'known flows' configuration file

[Russell Fulton]

On Fri, 2002-02-15 at 04:48, Carter Bullard wrote:
> Hey Guys,
>    If you implement it with filters, the filter is
> sent to the argus, and the filtering is done on the
> remote side.  If you implement it with a flow model
> such as ragator, then no, the aggregation is done
> on the local side.


Hmmmm... would it be worth implementing the aggregation on the server
end?  So that if ragator is inputting from a socket then it would/could
(I think this should be optional) ship the config file off to to server
and just disply the results.  Actually this sounds like an ra option,
ie. add a -f option to ra which sends the file to the server which kicks
off an ragator process to which it feeds the filtered records. The
ragator process then sends the records to a standard output process...

Why bother? Well imagine you are monitoring a wide area network with
sensors scattered all over the country. Then doing data aggregation on
the server makes sense.  I actually did this nearly 10 years ago using
NeTraMet when I was helping to manage Tuia (the NZ Academic & Research
network), we had meters at each site which I 'read' from my workstation
every 15 minutes.

There are time when you need to minimize the network bandwidth used by
monitoring.  We are probably more aware of these issues here where
network bandwidth is still extremely expensive.  The network I monitored
was based on frame relay and most of the links had 48Kbps CRI (yes that
is K not M).  We have come a fair way since then thank heavens but there
is still nothing akin to Internet2 in NZ, although we are working on it.

-- 
Russell Fulton, Computer and Network Security Officer
The University of Auckland,  New Zealand