argus to tcpdump conversion

[Carter Bullard]

Hey Scott,
   Hmmmm, this should work fine.  If not, we should fix it
so that it does work.  This filter should generate a class
C address matrix broken out by protocol.  This works for
me all the time no problem.

So you expect more or less than 600 output records?

The counters are 32 bit, but ragator will not overflow a
counter.  If it thinks that merging a record will overflow
a value, it will "send" the record out, and start over.
So you may get multiple records per day for the same matrix
entry, if there is overflow.

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

-----Original Message-----
From: Scott A. McIntyre [mailto:scott at xs4all.nl] 
Sent: Thursday, June 14, 2001 11:43 AM
To: Carter Bullard
Cc: argus-info at lists.andrew.cmu.edu
Subject: Re: argus to tcpdump conversion



> Scott,
>    Seems like the list is back.  Hmmm, well this is something


Heh, I thought it was a bit quite in this folder -- glad it wasn't just
me.

In this particular case, better use of ragator may allow me to perform
what it is I want to perform.  I have a day's worth of Argus data and
want to know every /24 with every other /24.  Unfortunately, with my
flow file (see below), I only end up with about 600 records, which
definitely not the case.

#label   id    SrcCIDRAddr     DstCIDRAddr  Proto  SrcPort  DstPort
ModelList  Duration
Flow     100       *                *         *        *        *
200      86400

#label   id    SrcAddrMask      DstAddrMask         Proto  SrcPort
DstPort
Model    200   255.255.255.0       255.255.255.0   yes     no      no

I had assumed that a duration of 86400 (a day's worth of seconds) would
summarise all of the traffic for the entire day by the netmask specified
in the Model.

The data I need is to know how much data was sent from one network to
any other network during an entire day -- and I have 24 seperate flow
files involved (hourly rotation).

Since we already have tools for doing this type of analysis with tcpdump
formatted files, my original thought was just to revert to those.

The other issue that has come up is how long the counters are, and how
often they wrap.  Initial investigation appeared to suggest that we were
looking at 32 bit counters and were indeed wrapping, but I didn't
investigate too far.

Certainly open to other ideas.

Thanks,

Scott