Using tcpdump input

[Carter Bullard]

Hey Andrew,
   Tcpdump's problem is that it has to write each
packet to disk, which is a huge bottleneck.  Tcpdump
can only report on packets dropped that it can
detect have been dropped, which doesn't cover the
most likely packet loss points in the packet
capture path.

   Use ra() with the -A option to get it to report
actual application bytes transferred.  That should
be your number, if things are working right.

Carter

   


> -----Original Message-----
> From: Andrew Pollock [mailto:andrew-argus at andrew.net.au] 
> Sent: Thursday, March 27, 2003 2:02 AM
> To: Carter Bullard
> Cc: argus-info at lists.andrew.cmu.edu; fysche at mindlessproductions.com
> Subject: Re: Using tcpdump input
> 
> 
> 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 
>