On 07/22/2014 01:18 AM, jk_14 wrote:
>
> Hi,
>
> I'm using latest PF_RING software for hardware filtering with Intel 82599
> based NIC (X520 in fact)
>
> And HW five-tuples filtering - works almost fine. Almost, because it seems I
> have found some problem:
>
> In my example I use only one, full drop rule:
> if(1) {
> memset(&rule, 0, sizeof(rule)), rule.rule_family_type =
> intel_82599_five_tuple_rule;
> rule.rule_id = rule_id++, ft_rule->queue_id = -1;
> rc = pfring_zc_add_hw_rule(zq, &rule);
> if(rc != 0) printf("pfring_zc_add_hw_rule(%d) failed [rc=%d]\n",
> rule.rule_id, rc);
> else printf("pfring_zc_add_hw_rule(%d) succeeded: drop rule\n",
> rule.rule_id);
> }
>
> And in the result we can see some UDP frames, which shouldn't be present
> here:
> [70:DD:A1:6B:C2:23 -> 01:80:C2:00:00:02] [eth_type=0x8809]
> [caplen=60][len=60][parsed_header_len=0][eth_offset=0][l3_offset=14][l4_offset=0][payload_offset=0]
> [70:DD:A1:6B:C2:23 -> 01:80:C2:00:00:02] [eth_type=0x8809]
> [caplen=60][len=60][parsed_header_len=0][eth_offset=0][l3_offset=14][l4_offset=0][payload_offset=0]
> [70:DD:A1:6B:C2:23 -> 00:22:83:D9:AA:95] [vlan 901]
> [IPv4][10.194.72.1:4003 -> 172.18.227.250:49999]
> [l3_proto=UDP][hash=3067478659][tos=56][tcp_seq_num=0]
> [caplen=1518][len=1518][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=46]
> [70:DD:A1:6B:C2:23 -> 00:22:83:D9:AA:95] [vlan 901] [IPv4][10.194.72.1:0
> -> 172.18.227.250:0] [l3_proto=UDP][hash=3067424657][tos=56][tcp_seq_num=0]
> [caplen=102][len=102][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=0]
> [70:DD:A1:6B:C2:23 -> 01:80:C2:00:00:02] [eth_type=0x8809]
> [caplen=60][len=60][parsed_header_len=0][eth_offset=0][l3_offset=14][l4_offset=0][payload_offset=0]
> [70:DD:A1:6B:C2:23 -> 01:80:C2:00:00:02] [eth_type=0x8809]
> [caplen=60][len=60][parsed_header_len=0][eth_offset=0][l3_offset=14][l4_offset=0][payload_offset=0]
> [70:DD:A1:6B:C2:23 -> 00:22:83:D9:AA:95] [vlan 901]
> [IPv4][10.194.72.1:4003 -> 172.18.227.250:49999]
> [l3_proto=UDP][hash=3067478659][tos=56][tcp_seq_num=0]
> [caplen=1518][len=1518][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=46]
> [70:DD:A1:6B:C2:23 -> 00:22:83:D9:AA:95] [vlan 901] [IPv4][10.194.72.1:0
> -> 172.18.227.250:0] [l3_proto=UDP][hash=3067424657][tos=56][tcp_seq_num=0]
> [caplen=102][len=102][parsed_header_len=0][eth_offset=0][l3_offset=18][l4_offset=38][payload_offset=0]
> ^[[A^CLeaving...
> =========================
> Absolute Stats: 81 pkts (15'633'475 drops) - 37'070 bytes
> =========================
>
>
>
> So, it seems UDP packets above are able to pass the “drop all” rule only if
> the size is equal to 1518 bytes,
> and then one more (probably next) packet is always passed yet, in pair...
The issue lies in the fact that the frame is fragmented. An IP
fragmented frame will not match any rule as the frame parser cannot
guarantee the L4 header is present on this frame.
This is a limitation of the 82599 hardware and is the reason why the
frames that are broken into 1518/102 pairs are making it through the filter.
Thanks,
Alex
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
