Hi Pavel, Thanks for your response. I didn't try it yet, I'll consider trying it, but currently my goal is to evaluate pf_ring C/C++ package to see if it fits my needs, in comparison to other packages. This is since I need to develop a kind of business-logic application using it. I really want to be able to add/remove HW filtering rules using pf_ring's APIs.
Thanks, Amir On Wed, Apr 29, 2015 at 10:57 AM, Pavel Odintsov <pavel.odint...@gmail.com> wrote: > 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 <akadur...@gmail.com> 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 < > cardigli...@ntop.org> > > wrote: > >> > >> > >> On 15 Apr 2015, at 19:10, Amir Kaduri <akadur...@gmail.com> 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 > >> <cardigli...@ntop.org> 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 <akadur...@gmail.com> 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 <akadur...@gmail.com> > >>> 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 > >>>> <cardigli...@ntop.org> 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 <akadur...@gmail.com> 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 > >>>>> <cardigli...@ntop.org> wrote: > >>>>>> > >>>>>> > >>>>>> On 05 Apr 2015, at 16:07, Amir Kaduri <akadur...@gmail.com> 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 <akadur...@gmail.com> > >>>>>> 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 > >>>>>>> <cardigli...@ntop.org> 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 <akadur...@gmail.com> > 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 Ntop-misc@listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc
