argus-clients-3.0.7.4 on the server - Netflow -V9

[David Edelman]

Nick,

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

--Dave

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

>
>Hi Carter,
>
>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        198.9.63.93           ->
> 17.0.206.175          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.
>
>Thanks!
>-Nikki
>
>---------------------------------------------------------
>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-3.0.7.4 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 ?
>> 
>> Carter 
>> 
>> On Dec 12, 2012, at 6:07 PM, jdenton <jdenton at itcglobal.com> wrote:
>>
>>       Hi Carter,
>>
>>       We have the 3.0.7.4 "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??
>>
>>       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
>>fixes
>> all the issues that have been presented on the email list, that I am
>>aware of,
>> and adds color support for ratop().
>>
>>    http://qosient.com/argus/dev/argus-clients-latest.tar.gz
>>    http://qosient.com/argus/dev/argus-clients-3.0.7.4.tar.gz
>> 
>> 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,
>> 
>> Carter
>> 
>> 
>> 
>> 
>>