Argus 3.0.6.1/2 on BiviOS 5.1.6 issues

[Carter Bullard]

Hey Eric,
These messages are saying that radium is connecting to the various
argus instances, but it never requests data from the argus.
The argus transport protocol is pretty simple, you connect to argus,
it sends an argus management record to the client, that has a bunch
of information about what it is, how often it sends management records,
if it requires security, etc…  Radium, has the option of sending a filter,
to argus (remote filtering), or requesting data outside of the current
data stream, but if all is ready, radium should send a "START" to argus.
Once argus gets the "START", it blow argus records down the pipe.

So we normally have a 10 second timer before we time out the
session, but you don't seem to be waiting at all.

> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.028468
> connect from CPU-X
> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.029010
> ArgusCheckClientMessage: client (null) never started: timed out

So you waited approximately 500 uSec.  We should take out the
check or extend the time.  Not sure how this could be screwing up,
but let me see what code to comment out to see if we can get it to work.

Carter

On Jun 19, 2012, at 1:32 PM, Eric Gustafson wrote:

> Hi Carter and friends,
> I saw in a recent email to the list that there are some Bivio-related
> Argus fixes coming, but I wasn't sure if this was related or not.
> Here's the backstory:
> Recently, our Bivio tech upgraded a few of our Bivio 7500 boxes to the
> latest rev of BiviOS, moving us from 5.1.4 to 5.1.6 to take care of
> security patches.  This, unfortunately, seems to have broken Argus,
> and both versions 3.0.2 and 3.0.6.1 (pre-6/15, I believe) were unable
> to capture any traffic from the 10G fiber interface.
> After consulting the mailing list archive, I grabbed, right before
> your announcement this morning, the latest argus and argus-clients,
> dated 6/15. I can, intermittently, grab data from the argus daemon
> running on each application CPU, but it otherwise produces errors like
> the ones I pasted below.
> 
> Our boxes are set up in what I assume is the typical fashion, with
> argus running on each Bivio application CPU, and radium running on
> CPU-X to merge all the flows together.
> If this helps any, the box we're testing currently is plugged into a
> rather noisy but not saturated 10G fiber link.  It also happens to be
> listening just outside a firewall, so there are a _lot_ of small flows
> from stuff that eventually gets blocked.
> 
> Here are the sort of log messages we get when starting radium or ra:
> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.028468
> connect from CPU-X
> Jun 19 10:13:08 CPU-1c0 argus[29290]: 19 Jun 12 10:13:07.029010
> ArgusCheckClientMessage: client (null) never started: timed out
> Jun 19 10:13:09 CPU-1c1 argus[29120]: 19 Jun 12 10:13:08.554611
> connect from CPU-X
> Jun 19 10:13:09 CPU-1c1 argus[29120]: 19 Jun 12 10:13:08.555118
> ArgusCheckClientMessage: client (null) never started: timed out
> 
> Let me know if you need any more info.
> 
> Thanks,
> - Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120619/278765cc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120619/278765cc/attachment.bin>