argus-clients-3.0.7.4 on the server - Netflow -V9
Carter Bullard
carter at qosient.com
Wed Dec 19 01:02:01 EST 2012
Hey Nikki,
I have a new version of the netflow V9 -> argus import routines for you to test.
(got a little excited, and I think that this may do it). If you replace these two source
code files in your client distribution, you should be able to see V6 flows.
I still need to do the IPv6 ICMP flow conversions, so if this works, I'll make
the changes very quickly.
Move the included argus_import.c and argus_util.c files into your clients
./common directory, then make.
There is a bit of a potential issue with little endian architectures. We will
convert the network order 128 bit IPv6 address into an array of 4 32-bit
little endian ints. This should be correct, but you never know, so if your
IPv6 addresses look weird, then we'll have to tweak that a bit.
Carter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: argus_import.c
Type: application/octet-stream
Size: 166455 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121219/5903454f/attachment.obj>
-------------- next part --------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: argus_util.c
Type: application/octet-stream
Size: 834820 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121219/5903454f/attachment-0001.obj>
-------------- next part --------------
On Dec 18, 2012, at 11:55 PM, Carter Bullard <carter at qosient.com> wrote:
> Hey Nikki,
> We are not parsing out IPv6 netflow v9 data objects. I didn't have any IPV6 data
> to test, so that still needs to be finished. I can have something by tomorrow / Thu?
> ( very easy, just need to copy the buffers to the appropriate argus record struct ).
> Since argus supports IPv6 its just a matter of the netflow to argus conversion.
>
> Any chance you have, or could collect, a packet trace of your netflow v9 data stream,
> so I can get examples of the IPv6 flow data? Need enough packets to capture
> the templates and the flow records. If that is not possible, I'll give the implementation
> a stab and provide an argus with what should be correct IPv6 collection in a few days.
>
> Sorry for any inconvenience, hope we can knock this out shortly !!!
>
> Carter
>
>
> On Dec 18, 2012, at 8:10 PM, "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
>
-------------- 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/20121219/5903454f/attachment.bin>
More information about the argus
mailing list