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

[Carter Bullard]

Hey Tez,
Hmmmmm, well that's not right.  So, how are you calling radium()?
Exactly as you have it in your email?  Just so I know all the options
so I can replicate the problem here.  Intel? Linux?

This was working fine not long ago, so its probably a minor nit,
as its  not suppose to sleep in ArgusReadStream if there is
data to read.  ArgusReadCiscoDatagramSocket() should return
something if there is success?

Sorry for the inconvenience, and thanks for the email.  I'll get on
it this weekend, this afternoon.

Carter


On Oct 26, 2007, at 11:58 AM, Terry Burton wrote:

> 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
>