ARGUS_FLOW_STATUS_INTERVAL

[Carter Bullard]

Hey Mike,
Your ArgusFarStatusInterval really should never be greater than 60  
seconds.
The interval drives how long an individual flow will be held in  
memory, and
so, holding records for an hour, when 90% only exist for 1.2-1.7  
seconds is
really not very efficient.   You will be happier with a value of 60  
or less.
Use racluster() to manage the output of argus to get the 3600  
duration flows,
if you really need them.

I've fixed the bug with the HUGE status intervals, though, so if you  
have a good
reason, .....

The default is 5 seconds, since this covers most of the flows.  I'll  
change the
documentation.

These other flow models are not all available to argus, so I'll fix  
the conf file
to reflect the actual support.

I have a great deal of experience with 10Gbps argus, and I'll try to put
together some form of 'report'.   With the new PCI-Express Endace cards,
it will become more important.

Carter



On Aug 17, 2006, at 4:47 PM, MN wrote:

>
> Hi - A couple of issues with ARGUS_FLOW_STATUS_INTERVAL:
>
> [1] in Argus 2.0, we used the (admittedly high) value of 3600.  If
> you set this in rc25, instead of summaries, the Argus log file will
> have an entry for every packet.
>
> [2] The default is listed in the text of the sample argus.conf as
> being 60 seconds, but it appears to be 5 seconds (even if one comments
> out the line ARGUS_FLOW_STATUS_INTERVAL=5).
>
> And, unrelated, the sample argus.conf file text says:
> # The argus supports a set of well known key strategies,
> # such as 'CLASSIC_5_TUPLE', 'LAYER_3_MATRIX', 'LAYER_2_MATRIX',
> # 'MPLS', and/or 'VLAN', or the argus can be configured to
> # formulate key strategies from a list of the specific
> # objects that the Argus understands.  See the man page for
> # a complete description.
>
> but there does not appear to be any such information in the man page.
>
> On another unrelated note, we are interested in hearing the
> experience of those who are monitoring 10Gb connections.  Of
> special interest is aggregating multiple 10G feeds to eliminate
> issues caused by asymmetric routing.  Budget is a definite issue.
> We've looked briefly at Gigamon.
>
> Thanks,
> - mike
>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20060818/aa12da3f/attachment.html>