Hello, Amir! Have you tried manual configuration of hardware filters for 82599? You could try do it with ethtool: https://github.com/FastVPSEestiOu/fastnetmon/wiki/Traffic-filtration-using-NIC-capabilities-on-wire-speed-(10GE,-14Mpps)
From my point of view ethtool interface is more flexible for hardware filter management. But I can't find any API for C/C++ for it. On Wed, Apr 29, 2015 at 10:50 AM, Amir Kaduri <[email protected]> wrote: > Hi, > > After testing software filtering rules, I've tried hardware filtering rules. > Unfortunately, it doesn't work for me. > First, I tested it using pfring 6.0.1 64bit, and then used pfring 5.6.1 > 32bit to make sure its not related to the version and the architecture. > In both tests, I didn't see that the hardware filters work. > > The command line I used: ./pfcount_82599 -i eth2 -v -m > > The NIC details: 06:00.1 Ethernet controller: Intel Corporation 82599EB > 10-Gigabit SFI/SFP+ Network Connection (rev 01) > > I used the following files: > 1. > https://drive.google.com/file/d/0B10Ms5GOXgCxYy1uWHZ2dXJrck0/view?usp=sharing > The tester program pfcount_82599.c with slight changes: enabling 3 > intel_82599_five_tuple_rule rules: > - One that drops tcp packets > - Second that drops packets with source 10.12.150.231 > - Third that drops packets with dest 10.12.150.231 > 2. > https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing > The pcap file containing 344 packets, that should be filtered with the > tester above. > > Note that all 3 rules should drop the packets in the attached tester. > > Any help to prove that hardware rules work, based on the above info, will be > much appreciated. > > Thanks, > Amir > > > On Thu, Apr 16, 2015 at 12:54 AM, Alfredo Cardigliano <[email protected]> > wrote: >> >> >> On 15 Apr 2015, at 19:10, Amir Kaduri <[email protected]> wrote: >> >> Hi, >> >> I would like to update that the problem in the tester program was that I >> probably didn't add the vlan_id to rule. Once added, the hash rule began to >> work. >> >> >> Ok, that was definitely the problem, vlan-id is part of the hash input >> (vlan, protocol, src/dst ip, src/dst port). >> >> Also, I would like to refer to the argument "There is no limit to the >> number of software hash rules": >> I assume that the meaning is that the algorithm doesn't have any >> limitation, though, since the rule_id field type is u_int16_t, there is a >> limit of 64K hash rules, de-facto. >> >> >> That’s right, we can consider changing the rule_id type if 64K rules is >> not enough in some use case. >> >> Alfredo >> >> >> Thanks, >> Amir >> >> On Tue, Apr 14, 2015 at 12:34 PM, Alfredo Cardigliano >> <[email protected]> wrote: >>> >>> Hi Amir >>> yes thank you for the files, I will look at them ASAP. >>> >>> Alfredo >>> >>> On 14 Apr 2015, at 11:17, Amir Kaduri <[email protected]> wrote: >>> >>> Hi Alfredo, >>> >>> I hope you saw what I've sent last week. Any chance that you will take a >>> look at it soon? >>> >>> Thanks, >>> Amir >>> >>> On Fri, Apr 10, 2015 at 11:08 AM, Amir Kaduri <[email protected]> >>> wrote: >>>>> >>>>> Hi Alfredo, >>>>> >>>>> Since the original pcap is huge, I sliced a smaller pcap from it, >>>>> holding 344 packets. >>>> >>>> Link to the tester code (based on pfcount_82599.c): >>>> >>>> https://drive.google.com/file/d/0B10Ms5GOXgCxdXhtRGRoQ1FTYVFDbkFGMkwzVExNRHJXbmt3/view?usp=sharing >>>> >>>> Link to the pcap file (congtaining 344 packets): >>>> >>>> https://drive.google.com/file/d/0B10Ms5GOXgCxS0dxR3lTZUoyRHZyUlpoemJfT0k2cS1QRGFr/view?usp=sharing >>>> >>>>> >>>>> Thanks a lot, >>>>> Amir >>>>> >>>> >>>> On Wed, Apr 8, 2015 at 4:07 PM, Alfredo Cardigliano >>>> <[email protected]> wrote: >>>>> >>>>> Hi Amir >>>>> could you provide your patched pfcount and a pcap with the packets >>>>> matching your rule? >>>>> >>>>> Alfredo >>>>> >>>>> On 08 Apr 2015, at 13:36, Amir Kaduri <[email protected]> wrote: >>>>> >>>>> I'm currently in a situation, that no rules work for me whatsoever >>>>> (same configuration I described earlier), and they did work for me a few >>>>> day >>>>> ago. >>>>> I'm using the pfcount_82599.c tester, and added a single hash rule. The >>>>> only thing that does work is the default behavior, when using the API >>>>> pfring_toggle_filtering_policy(pd, 1) (default to allow - packets >>>>> arrive normally) or pfring_toggle_filtering_policy(pd, 0); (default to >>>>> drop, >>>>> no packet arrive to the tester). >>>>> This is the part of code: >>>>> >>>>> ------------------------------------------------------------------------------------------ >>>>> : >>>>> rc = pfring_enable_ring(pd); >>>>> if (rc<0) >>>>> printf("pfring_enable_ring() failed. rc=%d\n", rc); >>>>> >>>>> pfring_toggle_filtering_policy(pd, 1); /* Default to allow */ >>>>> >>>>> if (1) { >>>>> hash_filtering_rule rule; >>>>> u_int16_t rule_id = 0; >>>>> >>>>> memset(&rule, 0, sizeof(hash_filtering_rule)); >>>>> rule.proto = 6; >>>>> rule.rule_id = rule_id++; >>>>> rule.rule_action = dont_forward_packet_and_stop_rule_evaluation; >>>>> rule.host4_peer_a = ntohl(inet_addr("10.12.150.231")); >>>>> rule.port_peer_a = 2489; >>>>> rule.host4_peer_b = ntohl(inet_addr("10.61.12.31")); >>>>> rule.port_peer_b = 139; >>>>> rc = pfring_handle_hash_filtering_rule(pd, &rule, 1); >>>>> if(rc<0) >>>>> printf("pfring_add_hash_filtering_rule(%d) failed [errno=%d: %s]\n", >>>>> rule.rule_id, errno, strerror(errno)); >>>>> else >>>>> printf("pfring_add_hash_filtering_rule(%d) succeeded\n", rule.rule_id); >>>>> } >>>>> >>>>> ------------------------------------------------------------------------------------------ >>>>> I don't get any errors when the following code run, but when I bombard >>>>> the machine >>>>> with a pcap containing more than 600,000 packets of the specified >>>>> session that I've expected to be filtered out, >>>>> packets of it still received at the tester. >>>>> >>>>> I'm pretty sure that something goes wrong in pf_ring, but I can't tell >>>>> what. >>>>> What is the best way to get debug information, other than reading >>>>> /var/log/messages? >>>>> >>>>> Thanks, >>>>> Amir >>>>> >>>>> >>>>> On Wed, Apr 8, 2015 at 1:08 PM, Alfredo Cardigliano >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On 05 Apr 2015, at 16:07, Amir Kaduri <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I think I've made some progress: AFAIU, the packets that I see despite >>>>>> the rule that supposed to filter them, are packets the receive during the >>>>>> time interval from rule-set to rule-apply by pfring. >>>>>> I'll appreciate getting some answers about the following: >>>>>> 1. If I use the pfring_purge_idle_hash_rules(..) API, is there any way >>>>>> to know which rules-ids are set and which are vacant? >>>>>> This is because I have to follow the rules-ids when setting them, >>>>>> but when I purge them, I don't know which of them were removed. >>>>>> >>>>>> >>>>>> No, unfortunately this is not possible with the current API. >>>>>> >>>>>> 2. Does this API also purges HW rules? >>>>>> >>>>>> >>>>>> No, It doesn’t. >>>>>> >>>>>> 3. According to the documentation, I know that HW rules have a limit >>>>>> of 32,000. What is the limit for hash rules? IS this limit includes the >>>>>> 32,000 of the HW, or additional to it? >>>>>> >>>>>> >>>>>> There is no limit to the number of software hash rules. >>>>>> >>>>>> 4. I have a valid rule, but whenever I call >>>>>> pfring_get_hash_filtering_rule_stats(..), it fails.Any idea why? >>>>>> >>>>>> >>>>>> pfring_get_hash_filtering_rule_stats() should be used with sw rules to >>>>>> get stats from kernel plugins (when used), otherwise there is no stats >>>>>> per >>>>>> rule. >>>>>> >>>>>> Br >>>>>> Alfredo >>>>>> >>>>>> - I've add the stats code to the pfcount_82599 tester >>>>>> - In /var/log/messages I see the following message that is >>>>>> probably originated from ring_setsockopt(): "kernel: [PF_RING] Found rule >>>>>> but pluginId 0 is not registered" >>>>>> >>>>>> Thanks, >>>>>> Amir >>>>>> >>>>>> >>>>>> On Thu, Apr 2, 2015 at 5:06 PM, Amir Kaduri <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> Hi Alfredo, >>>>>>> >>>>>>> Thanks for referring to my question. >>>>>>> I hope the following answers: >>>>>>> >>>>>>> [root@CT10K10G]# cat /etc/pf_ring/pfring.conf >>>>>>> min_num_slots=1024 transparent_mode=2 enable_frag_coherence=1 >>>>>>> enable_ip_defrag=1 >>>>>>> >>>>>>> [root@CT10K10G]# cat /proc/net/pf_ring/info >>>>>>> PF_RING Version : 6.0.1 ($Revision: exported$) >>>>>>> Total rings : 0 >>>>>>> >>>>>>> Standard (non DNA) Options >>>>>>> Ring slots : 1024 >>>>>>> Slot version : 15 >>>>>>> Capture TX : Yes [RX+TX] >>>>>>> IP Defragment : Yes >>>>>>> Socket Mode : Standard >>>>>>> Transparent mode : No [mode 2] >>>>>>> Total plugins : 0 >>>>>>> Cluster Fragment Queue : 0 >>>>>>> Cluster Fragment Discard : 0 >>>>>>> >>>>>>> Thanks, >>>>>>> Amir >>>>>>> >>>>>>> >>>>>>> On Thu, Apr 2, 2015 at 4:10 PM, Alfredo Cardigliano >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Amir >>>>>>>> how did you load pf_ring.ko? Can I see the command line? >>>>>>>> Please also try using latest code from svn, this helps us debugging >>>>>>>> the issue. >>>>>>>> >>>>>>>> Br >>>>>>>> Alfredo >>>>>>>> >>>>>>>> On 01 Apr 2015, at 18:22, Amir Kaduri <[email protected]> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I’m using PF_RING-6.0.1. >>>>>>>> >>>>>>>> I’m trying to develop an application that runs some algorithm >>>>>>>> consisting on rules. >>>>>>>> >>>>>>>> I made some tests using the “pfcount” tester, and unfortunately, I >>>>>>>> don’t understand the behavior: >>>>>>>> >>>>>>>> I’m running the following command line: “./pfcount -i eth3 -u 2 -v 1 >>>>>>>> -r –m” which AFAIU, adds a wildcard filter for each incoming packet. >>>>>>>> >>>>>>>> If I get it correctly, once a rule was added, I should not expect >>>>>>>> other packets of the same session to receive, and this is not what I’m >>>>>>>> getting. >>>>>>>> >>>>>>>> For example: >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------------------------------------------------- >>>>>>>> >>>>>>>> [root@CT10K10G examples]# ./pfcount -i eth3 -u 2 -v 1 -r -m >>>>>>>> >>>>>>>> Adding wildcard filtering rules >>>>>>>> >>>>>>>> Using PF_RING v.6.0.1 >>>>>>>> >>>>>>>> Capturing from eth3 [00:E0:ED:FE:18:19][ifIndex: 11] >>>>>>>> >>>>>>>> # Device RX channels: 6 >>>>>>>> >>>>>>>> # Polling threads: 1 >>>>>>>> >>>>>>>> Dumping statistics on /proc/net/pf_ring/stats/11993-eth3.1074 >>>>>>>> >>>>>>>> 18:52:35.956295950 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 -> >>>>>>>> 10.70.150.108:60189] >>>>>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596843063] >>>>>>>> [caplen=128][len=1522][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>>>>> >>>>>>>> Rule 0 added successfully... >>>>>>>> >>>>>>>> 18:52:35.956301616 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 -> >>>>>>>> 10.70.150.108:60189] >>>>>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596844523] >>>>>>>> [caplen=128][len=650][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>>>>> >>>>>>>> Rule 1 added successfully... >>>>>>>> >>>>>>>> 18:52:35.956303262 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 -> >>>>>>>> 10.70.150.108:60189] >>>>>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596845111] >>>>>>>> [caplen=128][len=1086][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>>>>> >>>>>>>> Rule 2 added successfully... >>>>>>>> >>>>>>>> : >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------------------------------------------------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> How come, that once rule #0 was added for [10.61.10.9:52311 -> >>>>>>>> 10.70.150.108:60189], I still see such packets in the next lines? >>>>>>>> Shouldn’t >>>>>>>> they be filtered by the rule that just as added? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> (BTW, when I use the command “./pfcount -i eth3 -u 1 -v 1 -r –m” >>>>>>>> (i.e. –u is 1 rather than 2), the tester uses hash filters, and in this >>>>>>>> case, I get errors: >>>>>>>> >>>>>>>> 18:53:19.052549112 [RX][if_index=11][00:08:E3:FF:FC:C8 -> >>>>>>>> 00:01:02:03:04:05] [vlan 70] [direction 1] [IPv4][10.61.10.9:52311 -> >>>>>>>> 10.70.150.108:60189] >>>>>>>> [l3_proto=TCP][hash=344283189][tos=0][tcp_seq_num=596847159] >>>>>>>> [caplen=128][len=1490][parsed_header_len=0][eth_offset=-14][l3_offset=18][l4_offset=38][payload_offset=58] >>>>>>>> >>>>>>>> pfring_add_hash_filtering_rule(1) failed) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any help will be appreciated. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Amir >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ntop-misc mailing list >>>>>>>> [email protected] >>>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ntop-misc mailing list >>>>>>>> [email protected] >>>>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ntop-misc mailing list >>>>>> [email protected] >>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ntop-misc mailing list >>>>>> [email protected] >>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ntop-misc mailing list >>>>> [email protected] >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ntop-misc mailing list >>>>> [email protected] >>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>>> >>>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >>> >>> >>> >>> _______________________________________________ >>> Ntop-misc mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc >> >> >> >> _______________________________________________ >> Ntop-misc mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop-misc > > > > _______________________________________________ > Ntop-misc mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop-misc -- Sincerely yours, Pavel Odintsov _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
