Argus 2.0 Record Changes

[Carter Bullard]

Hey Peter!
   There are several ways to tackle the link utilization value
that you are looking for, but I'm not sure exactly if I know
what your fishing for, so lets try some possibilities.

   If your looking for just relative per flow link utilization.
One way that you would do it, with any version of Argus, is
to configure it to generate management records, which report
total packets and bytes on the interface, at an interval that
suits your needs, say every 60 seconds, or less.  This would
give you the basic link utilization trend, and then you could
compare the per flow utilization that can be derived from
the actual flow records to decide whose the biggest, baddest
flow during the interval.

   If it is, "what percentage of the link utilization
was contributed by this flow", well now there is a stat
we could put into each flow record.  I would do it by noting
the total interface packets and bytes at the start of the
flow report, and the total interface packets and bytes at
the end of the flow report, and dividing the difference
into the totals for the flow.

   Is this last stat what your interested in?

Carter


-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[snip]

	Although I'm not sure how to do it, I'd like to see a utilization
field (which may be stats below here) that counts all bytes coming by (IP
and
otherwise) and gives some indication of the current busyness of the link
(perhaps enabled by a command line option because I expect it to chew disk
space, perhaps with a file name where the data will be written). Its
possible
this would be better done with an rmon probe, but if I can get everything I
want in one tool so much the better! Essentially a field that says "in the
last minute the link was %90 utilized" so that we can see the extent of
traffic
peaks after the fact. As I say there are other tools that will do this, but
being able to do it in a single box and record that traffic flows were
active
at the time would be (I think) unique. It would allow dropping an argus box
on
a segment and finding both traffic peaks and what caused the peak over
extended
periods of time (which rmon probes won't do because of a lack of flow
compression and memory if they are capturing packets).