123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233 |
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
- <!--Converted with LaTeX2HTML 2002-2 (1.70)
- original version by: Nikos Drakos, CBLU, University of Leeds
- * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
- * with significant contributions from:
- Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
- <HTML>
- <HEAD>
- <TITLE>5 Common Questions from Users</TITLE>
- <META NAME="description" CONTENT="5 Common Questions from Users">
- <META NAME="keywords" CONTENT="FAQ">
- <META NAME="resource-type" CONTENT="document">
- <META NAME="distribution" CONTENT="global">
- <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
- <META NAME="Generator" CONTENT="LaTeX2HTML v2002-2">
- <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
- <LINK REL="STYLESHEET" HREF="FAQ.css">
- <LINK REL="next" HREF="node7.html">
- <LINK REL="previous" HREF="node5.html">
- <LINK REL="up" HREF="FAQ.html">
- <LINK REL="next" HREF="node7.html">
- </HEAD>
- <BODY >
- <DIV CLASS="navigation"><!--Navigation Panel-->
- <A NAME="tex2html213"
- HREF="node7.html">
- <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
- <A NAME="tex2html209"
- HREF="FAQ.html">
- <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
- <A NAME="tex2html203"
- HREF="node5.html">
- <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
- <A NAME="tex2html211"
- HREF="node1.html">
- <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
- <BR>
- <B> Next:</B> <A NAME="tex2html214"
- HREF="node7.html">6 Testing Methodologies</A>
- <B> Up:</B> <A NAME="tex2html210"
- HREF="FAQ.html">Tcpreplay 3.x FAQ</A>
- <B> Previous:</B> <A NAME="tex2html204"
- HREF="node5.html">4 Common Error and</A>
- <B> <A NAME="tex2html212"
- HREF="node1.html">Contents</A></B>
- <BR>
- <BR></DIV>
- <!--End of Navigation Panel-->
- <!--Table of Child-Links-->
- <A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
- <UL CLASS="ChildLinks">
- <LI><A NAME="tex2html215"
- HREF="node6.html#SECTION00061000000000000000"><SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">1</SPAN> Why is tcpreplay not sending all the packets?</A>
- <LI><A NAME="tex2html216"
- HREF="node6.html#SECTION00062000000000000000"><SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">2</SPAN> Can tcpreplay read gzip/bzip2 compressed files?</A>
- <LI><A NAME="tex2html217"
- HREF="node6.html#SECTION00063000000000000000"><SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">3</SPAN> How fast can tcpreplay send packets?</A>
- <LI><A NAME="tex2html218"
- HREF="node6.html#SECTION00064000000000000000"><SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">4</SPAN> Is tcpreplay stateful?</A>
- </UL>
- <!--End of Table of Child-Links-->
- <HR>
- <H1><A NAME="SECTION00060000000000000000">
- <SPAN CLASS="arabic">5</SPAN> Common Questions from Users</A>
- </H1>
- <P>
- <H2><A NAME="SECTION00061000000000000000">
- <SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">1</SPAN> Why is tcpreplay not sending all the packets?</A>
- </H2>
- <P>
- 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).
- <P>
- 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.
- <P>
- The longer version goes something like this:
- <P>
- 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:
- <P>
- <OL>
- <LI>It is well known that tcpdump and other sniffers have a problem keeping
- up with high-speed traffic. Furthermore, the OS in many cases <SPAN CLASS="textit">lies</SPAN>
- 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.
- </LI>
- <LI>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.
- </LI>
- </OL>
- 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.
- <P>
- <H2><A NAME="SECTION00062000000000000000">
- <SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">2</SPAN> Can tcpreplay read gzip/bzip2 compressed files?</A>
- </H2>
- <P>
- Yes, but not directly. Since tcpreplay can read data via STDIN, you
- can decompress the file on the fly like this:
- <P>
- <SPAN CLASS="textit">gzcat myfile.pcap.gz | tcpreplay -i eth0 -</SPAN>
- <P>
- Note that decompressing on the fly will require additional CPU time
- and will likely reduce the overall performance of tcpreplay.
- <P>
- <H2><A NAME="SECTION00063000000000000000">
- <SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">3</SPAN> How fast can tcpreplay send packets?</A>
- </H2>
- <P>
- First, if performance is important to you, then upgrading to tcpreplay
- 3.x is worthwhile since it is more optimized then the 1.x or 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:
- <P>
- <UL>
- <LI>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.
- </LI>
- <LI>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.
- </LI>
- <LI>Most operating systems will cache disk reads in RAM; hence making
- subsequent access to the file faster the second time.
- </LI>
- <LI>Re-opening small files repeatly will reduce performance. Consider
- using mergecap to generate a single large file.
- </LI>
- <LI>Network cards and drivers, disk speed (RPM is more important then
- seek), amount of RAM and system bus speed are all important.
- </LI>
- <LI>In general servers with faster disks and bus speeds will be faster
- then desktops which will be faster then laptops.
- </LI>
- </UL>
- <P>
- <H2><A NAME="SECTION00064000000000000000">
- <SPAN CLASS="arabic">5</SPAN>.<SPAN CLASS="arabic">4</SPAN> Is tcpreplay stateful?</A>
- </H2>
- <P>
- No. Tcpreplay processes each packet in the order it is stored in the
- pcap file. The default is to send each packet based on the timestamp
- stored in the pcap file. If your pcap file has packets out of order,
- tcpreplay will send them out of order. In certain situations a packet
- may have an earlier timestamp then the packet before it, tcpreplay
- will then send the second packet as soon as possible.
- <P>
- The basic point is that if your pcap file is well formed and has the
- packets in the correct order, then tcpreplay will create a ``stateful''
- packet stream. If your pcap file has errors, then tcpreplay will repeat
- those errors. Garbage in, garbage out.
- <P>
- <DIV CLASS="navigation"><HR>
- <!--Navigation Panel-->
- <A NAME="tex2html213"
- HREF="node7.html">
- <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
- <A NAME="tex2html209"
- HREF="FAQ.html">
- <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
- <A NAME="tex2html203"
- HREF="node5.html">
- <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
- <A NAME="tex2html211"
- HREF="node1.html">
- <IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
- <BR>
- <B> Next:</B> <A NAME="tex2html214"
- HREF="node7.html">6 Testing Methodologies</A>
- <B> Up:</B> <A NAME="tex2html210"
- HREF="FAQ.html">Tcpreplay 3.x FAQ</A>
- <B> Previous:</B> <A NAME="tex2html204"
- HREF="node5.html">4 Common Error and</A>
- <B> <A NAME="tex2html212"
- HREF="node1.html">Contents</A></B> </DIV>
- <!--End of Navigation Panel-->
- <ADDRESS>
- Aaron Turner
- 2006-07-17
- </ADDRESS>
- </BODY>
- </HTML>
|