Using tcpdump input

[Peter Van Epp]

	Try a small (~ 100 packets or less) transfer where you can compare
each packet in both tcpdump and argus with what was sent would be my suggestion.
I'd also be tempted to try using tcpreplay out of one machine in to the other
to eliminate the span port on the switch from the equation initially as well.
Once you understand what happens at small volumes (where it is feasable to 
examine every packet) then move up to big files.

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


On Mon, Mar 31, 2003 at 11:50:56AM +1000, Andrew Pollock wrote:
> 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|
> >                 +-------+
> > 
> 
> More on this scenario...
> 
> In today's testing, we ran Argus and tcpdump side by side.
> Tcpdump logged to a tmpfs filesystem, so there was no disk I/O
> and was only logging the first 100 bytes.
> 
> We again used (native) rsync to transfer a 1GB file from onion
> to lettuce. The tcpdump, converted to an Argus log showed about 1.1GB 
> of data received by lettuce, whereas the native Argus log showed more
> like 2.2GB.
> 
> This was with the eepro100 Ethernet driver and the e100 Ethernet driver.
> 
> The strange thing is, last week we were getting Argus to report 1GB,
> and tcpdump showed about half that. Now both sets of figures seemed to have
> doubled. The only major difference was that last week we were running tcpdumps 
> with a snaplength of 0, so it was trying to log the entire packet, which would
> have increased the I/O on the box.
> 
> Anyone got any further thoughts?
> 
> Andrew