A puzzle

[Carter Bullard]

Hey Peter,
   Well, at least its good that tcpdump data and
argus agree ;o)

   When there are fragments, argus puts in
some additional logic to double check the bytes
that are received against the byte count in the
first IP header, and so I would think that the
byte counts are accurate.  Because you aren't
getting any "frag" records, which would happen
if there was packet loss in the Fragmented stream,
it seems that you are getting all the packets,
and the byte counts are being fullfilled.  So
my feeling is to believe the counts. 

   Now the actual load discrepancies are
compelling and interesting, so we need to look
into it.  The times that are printed on the ra()
output are start times.  With the '-l' option you will
get lasttimes.  We should be doing the
load calculation based on total time.  Get
the earlies 'start time' and the lastest 'last time'
and use that for the interval calculation for
the bits/second values.  Although this may only
add another 300 seconds (5 min * 60 secs) to your
calculation, that may be enough to get it under
100 megabits/sec.

   I'm going on vacation until May 4th, so lets
talk/write about this when I get back.

Best Regads,

Carter


> -----Original Message-----
> From: Peter Van Epp [mailto:vanepp at sfu.ca]
> Sent: Wednesday, April 19, 2000 11:30 AM
> To: argus at lists.andrew.cmu.edu
> Subject: A puzzle
> 
> 
> 	Last Saturday someone on our time share host decided to 
> DOS somebody
> else. The router logs indicate a 15 minute peak at around 40 
> megabits per
> second (since the link is half duplex for argus that is 
> probably saturation
> level) on the 100 meg segment where argus is watching. 
> However argus seems to 
> indicate an impossible amount of traffic (although it 
> certainly got the sense 
> of things correct!) the output from "ra file -c -n host 
> aaa.bbb.ccc.dd":
> 
> Sat 04/15 18:36:12  F   udp   142.58.101.25.38593  ->  
> aaa.bbb.ccc.dd.16838 31
>    0       88536     0        TIM
> Sat 04/15 18:36:12  F   udp   142.58.101.25.38594  ->  
> aaa.bbb.ccc.dd.5758  31
>    0       88536     0        TIM
> ... (193170 similar lines)
> Sat 04/15 18:51:13  F   udp   142.58.101.25.41323  ->  
> aaa.bbb.ccc.dd.2763  31
>    0       88536     0        TIM
> Sat 04/15 18:51:13  F   udp   142.58.101.25.41327  ->  
> aaa.bbb.ccc.dd.23882 31
>    0       88536     0        TIM
> 
> 	Now as I understand it the "88536" should be the byte 
> count of the 
> packets seen in this flow (obviously as the F flag implies, 
> well fragmented!).
> However 193174 * 88536 ~= 17 gigabytes in 15 minutes (900 
> seconds) which in
> turn would seem to indicate a bit rate of 152 megabits per 
> second on the wire
> (which is only 100 meg half duplex Ether, the OC3 is after 
> this point). 
> 	Is this a case of argus calculating what the flow should have 
> transferred and ignoring the lost packets? Or I making a 
> mistake or wrong
> assumption of some kind here? This comes back to the question 
> (that I still 
> haven't resolved) of why argus and tcpdump packet counts on 
> the argus host are 
> much higher than the bytes transferred that the router claims to have 
> transferred on the interface where argus is. I need to get a 
> sniffer on the 
> segment and compare all three (or four if I include tcpdump) 
> and try and nail 
> the inconsistancy. I also need to try the newest Netramet 
> which has FreeBSD 
> byte order bug fixes (since an older version reported much 
> the same numbers as 
> argus) and see what that says ... The tcpdump numbers 
> matching the argus 
> numbers (i.e. a perl script summing tcpdump packet sizes and 
> argus byte counts
> for the same tcpdump file agree on the byte count) is still 
> much larger than
> the byte count the Cisco fastether interface is reporting 
> having transferred. 
> 
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000424/59bac1b0/attachment.html>