Wire-Speed Hardware-Assisted Traffic Filtering with Mainstream Network Adapters - Advances in Network-Embedded Management and Applications - page 83

networks, this means that traffic originated/directed to specific IPs or flowing
on specific ports need to analyzed. Doing this on a 10 Gbit link using
software-based traffic filters can be inefficient as packet loss might prevent
captured traffic from being analyzed properly. In order to implement a simple
packet capture system driven by signaling protocols such as Radius or DHCP,
it is possible to setup (e.g. via the PF_RING /proc filesystem interface) a few
filtering rules that discard all traffic except signaling (similar to the setup used
in 5.2) and traffic belonging to target IPs that need to be intercepted.
5.5 Firewalling at 10 Gbit
The Linux netfilter/iptables firewall is quite efficient but it cannot operate
with no loss on heavily loaded 10 Gbit links. The use of 5-tuple filters can
definitively help dropping unwanted traffic or tracking NAT sessions using
FD filters. Unfortunately the Linux firewall is more flexible than 5-tuple
filters, hence it is not possible to do a one-to-one mapping between iptables
rules and 5-tuple filters. This means that 82599 can be used to discard a large
portion of incoming traffic but not all, leaving to netfilter the duty of
completing packet filtering. Nevertheless this hybrid, hardware plus software,
filtering architecture allows to significantly boost the firewall performance in
most situations. Currently we are add filters using the PF_RING /proc
filesystem interface as we have not yet added native 82599 support into
netfilter.
6 Open Issues and Future Work
The main limitation of the current implementation is the lack of a compiler
that transparently compiles BPF filters into PF_RING (hence flow affinity)
filters. Due to this limitation, users must configure both BPF filters (e.g. on
the command line while starting the monitoring tool) and flow affinity filters
(e.g. using the PF_RING /proc filesystem). In future code releases we plan
to implement such feature so that BPF-aware applications (e.g. Wireshark)
can still use BPF for setting filters while the underlying kernel layers add
automatically flow affinity filters in order to reduce the amount of packets
that will hit the BPF filtering engine. In addition to 5-tuple and FD filters,
82599 also supports SYN filter that diverts to a specific core all incoming
TCP packets with the SYN flag set. While its support would be trivial from
the 82599 point of view, the PF_RING engine instead needs some extensions
in order to add filters that can select packets based on TCP flags.
Finally we would like to use 82599 in the context of OpenFlow switching, for
implementing efficient in-kernel switching across network applications