argus-clients- on the server - Netflow -V9

David Edelman dedelman at
Tue Dec 18 23:34:31 EST 2012


Do you have packet capture for all or part of the traffic that you are
collecting with Netflow?

I have seen the protocol field indicate IPv6 for some of the tunnel based
transition mechanisms. Using Argus as a collector, I do see all sorts of
IPv6 traffic but I don't have an IPv6 Netflow source available at the
moment so I can't give you anything more than the pointer about the


On 12/19/12 1:10 AM, "Nichole K. Boscia" <Nichole.K.Boscia at> wrote:

>Hi Carter,
>I am looking at using argus to do long-term storage of our netflow v9
>This version is running without seg faults, so that appears all and well.
>question is:  does this version support IPv6?  I've been running it for
>today and I've seen no v6 addresses.  I have my primary netflow export
>going to 
>a commercial tool and the v6 records show up there so I know the problem
>with netflow itself.
>What I'm doing to look is just running 'ra -n -S cisco://any:9996 | grep
>since 2001 is the prefix for all the addresses. If I grep ipv6 in the
>field, I get matches on that, but the addresses themselves are just
>showing up 
>as IPv4 addresses, for example:
>    16:02:56.525000 N           ipv6           ->
>          393255          1   REQ
>I see no actual ipv6-formatted addresses anywhere being captured.
>Does anyone else have IPv6 captures working? Pardon my ignorance on this
>if it's 
>something simple I'm missing. Argus is new to me so I've just been in the
>learning process.
>Nichole K. Boscia
>Senior Network Engineer, CSC
>NASA Advanced Supercomputing Division
>Ames Research Center, Moffett Field, CA 94035
>On Thu, 13 Dec 2012, Carter Bullard wrote:
>> Date: Thu, 13 Dec 2012 09:28:03 -0600
>> From: Carter Bullard <carter at>
>> To: jdenton <jdenton at>
>> Cc: "<argus-info at>"
>><argus-info at>
>> Subject: Re: [ARGUS] argus-clients- on the server  - Netflow -V9
>> Hey John,
>> We extract the time from the netflow v9 flow records themselves, which
>>can be minutes ( I've seen hours ) behind.  The router that generates
>>the nfv9 records, provides the
>> timestamps, so it must be sync'd somehow to real time.  Netflow doesn't
>>deliver records timely, so there are situations where you could get a
>>flow record from days earlier.
>> Racluster doesn't modify time, it choses the min and max times for each
>>direction, from the records its aggregating, to report the time bounding
>> Your png doesn't look bad.  Looks like racluster() is sorting based on
>>the key, saddr, daddr, so it all looks pretty ok ?
>> Carter 
>> On Dec 12, 2012, at 6:07 PM, jdenton <jdenton at> wrote:
>>       Hi Carter,
>>       We have the "ra" client running with a V9 netflow.
>>       - so far so good, no seg faults.
>>       We are seeing a time differential in the stime versus server
>>       Server time ~ 15:00 CST is when the command "ra -S
>>cisco://any:9996 -w netflow-ra-2012Dec12.arg"
>>       is issued with the racluster cmd tested 30-45 minutes after. (
>>1530 ~ 1545 )
>>       Shouldn't we expect a 1500 ~ 1600 range for the StartTime from
>>the racluster output?
>>       How is a 'timestamp' for stime or ltime defined/extracted for the
>>V9 flow??
>>       Regards,
>>       Jon
>>       <fgecgjeg.png>
>>       On 12/7/12 9:49 AM, Carter Bullard wrote:
>>  Gentle people,
>> I've uploaded the new development image of the argus clients.  This
>> all the issues that have been presented on the email list, that I am
>>aware of,
>> and adds color support for ratop().
>> This version has significant bug fixes for netflow v9.  At this point,
>>I believe that
>> ra* reading of netflow v9 is fully functional and working well.  But we
>>still need
>> more testing, use, so If you have any problems, please send email, as
>> support is important to more than a few.
>> ratop() is a complete rewrite, with more threads, better curses library
>> better use of editline or readline, and better functionality when
>>neither  are
>> available.  AND, of course, COLOR !!!!  The ./support/Config/rarc has
>>all the
>> variables needed to use color, and there is a sample racolor.conf file
>> Paths to this file is important, so when you decide to use color, play
>>with the
>> rarc and racolor.conf, to see what works for you.
>> Documentation is not complete, but as you guys point out problems, I'll
>> as I can.  After we get the documentation developed a bit, I'll work
>> releasing argus[-clients]-3.0.8.
>> Many, many small bug fixes, PCRE support, better readline library
>> and use, so lots to digest, but like all releases, this should be
>> backward compatible with prior versions of argus data, etcŠ.
>> Please take a look, and send any comments, reactions, opinions and of
>> results !!!!  If your bug, or issue, has not be resolved, please send a
>>note to
>> either me, or the list, and I'll address it.
>> Hope all is most excellent,
>> Carter

More information about the argus mailing list