Subsections
Every now and then, someone emails the tcpreplay-users list, asking
if there is a bug in tcpreplay which causes it not to send all the
packets. This usually happens when the user uses the -t flag or is
replaying a high-speed pcap file (> 50Mbps, although this number is
dependant on the hardware in use).
The short version of the answer is: no, we are not aware of any bugs
which might cause a few packets to not be sent.
The longer version goes something like this:
If you are running tcpreplay multiple times and are using tcpdump
or other packet sniffer to count the number packets sent and are getting
different numbers, it's not tcpreplay's fault. The problem lies in
one of two places:
- It is well known that tcpdump and other sniffers have a problem keeping
up with high-speed traffic. Furthermore, the OS in many cases lies
about how many packets were dropped. Tcpdump will repeat this lie
to you. In other words, tcpdump isn't seeing all the packets. Usually
this is a problem with the network card, driver or OS kernel which
may or may not be fixable. Try another network card/driver.
- When tcpreplay sends a packet, it actually gets copied to a send buffer
in the kernel. If this buffer is full, the kernel is supposed to tell
tcpreplay that it didn't copy the packet to this buffer. If the kernel
has a bug which squelches this error, tcpreplay will not keep trying
to send the packet and will move on to the next one. Currently I am
not aware of any OS kernels with this bug, but it is possible that
it exists. If you find out that your OS has this problem, please let
me know so I can list it here.
If for some reason, you still think its a bug in tcpreplay, by all
means read the code and tell me how stupid I am. The do_packets()
function in do_packets.c is where tcpreplay processes the pcap file
and sends all of the packets.
Yes, but not directly. Since tcpreplay can read data via STDIN, you
can decompress the file on the fly like this:
gzcat myfile.pcap.gz | tcpreplay -i eth0 -
Note that decompressing on the fly will require additional CPU time
and will likely reduce the overall performance of tcpreplay.
First, if performance is important to you, then upgrading to tcpreplay
3.x is worthwhile since it is more optimized then the 2.x series.
After that, there are a number of variables which effect performance,
including on how you measure it (packets/sec or bytes/sec). 100Mbps
and 120K pps are quite doable. Generally speaking here are some points
to consider:
- Profiling tcpreplay has shown that a significant amount of time is
spent writing packets to the network. Hence, your OS kernel implimentation
of writing to raw sockets is one of the most important aspects since
that is where tcpreplay spends most of it's time.
- Like most network based I/O, it is faster to send the same amount
of data in a few large packets then many small packets.
- Most operating systems will cache disk reads in RAM; hence making
subsequent access to the file faster the second time.
- Re-opening small files repeatly will reduce performance. Consider
using mergecap to generate a single large file.
- Network cards and drivers, disk speed (RPM is more important then
seek), amount of RAM and system bus speed are all important.
Aaron Turner
2005-08-07
