argus-clients-18.104.22.168 on the server - Netflow -V9
Nichole K. Boscia
Nichole.K.Boscia at nasa.gov
Tue Dec 18 20:10:07 EST 2012
I am looking at using argus to do long-term storage of our netflow v9 records.
This version is running without seg faults, so that appears all and well. My
question is: does this version support IPv6? I've been running it for awhile
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 isn't
with netflow itself.
What I'm doing to look is just running 'ra -n -S cisco://any:9996 | grep 2001'
since 2001 is the prefix for all the addresses. If I grep ipv6 in the Proto
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 22.214.171.124 -> 126.96.36.199 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
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 qosient.com>
> To: jdenton <jdenton at itcglobal.com>
> Cc: "<argus-info at lists.andrew.cmu.edu>" <argus-info at lists.andrew.cmu.edu>
> Subject: Re: [ARGUS] argus-clients-188.8.131.52 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 values.
> Your png doesn't look bad. Looks like racluster() is sorting based on the key, saddr, daddr, so it all looks pretty ok ?
> On Dec 12, 2012, at 6:07 PM, jdenton <jdenton at itcglobal.com> wrote:
> Hi Carter,
> We have the 184.108.40.206 "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 time.
> 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??
> On 12/7/12 9:49 AM, Carter Bullard wrote:
> Gentle people,
> I've uploaded the new development image of the argus clients. This fixes
> 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 this
> support is important to more than a few.
> ratop() is a complete rewrite, with more threads, better curses library support,
> 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 provided.
> 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 fix
> as I can. After we get the documentation developed a bit, I'll work toward
> releasing argus[-clients]-3.0.8.
> Many, many small bug fixes, PCRE support, better readline library discovery
> and use, so lots to digest, but like all releases, this should be completely
> backward compatible with prior versions of argus data, etc….
> Please take a look, and send any comments, reactions, opinions and of course
> 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,
More information about the argus