ramon functionality
Peter Van Epp
vanepp at sfu.ca
Tue Oct 15 23:05:23 EDT 2002
My first question would be how much output does ra give you? Is it
possible the sort (which used to occur in memory) is running out of memory?
Try it on a small capture file and see if that works better (if you haven't
already of course :-)).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
>
> On Tue, Oct 15, 2002 at 10:38:01AM -0400, Carter Bullard wrote:
> > Hey Andrew,
> > There is a new argus-clients beta distribution that
> > has the upgrades to ramon() to do what was described below.
> > ftp://qosient.com/dev/argus-2.0/argus-clients-2.0.6.beta.35.tar.gz
> > Please give this a run, and tell me if it does the trick.
>
> Umm, I've tried:
>
> ramon -M TopN -r ./2002-09-01 - host myhost
>
> and
>
> ramon -M TopN -r ./2002-09-01 - net mynet/24
>
> and I don't get any output back.
>
> ra -r ./2002-09-01 - net mynet/24 does produce output.
>
> Andrew
>
> > 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: owner-argus-info at lists.andrew.cmu.edu
> > [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of Carter
> > Bullard
> > Sent: Tuesday, October 15, 2002 8:45 AM
> > To: 'Andrew Pollock'
> > Cc: 'Argus'
> > Subject: ramon functionality
> >
> >
> > Hey Andrew,
> > You want to use the '-M TopN' option of ramon(). I've included a few
> > runs below. Be sure and use the clients that are in the new
> > argus-clients package. They are the latest and greatest, and it's the
> > one that I'll rework first. Currently its:
> >
> > ftp://qosient.com/dev/argus-2.0/argus-clients-2.0.6.beta.34.tar.gz
> >
> > Here are runs for the existing ramon() against some anonymized data.
> >
> > ramon -M topn -r /tmp/argus.anon - host 197.0.1.1
> > StartTime Addr InPkt OutPkt InBytes
> > OutBytes
> > 09/13.10:42:50.293598 197.0.1.1 3866 3838 878095
> > 289926
> > 09/13.10:42:50.293598 197.0.1.2 3702 3703 270787
> > 856917
> > 09/13.11:41:51.934615 197.0.1.7 97 127 10201
> > 13142
> > 09/13.11:03:51.057003 1.0.3.1 28 25 7982
> > 6926
> > 09/13.10:42:53.647434 197.0.1.3 5 5 416
> > 570
> > 09/13.10:53:06.147341 100.0.1.1 3 3 270
> > 270
> > 09/13.10:53:07.146460 197.0.4.1 3 3 270
> > 270
> >
> > The output includes stats for all the machines that are involved so you
> > can see the breakdown, but if you add up the counts, you'll
> > see double counting. That does make sense?
> >
> > I'm making the changes so that the output can be processed using the
> > input filter, so you would only get one stat.
> >
> > ../bin/ramon -M topn -r /tmp/argus.anon - host 197.0.1.1
> > StartTime Addr InPkt OutPkt InBytes
> > OutBytes
> > 09/13.10:42:50.293598 197.0.1.1 3866 3838 878095
> > 289926
> >
> > Is this preferable, or the original?
> >
> > To specify a net, we already support CIDR masking in the input filters,
> > and the aggregation as well, but specifying an arbitrary mask on the
> > command line and getting it into the aggregation configuration is an
> > interesting issue. This is what you would get if you ran the stock
> > ramon() against a net filter.
> >
> > ramon -M topn -r /tmp/argus.anon - net 197.0.1.0/31
> > StartTime Addr InPkt OutPkt InBytes
> > OutBytes
> > 09/13.10:42:50.293598 197.0.1.1 3866 3838 878095
> > 289926
> > 09/13.10:42:50.293598 197.0.1.2 3702 3703 270787
> > 856917
> > 09/13.11:41:51.934615 197.0.1.7 97 127 10201
> > 13142
> > 09/13.11:03:51.057003 1.0.3.1 28 25 7982
> > 6926
> > 09/13.10:42:53.647434 197.0.1.3 5 5 416
> > 570
> > 09/13.10:53:06.147341 100.0.1.1 3 3 270
> > 270
> > 09/13.10:53:07.146460 197.0.4.1 3 3 270
> > 270
> >
> > My monitor is on a hub, so this a mix of local hosts
> > talking to each other as well as remote hosts. If I wanted
> > to just get remote talking to local, I could either use
> > the "gateway host" filter, or I could use a filter like:
> >
> > ((src net x.y.z.w/mask and dst net not x.y.z.w/mask) or
> > (dst net x.y.z.w/mask and src net not x.y.z.w/mask))
> >
> > Here is what I'm proposing the modified ramon() should generate:
> >
> > ../bin/ramon -M topn -r /tmp/argus.anon - net 197.0.1.0/30
> > StartTime Addr InPkt OutPkt InBytes
> > OutBytes
> > 09/13.10:42:50.293598 197.0.1.1 3866 3838 878095
> > 289926
> > 09/13.10:42:50.293598 197.0.1.2 3715 3745 274623
> > 861925
> > 09/13.10:42:53.647434 197.0.1.3 2628 2351 710476
> > 730027
> >
> > Since it would filter the output records to match the filter.
> >
> >
> > And by adding a net/mask mode, you would get something like (notice
> > different mask value):
> >
> > ../bin/ramon -M topn -M net/31 -r /tmp/argus.anon - net 192.0.1.0/31
> > StartTime Addr InPkt OutPkt InBytes
> > OutBytes
> > 09/13.10:42:50.293598 197.0.1.0 3866 3838 878095
> > 289926
> >
> >
> >
> > -----Original Message-----
> > From: Andrew Pollock [mailto:andrew at andrew.net.au]
> > Sent: Tuesday, October 15, 2002 1:46 AM
> > To: Carter Bullard
> > Subject: Re: Filter rule confusion
> >
> >
> > On Tue, Oct 15, 2002 at 01:32:24AM -0400, Carter Bullard wrote:
> > > Hey Andrew,
> > > Not a pain at all. The problem is that you're
> > > interested in RMON like statistics, inbound/outbound counters, but
> > > you're using bi-directional flow data to construct it. Not a problem,
> >
> > > but it does take some adjustments.
> > >
> > > For all traffic A <-> B, if you calculated the inbound/outbound
> > > stats for A and B, you end up counting all the packets twice, since an
> >
> > > inbound packet for A is an outbound packet of B. Bi-directional flow
> > > data, on the other hand, accounts for the same stats, but only counts
> > > the packets once. This is a great property for auditing, but somewhat
> >
> > > complicated when you want to derive RMON style stats. This is where
> > > the utility ramon() comes in.
> > >
> > > In order to calculate inbound and outbound counters for
> > > a single entity, you need to collect all the records that have your
> > > address as either the source or the destination. You need to then
> > > throw away the reference to second address in the flow description and
> >
> > > then aggregate the records together, in such as way that preserves the
> >
> > > inbound/outbound semantic.
> > >
> > > ramon() does this by duplicating all its input argus records, and
> > > modifies them to calculate RMON stats. With the first copy of the
> > > records, ramon() retains the metrics, but zero's out the dst address.
> >
> > > With the second copy, it flips the addressing data and metrics, and
> > > then zero's out the dst address. This gives you records that have
> > > counters referenced by a single address. Then by aggregating the
> > > collection of records together, you can generate the basic RMON stat.
> >
> > Can you give me a sample of how I'd invoke ramon using a single IP
> > address
> > (lets just say I want to use a single address out of the /24 I used in
> > my
> > example)?
> >
> > > Unfortunately you're currently looking for a stat that ramon()
> > > doesn't generate, CIDR address based counting. Ramon basically gives
> > > you address based counting, with no masks, but it can be added in less
> >
> > > than an hour, so no problem. Do you see a need to provide arbitrary
> > > CIDR addressing (any mask length), or would you be satisfied with
> > > Class oriented inbound/outbound accounting? The first is a little
> > > hard, the second is trivial.
> >
> > I am going to need variable mask length, I'm sorry to say.
> >
> > Thanks yet again for your quick assistance.
> >
> > Andrew
> >
> >
> >
>
More information about the argus
mailing list