argus management records

[Carter Bullard]

Gentle people,
I'm finalizing the argus management record data support and printing  
this
week, to get ready for release.   These records are very important to  
argus,
its clients and hopefully, you ;o)  I'd like to describe them here,  
to generate
some dialog so I can make sure they are doing what we need, and to
introduce some ideas for future management records.

All argus streams start with a 128 byte Start Management Record. This
helps ra* clients understand what they are reading, the version number
etc...  This allows the ra* programs to be backward compatible with all
prior versions of argus.  The basic contents are:
    Status (up, down, state)
    Probe ID (number, IPv4 address, IPv6 address, string)
    Start Time, Current Time.
    Next Seq Number (next argus record sequence number)
    Version Number (major and minor).
    Interface Type, Interface Status.
    Mar Status Report Interval, Far Status Report Interval.

And then we have stats since the last Management Record Sent:
    Pkts Recvd, Bytes Recvd
    Time drift (64-bit uSec drift).
    Number of Records Generated.
    Number of Flows Currently Being Tracked.
    Number of Records Dropped
    Number of Flow Records in Process Queue.
    Number of Flow Records in Output Queue.
    Number of Clients Attached.
    Number of Buffers Allocated.
    Number of Bytes Allocated.
    Size of configured user data length.

All this packed into 128 bytes.

The primary purpose of the "man" records is to convey argus status
to clients.  All clients, when reading from a live remote argus data
source, use the management records as "keep alives".  Thats how
they know if a data source is active or not.  If the source is dead, it
automatically disconnects, and the clients get the timer value from
the initial management record.  And from the status records, the
ra* programs can see how the argus is doing, if its queues are big,
if its interfaces are up, if its got any new clients attached,  etc...

These are also important for a client reading from a radium() based
collection tree.  A single client should be able to see status "man"
records from all the argi, and all the radii, as well.   This is why you
should have unique source id's for all your argus data generators
(argus) and generators (radium).

One of the important additional features that will be in argus-3.0.0
is the addition of extended management records, which will allow
ra* programs to do radium tree loop detection/rejection.   While
this is not a huge deal for most, loop detection is always important
when you're building complex collection trees.

Ok, so the initial management record must be 128 bytes, but
that doesn't mean that status managements records have to be
128 bytes.  Can you think of other information that would be
important to gather.  We could generate per monitored
interface stats, or we could report on the available interfaces
that could be monitored.

Radium supports the ability to read archive files directly,
but we don't have any means for radium to tell clients
what archives are available.  These would need to go in
extended management records.

Any suggestions?  Wish lists?  Opinions?

Carter