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