Using tcpdump input

[Peter Van Epp]

        I'd suggest everyone's friend tcpreplay (available from ftp.sfu.ca
in /pub/unix/tcpreplay since its home site had died last I looked). It will
replay a tcpdump file (at varying speeds) to the wire. Thus you can slow the
output down til all involved can keep up :-) You can also repeat the exact
same sequence of packets every time (even with close to identical timing).
I found it very useful (along with a switch capable of wire speed rmon to
get on the wire packet counts) for assessing how fast a given box could
capture and to assess where packets were being lost.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada


On Thu, Mar 27, 2003 at 05:01:44PM +1000, Andrew Pollock wrote:
> On Wed, Mar 26, 2003 at 07:55:56PM -0500, Carter Bullard wrote:
> > Hey Andrew,
> >    Great!  It seems that everyone has to do this at some
> > point.  If you have any problems, or interesting results,
> > don't hesitate to send mail.
> 
> Interesting results time.
> 
> We setup three boxes and a Cisco switch like so:
> 
> +-------+       +-------+        +-----+
> |lettuce|-------|Switch |--------|onion|
> +-------+       +-------+        +-----+
>                     |
>                     |
>                 +-------+
>                 |rhubarb|
>                 +-------+
> 
> Lettuce and Onion were used to transfer files backwards and forwards,
> the switch had a span port setup with Rhubarb running Argus and tcpdump.
> 
> We used SSH, rsync and netcat to transfer a file of random contents being exactly
> 1GB in size (1024^3 bytes).
> 
> We ran Argus and tcpdump simultaneously and tcpdump by itself, with tcpdump invoked with a
> snaplen of 0 to catch the entire packet.
> 
> I would have thought that with a snaplen of zero, the resulting tcpdump would be greater 
> than the size of the file being transferred, given IP overhead and whatnot, yet the tcpdump
> was consistently less than 1GB (exact size varied depending on transport method used), which suggests
> dropped packets. Tcpdump claims there were no dropped packets, yet the number packets seen was approximately
> 50% of what an racount of the Argus logfile said it saw.
> 
> So if tcpdump is indeed dropping packets, this strikes me as strange that Argus isn't as well, given they are
> both using libpcap.
> 
> The interesting thing with the Argus results is that they came out somewhat higher than I would have expected,
> the 1GB file transferred using netcat, which I figured would have been about as raw TCP in terms of transport as it comes,
> had Argus reporting about a 20% more than the 1GB going over the wire, which seems quite a lot of overhead to me.
> 
> We're yet to see what the interface counter on the switch saw.
> 
> Andrew