ramon functionality
Carter Bullard
carter at qosient.com
Tue Oct 15 22:33:51 EDT 2002
Hey Andrew,
Well, I'll need a bit more information than that.
Does
ramon -M topn -r ./2002-09-01
generate any output?
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