In the experimental testbed, the NP-based capturing device is connected to a high-end personal computer equipped by two Intel Xeon 2.8GHz CPUs (with hyper threading activated), 1 GByte of rambus RAM and a 3COM Gigabit Ethernet optical ber network interface using the tg3 driver. The installed Operating System is Ubuntu Linux 7.04 OS with a 2.6.18 vanilla kernel. Unfortunately, the tg3 driver, along with the majority of the drivers for gigabit interfaces available for Linux, does not support the polling working mode (NAPI). Nonetheless, the interrupt mitigation mechanism supported in hardware by this 3COM interface proved to be su cient to avoid the PC livelock.
In order to perform packet capturing, a standard tcpdump and libpcap dis- tribution is used. Data streams are generated by Spirent ADTECH AX/4000 hardware packet generator and analyzer.
In the rst experiment, a bulk tra c stream is generated and fed to the personal computer either directly or through the NP. The main purpose of this experiment is, on one hand, the evaluation of the processing overhead introduced by the abstraction layer and, on the other hand, the evaluation of the bene ts introduced by the packet batching operation performed in the NP (due to the lower packet rate which means a lower rate of calls to the driver function). The NP has been set up to mark all the tra c with the owID 3, thus making it available through the mon3 virtual network interface on the receiving PC.
The stream is captured in both cases using the tcpdump raw capturing features. Hence, for the rst experiment the command line is:
user@hostname# tcpdump -i eth4 -w file1 while for the NP-driven one the command line is: user@hostname# tcpdump -i mon3 -w file2
The second experiment aims to show the capabilities of the system in ex- tracting and processing a mouse ow in presence of an elephant one. Therefore
Figure 4.7: Packets rawly saved to trace le.
two ows are involved: one (the mouse) from IP host 100.3.3.3 to 10.3.3.3 with TCP source port 100 and destination port 3357, the second (the ele- phant) with a dierent source port (3). The rst ow is generated at a rate of 50kpps, while the second one is generated at increasing packet rates. The compound ow is once again captured by the PC alone and through the NP. The NP is con gured to mark the mouse with owID 4 (available through mon4 at the receiving PC). In both cases tcpdump is simply asked to decode each packet and write it in a trace le (in a real context, this is the minimum real-time packet processing). The issued command lines is the following:
user@hostname# tcpdump -nttv -i eth4 -w file1 src host 10.3.3.3 and dst host 100.3.3.4 and src port 100 and dst port 3357
while, in the NP-driven experiment:
user@hostname# tcpdump -nttv -i mon4 -w file1. In both experiments, packets are minimum sized.
Fig. 4.7 shows that for the bulk stream capturing the NP-based system outperforms the PC alone, meaning that the bene t of a lower number of calls to the driver is greater than the processing overhead introduced by the abstraction layer.
Fig. 4.8 shows the full advantage obtained using the NP in the ow ex- traction. In this context the PC shows all its architectural aws loosing a huge amount of packets, while the NP-based system performs this operation with no loss.
Figure 4.8: Packets captured from the mouse ow.
4.8 Final considerations
This chapter proposes a packet capturing system architecture which combines the power of a Network Processor card with the exibility of software based solutions; this brings wire speed capturing capacity to applications such as tra c monitors, intrusion detection systems, protocol analyzers.
The system has been tested and proved to overcome or alleviate a number of limitations of standard PC tra c monitoring schemes. Moreover, it looks to be scalable towards multi gigabit environments by simply adopting a more powerful NP.
Some re nements are planned for this architecture to overcome some de- sign limitations. The rst limitation is the use of a batch packet regardless of the fragment length con gured by the user. Hence, if a user asks the system to capture the entire length of the packets, the resulting batch packet is longer then the maximum ethernet frame every time a full size packet is captured. To overcome this problem, we plan to use oversized ethernet frames handled by modern Gigabit Ethernet NICs.
A second limitation is the use of a gigabit ethernet interface of the NP- board to send batch frames to the cluster; as a matter of fact, the number of interfaces on an NP board is one of the most important sources of cost and hence must be saved. Therefore, a less expensive choice would be to use the PCI-X bus (which currently only gives power supply to the board) to transmit batch frames to the host PC and make it forward them to the cluster via a standard gigabit ethernet PCI-X NIC.
Finally, another limitation of the system is that it cannot currently classify and duplicate packets to more than one ow in order to send a given packet to more than one processing PC or application. A possible solution involves
the upgrade of the classi cation application (which must be able of handling rules with multiple target owIDs), of the batch frame format (and hence the PC side abstraction layer) to bring multiple owIDs per packet digest and of the batch frame crafting application to make it capable of copying a fragment across many packet digests (possibly with dierent fragment lengths).
Chapter 5
BRUNO: a high performance
traffic generator
Evaluating the performance of high speed networks is a critical task due to the lack of reliable tools to generate tra c workloads at high rates. The current open-source software tools (BRUTE, KUTE, RUDE) are not suitable to deal with high-speed networks as they present poor performance in terms of gener- ated frames per second and scarce timing/rate accuracy in tra c generation. These issues are due to the intrinsic limitations of the PC architecture, for which these tools are designed. This chapter proposes a dierent approach based on the Intel Network Processor IXP2400. The design aims to keep the high exibility of PC solutions while outperforming them in terms of band- width/packet rates. Moreover BRUNO achieves excellent results in terms of time/rate accuracy compared to other solutions based on Network Processors and, of course, the PC-based tools.