Hello, Amir!

I suggest you switch to hardware NIC level filtering rules from ethtool
interface directly:
https://github.com/FastVPSEestiOu/fastnetmon/wiki/Traffic-filtration-using-NIC-capabilities-on-wire-speed-(10GE,-14Mpps)

Because it works on wire speed and has zero cost for cpu resources.

On Sunday, April 5, 2015, 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.
> 2. Does this API also purges HW rules?
> 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?
> 4. I have a valid rule, but whenever I
> call pfring_get_hash_filtering_rule_stats(..), it fails.Any idea why?
>     - 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','Ntop-misc@listgateway.unipi.it');>
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>
>>>
>>>
>>> _______________________________________________
>>> Ntop-misc mailing list
>>> Ntop-misc@listgateway.unipi.it
>>> <javascript:_e(%7B%7D,'cvml','Ntop-misc@listgateway.unipi.it');>
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-misc
>>>
>>
>>
>

-- 
Sincerely yours, Pavel Odintsov
_______________________________________________
Ntop-misc mailing list
Ntop-misc@listgateway.unipi.it
http://listgateway.unipi.it/mailman/listinfo/ntop-misc

Reply via email to