rasplit idle closing
carter at qosient.com
Wed Feb 5 06:14:11 EST 2014
Idle timeout for an argus client (data reader) is caused by the client not seeing management records from the connected source.
All clients are sent the Management Status Interval, when they connect to the argus data source, and so they expect MARs, from that specific source, every status interval. If, after 3 intervals they haven't seen any, they disconnect, thinking the connection has died.
The logic is tied to the source id of the argus data source, so it should be unique, and filters can hurt you, but if it works for any reasonable time it should keep working. We use TCP, so if there is congestion, that can get you into trouble. Look at the logs for the new machine to see what maybe up. Could be as simple as a bad cable.
> On Feb 5, 2014, at 4:58 AM, Jesse Bowling <jessebowling at gmail.com> wrote:
> Built a new sensor box with my standard stack (PF_RING + argus), differing only from other builds in that I'm using latest versions (PF_RING 5.6.2, argus-126.96.36.199, argus-clients-188.8.131.52). I found that the rasplit instance I attach locally to argus appears to timeout after 10 or so minutes:
> rasplit[24738.0077daf0837f0000]: 02/04/14 22:34:56.974965 ArgusReadStreamSocket (0x7f83f0c91010) read 352 bytes
> rasplit[24738.0077daf0837f0000]: 02/04/14 22:34:58.975067 ArgusReadStreamSocket (0x7f83f0c91010) read 428 bytes
> rasplit[24738.0077daf0837f0000]: 02/04/14 22:35:16.975751 ArgusReadStreamSocket (0x7f83f0c91010) read 460 bytes
> rasplit: 02/04/14 22:37:17.016896 ArgusReadStream 10.9.28.20: idle stream: closing
> rasplit[24738.0077daf0837f0000]: 02/04/14 22:37:20.979732 ArgusCloseInput(0xf0c91010) closing
> This is a much smaller link than I usually monitor (100 Mb connection), but it seems highly unlikely that there was in fact 2 minutes without a single flow.
> Any hints on where to look for the issue?
> Jesse Bowling
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the argus