Filter rule confusion

[Carter Bullard]

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.

    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.

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 Andrew
Pollock
Sent: Monday, October 14, 2002 11:22 PM
To: argus-info at lists.andrew.cmu.edu
Subject: Filter rule confusion


Hi,

It would seem that I've got myself confused over flows and filter rules 
and how Argus works in general (again).

I must be totally thick.

Anyway, I have this situation:

Client network is 172.16.6/24
Argus collection point above their gateway.
Remote proxy server they use is 172.16.2.100
There are Some other external hosts that I want to exclude counting 
inbound traffic from

I want to determine all inbound traffic to this network. I've got lots
of 
lovely Argus logs from a span port on the switch that this network is 
connected to.

I would have thought that a filter rule of "dst net 10.15.6/24" and then
looking at the src bytes would have given me a broad overview of how
much
inbound traffic there was, however, it seems that I'm not looking at a
lot
of the traffic by doing this. All the traffic between the client network
and the proxy server only shows up when I use a filter rule of "src net
10.15.6/24". Given that the connections to the proxy server are always
initiated FROM the client network TO the proxy server, this does make
some
sense to me. However, I'm only interested in the inbound data as a
result
of that outbound initiated flow. How do I get this? Should I be using a
filter rule of just "net 10.15.6/24"? Do I then look at the src bytes or
dst bytes to establish how much data came in, regardless of the
direction
of the initial flow?

I thought I had this under control, from previous dumb questions, but it

seems I've haven't. It's fine for working out the inbound traffic to a 
single webserver, I've just been going "dst webserver" and then looking
at 
the src bytes, but for a gateway with lots of bidirectional traffic, I'm

at a loss again.

Sigh. Sorry to be a pain.

Andrew