ramon functionality

Carter Bullard carter at qosient.com
Tue Oct 15 10:38:01 EDT 2002


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.

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