ramon functionality
Carter Bullard
carter at qosient.com
Tue Oct 15 08:44:42 EDT 2002
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