Information Technology Reference
In-Depth Information
In the first test we compared hardware (i.e. 82599) vs. software (i.e.
PF_RING) packet filtering using a single filtering rule that match for every
incoming packet (i.e. the entire traffic is forwarded to the user space). In the
second test we have injected traffic that does not match any configured filter,
and verified that there is no load on the CPU whenever hardware filters are
used. On the contrary, what we observed with software filters, is that for
packets up to 256 bytes the CPU utilization was around 95%, and about 3%
for larger packets. This leads us to the conclusion that in the hybrid model of
software and hardware filtering we propose, it is recommended to use
software filters only for medium to large packets.
In order to further improve packet capture, the authors have developed
TNAPI [25], a multithreaded RX queue polling mechanism that significantly
improves packet capture performance with respect to the standard Linux
NAPI.
5.1 Realtime Multimedia Traffic Monitoring
As described earlier in this paper, RTC-Mon has been designed to efficiently
handle VoIP calls and video-on-demand traffic analysis at 1 Gbit. In order to
scale the solution to 10 Gbit, we have slightly modified the original RTC-
Mon code as follows:
•
A few 5-tuple filters have been configured:
•
All the SIP signaling packets go to core 0.
Non UDP (i.e. ICMP/TCP) packets are dropped.
•
UDP traffic on popular ports (e.g. port 53 used by DNS) is also
dropped.
•
•
Whenever a new VoIP call has been setup, such call is tracked by adding
two FD filters (one per call direction) that send the voice traffic for the
tracked call (i.e. RTP traffic) to the same RX queue where the RTP plugin
is active. In order to evenly balance the traffic across queues, the queue ids
used for voice traffic are selected in round robin so that all queues have
almost the same amount of traffic.
This setup has allowed RTC-Mon to operate efficiently in 10 Gbit links where
VoIP is only a portion of the overall traffic, thanks to 82599 filters used to
discard packets not belonging to calls being tracked. Unfortunately, not all
unwanted packets have been discarded and a small portion of them is still
received by PF_RING. This is because 5-tuple filters are evaluated before FD
filters, hence it is not possible to set 5-tuple rule that discards all the
remaining traffic because this would also discard traffic that matched by FD
filters. It is worth noting that the ability to setup thousands of flow affinity
Search WWH ::
Custom Search