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
