[PATCH] Re: Using the argus server as a NetFlow listener

[Terry Burton]

On 10/24/07, Carter Bullard <carter at qosient.com> wrote:
> Thanks for the patches.  I'll take a look and integrated as needed.
> The -d option on radium "toggles" the daemon flag, so if the
> /etc/radium.conf file has the DAEMON variable set to "on", then
> the -d option will turn it off, so check that.

Hi Carter,

I noticed that was the case but that the behaviour differed from that of argus.

> I know you had the -X option, so I'll make sure that the
> DAEMON flag setting is cleared when you use the -X option.

Excellent, that would seem to be the best solution. Thanks.

> If you have any problems, don't hesitate to send to the list.

A short while after running radium -X -C -S 1006 I noticed that the
receive queues for the sockets bound to the NetFlow port had grew to
their maximum size without radium occupying any notable CPU resource.

Upon investigating I found that the ArgusReadStream function was
invoking ArgusReadCiscoDatagramSocket which reads via recvfrom only
one single message/packet from the NetFlow UDP socket. After this
ArgusReadStream exits and radium sleeps for some ~0.5sec interval.
Since our router generates significantly more netflow packets than
~2/sec, the incoming UDP queue is not consumed fast enough to keep up.

Presumably there ought to be a conditional loop around the either the
recvfrom or select system calls for this socket to detect the
instances when a single read is insufficient to entirely drain the
queue. Since I am unsure at what level you would think that this
conditional should be placed (ArgusReadCiscoDatagramSocket,
ArgusReadStream, or even further out) I have not attempted to fix this
myself.

Please let me know if I am thinking along the right lines and if you
would like me to provide any further information or testing for this.


Warm regards,

Tez