ramon functionality
Andrew Pollock
andrew-argus at andrew.net.au
Tue Oct 15 22:57:21 EDT 2002
On Tue, Oct 15, 2002 at 10:33:51PM -0400, Carter Bullard wrote:
> Hey Andrew,
> Well, I'll need a bit more information than that.
> Does
> ramon -M topn -r ./2002-09-01
>
> generate any output?
Yes it does.
> Carter
>
>
>
> -----Original Message-----
> From: Andrew Pollock [mailto:andrew-argus at andrew.net.au]
> Sent: Tuesday, October 15, 2002 10:21 PM
> To: Carter Bullard
> Cc: 'Argus'
> Subject: Re: ramon functionality
>
>
> 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