argus-clients 3.0.7.1 Cisco V9 flows
Carter Bullard
carter at qosient.com
Thu Sep 27 07:33:43 EDT 2012
Hey Jon,
This looks pretty good until the Segmentation fault (core dumped).
If possible, could you run ra() under gdb(), with the same options, so we
can see where it blowing up?
To turn on gdb support, if you haven't done this yet, try (in your clients root directory),
% touch .devel .debug
% ./configure
% make clean; make
% gdb bin/ra
(gdb) run -S cisco://10.3.55.9:9996
And we'll see where the problem is.
If at the same time you can capture the port 9996 packet data, we maybe able to
recreate the problems you are getting.
Thanks !!!!!!!!!
Carter
On Sep 26, 2012, at 11:36 PM, jdenton at itcglobal.com wrote:
> Carter,
>
> Here's the results for running the basic ra -S cisco://host:port.
>
> Regards.
> Jon Denton
>
>
>> [root at syslog bin]# ./ra -S cisco://10.3.55.9:9996
>> ra[31076]: 22:24:15.616074 Binding 10.3.55.9:9996 Expecting Netflow records
>> StartTime Flgs Proto SrcAddr Sport Dir DstAddr Dport TotPkts TotBytes State
>> 14:29:02.600000 N tcp 74.125.224.70.thpth ?> 10.15.131.2.49839 13 14027 CON
>> 14:29:01.968000 N tcp 10.15.131.2.56016 ?> 206.165.250.94.thpth 3 132 CON
>> 14:29:02.596000 N tcp 10.15.131.2.49840 ?> 74.125.224.70.thpth 13 1454 CON
>> 14:29:02.600000 N tcp 74.125.224.70.thpth ?> 10.15.131.2.49840 18 18766 CON
>> 14:29:18.132000 N tcp 88.208.52.174.thpth ?> 10.15.131.2.56034 17 17716 FIN
>> 14:29:18.132000 N tcp 88.208.52.174.thpth ?> 10.15.131.2.56035 4 401 FIN
>> 14:29:00.052000 N tcp 10.15.131.2.56011 ?> 77.247.179.176.thpth 5 687 FIN
>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56026 51 60034 FIN
>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56027 46 53753 FIN
>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56028 51 60236 FIN
>> 14:29:13.844000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56029 38 44091 FIN
>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56024 37 40468 FIN
>> 14:29:14.680000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56030 4 872 FIN
>> 14:29:38.504000 N tcp 173.194.56.139.thpth ?> 10.15.131.2.49823 1 79 RST
>> 14:29:13.808000 N tcp 69.4.225.46.thpth ?> 10.15.131.2.56025 45 50987 RST
>> 14:29:31.864000 N tcp 10.15.131.2.49823 ?> 173.194.56.139.thpth 2 80 RST
>> 14:29:41.880000 N tcp 96.8.80.129.thpth ?> 10.15.131.2.49810 1 40 RST
>> 14:29:22.260000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56042 4 872 RST
>> 14:29:02.620000 N tcp 10.15.131.2.56018 ?> 8.26.196.126.thpth 69 3829 RST
>> 14:28:58.360000 N tcp 10.15.131.2.56006 ?> 88.208.52.174.thpth 12 1153 RST
>> 14:29:43.376000 N tcp 204.8.40.44.46106 ?> 10.15.131.2.27302 2 1500 RST
>> 14:29:43.376000 N tcp 10.15.131.2.27302 ?> 204.8.40.44.46106 1 40 RST
>> 14:29:44.204000 N tcp 204.8.40.44.43379 ?> 10.15.131.2.timbu* 2 1500 RST
>> 14:29:44.204000 N tcp 10.15.131.2.timbu* ?> 204.8.40.44.43379 1 40 RST
>> 14:29:14.676000 N tcp 10.15.131.2.56031 ?> 69.4.225.47.thpth 2 92 RST
>> 14:29:14.680000 N tcp 69.4.225.47.thpth ?> 10.15.131.2.56031 1 40 RST
>> 14:28:59.716000 N tcp 10.15.131.2.56007 ?> 88.208.52.174.thpth 6 874 CON
>> 14:29:46.948000 N tcp 74.125.224.73.thpth ?> 10.15.131.2.49821 2 120 RST
>> 14:29:15.872000 N tcp 10.15.131.2.56033 ?> 206.165.250.94.thpth 3 132 RST
>> 14:29:47.376000 N tcp 74.125.224.66.thpth ?> 10.15.131.2.49818 2 120 RST
>> 14:29:47.576000 N tcp 74.125.224.66.thpth ?> 10.15.131.2.49824 2 119 RST
>> 14:29:47.676000 N tcp 74.125.224.109.thpth ?> 10.15.131.2.49825 2 120 RST
>> 14:29:47.836000 N tcp 74.125.224.143.thpth ?> 10.15.131.2.49826 2 120 RST
>> 14:29:02.620000 N tcp 10.15.131.2.56019 ?> 8.26.196.126.thpth 3 132 RST
>> 14:29:18.412000 N tcp 10.15.131.2.49842 ?> 96.8.80.129.thpth 5 620 RST
>> 14:29:18.416000 N tcp 96.8.80.129.thpth ?> 10.15.131.2.49842 4 1674 RST
>> Segmentation fault (core dumped)
>> [root at syslog bin]#
>
>
> On 09/26/2012 08:07 PM, Jon Denton wrote:
>>
>> Carter,
>>
>> I'll give it a try and send the results.
>> I have a system sending v9 flows as a test.
>> Will check the pcap for template packets.
>>
>> Regards,
>>
>> Jon Denton
>> Director - Technology
>> ITC Global
>>
>> ----- Reply message -----
>> From: "Carter Bullard" <carter at qosient.com>
>> To: "Jon Denton" <jdenton at itcglobal.com>
>> Cc: "<argus-info at lists.andrew.cmu.edu>" <argus-info at lists.andrew.cmu.edu>
>> Subject: [ARGUS] argus-clients 3.0.7.1 Cisco V9 flows
>> Date: Wed, Sep 26, 2012 18:25
>>
>>
>>
>> Hey jdenton,
>> The netflow v9 support in argus-clients-3.0.7.2 , should work fine, but there is
>> one report that indicated failure. However, we never got a packet file that
>> could replicate the problems that were reported.
>>
>> What we need is more testing, and if there are problems, getting a good packet
>> capture of netflow v9 traffic, including the template packets, will help us fix
>> the bugs.
>>
>> This should work with the newest clients:
>> ra -S cisco://host:port
>>
>> Once ra() gets some templates, then it should decode the flows. The host:port
>> would be the same that were used to configure the router to send the flows data.
>>
>> Prior reports had bad timestamps, and core dumping, so it should be pretty
>> obvious if you get the same results.
>>
>> Any help in this area would be greatly appreciated.
>>
>> Carter
>>
>> On Sep 26, 2012, at 1:26 PM, "jdenton at itcglobal.com" <jdenton at itcglobal.com> wrote:
>>
>> > To All,
>> >
>> > Working on Cisco V9 flows with Argus capture and decoding.
>> > Saw a thread on trying to decode, I have a network that is generating
>> > Cisco V9 flows and sending to a local server port 9996.
>> > I can grab the raw stream with tshark to verify receipt but was
>> > looking for direction on tracking down the decoding issue.
>> >
>> > Is anyone working on a debug of this? What is needed to recompile
>> > the argus clients in debug mode so I can use gdb?
>> >
>> > May be able to provide raw pcaps of the traffic after scrubbing the
>> > public IP addresses.
>> >
>> > Our goal is the use argus to capture flows from various networks across a
>> > geographically diverse area, filter and if possible use radium to send
>> > the filtered streams
>> > to a centralized Scrutinizer flow collector.
>> >
>> > Regards,
>> > jdenton
>> >
>> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120927/90a131ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120927/90a131ef/attachment.bin>
More information about the argus
mailing list