argus and Netflow
Carter Bullard
carter at qosient.com
Tue Nov 27 19:16:30 EST 2012
Hey Jon,
Thats pretty interesting, although insanely inefficient.
Do they process netflow in real-time now, or is it file based imports, as a rule?
We have netflow v5 support in all the clients now, because of the flow-tools
support that was put in 3.0.6 code, but I would have to do
some work to make it production level. All the modes are there to dumb down
the data to generate uni-directional flow records (thats the hard part by the
way, can they handle bi-directional flow data ?)
I could do v5 transmit support, pretty quickly, but I'd have to put you
on a support contract to do that, as its not in the plans
Would they suck up netflow v5 ? Would you want to be a QoSient
customer?
Carter
Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax
On Nov 27, 2012, at 5:37 PM, jdenton <jdenton at itcglobal.com> wrote:
> Hi Carter,
>
> Spoke with someone at Plixer.
> They have an agent that can be run on the same server as argus.
> The agent can read files with the network data required ( format and fields specified )
> and they will process it, format it in a IPFIX packet and send it to Scrutinizer.
>
> From my understanding, I would have to settle on what to export from the argus client
> to a Plixer file for processing.
> They have a Professional Services group that would work on the integration.
>
> I will take a parallel path of:
> a.) Setting up the argus collectors to log and generate a few standard reports
> on a local web server.
> b.) Defining a separate 'Plixer' output file to test with.
>
>
> On the v9 netflow testing:
> i have another site that we are sending netflow v9 from for testing.
> I will grab the latest argus-client to test to see if the seg-fault is still occurring.
>
> Appreciate the support,
>
> Regards,
> Jon
>
>
>
>
> On 11/26/12 6:43 PM, Carter Bullard wrote:
>> Hey John,
>> Well I am so down on IPFIX from a technical perspective, that supporting it
>> is very low on the importance list. Just as an example, after all this time,
>> they are still having problems with the concept of start and stop times for
>> flow records. Without an understanding of that simple, but massively
>> important concept, its hard to consider the technology seriously. But no
>> basic support for simple transport schemes, like multicast, makes it a
>> complete no go as a transport strategy for serious use.
>>
>> I don't have fundamental problems with netflow, so that maybe a path that
>> could get you there. We do need some more testing on the v9 support we
>> have before I start writing v9 data.
>>
>> I'd love for Plixar to read argus data, and I'd help them do that, if they need the help.
>>
>> Not sure that I can point you in a direction, as I'm not sure what Plixar can eat.
>> If I can get some idea as to what the best path would be, then I can make suggestions.
>>
>> Carter
>>
>>
>> On Nov 26, 2012, at 6:16 PM, jdenton <jdenton at itcglobal.com> wrote:
>>
>>> Hi Carter,
>>>
>>> Understand, we may go down the road to having a list of pre-generated reports on a web server complied from the argus data and
>>> jump in at the CLI to use the argus clients if something special is needed.
>>>
>>> The idea is to have several argus collectors around the world feeding upstream to two data centers, from the data centers
>>> we would filter and feed traffic to a Database server / Web GUI or Scrutinizer?
>>>
>>> I believe Plixer can read IPFIX data, will have to check on CSV ascii flow data?
>>>
>>> If you can point me in the right direction, I can see what mods are needed to feed data to Plixer.
>>> Most of my programming has been on the embedded side with Linux, but I can jump in with C or C++ where needed.
>>> ( Computer Engineer working in the Telecom industry...)
>>>
>>> Thanks,
>>> Jon
>>>
>>>
>>> On 11/26/12 4:52 PM, Carter Bullard wrote:
>>>> Hey Jon,
>>>> These kinds of GUIs are really pretty simple, but I don't want to bash Plixer, as any GUI is a
>>>> hard project to maintain, so I understand the desire to leverage it.
>>>>
>>>> Because we can do everything already with argus-client examples, the graph and the table,
>>>> I personally am not motivated to convert the data to feed Scrutinizer. Can Scrutinizer eat comma
>>>> separated ascii flow data ?
>>>>
>>>> Carter
>>>>
>>>>
>>>> On Nov 26, 2012, at 11:42 AM, jdenton <jdenton at itcglobal.com> wrote:
>>>>
>>>>> Hi Carter,
>>>>>
>>>>> I agree, argus data beats flow data any time.
>>>>> I usually use argus and ra and/or racluster to generate a Engineering level report for major issues when it escalates to our level.
>>>>> Basically we are trying to leverage existing reporting tools as a means to use argus data.
>>>>>
>>>>> For nominal usage and trending we use Plixer's Scrutinizer.
>>>>> They have a decent GUI ( a couple snapshots below) that our operational support uses.
>>>>>
>>>>> Plixer does have a second tool that I am investigating that they claim can export 'other' data. Following up with their white paper
>>>>> and a discussion with their sales engineer to see how it may fit with argus data.
>>>>>
>>>>> Here's a brief summary of the Scrutinizer screen shots below:
>>>>> 1.) Select a report that shows network traffic based on Network, Protocol, IP host or IP Range.
>>>>> - From the graphic window I can highlight a section to zoom into the traffic at that time period.
>>>>> - You can also select items in the table and run reports per item.
>>>>> - If I select the first line on the left ( Application ipsec-nat-t, Destination 204.8.40.56) I can generate a new report
>>>>> showing the 'Known ports" used for this instance. The results are in snapshot 2.
>>>>>
>>>>> 2.) From the 204.8.40.56 selection, I can see what ports are in use, their pkt/s, percent and Kb/s.
>>>>> - You can drill down deeper by selecting a time period in the graph or from an item in this table as well.
>>>>>
>>>>> Regards,
>>>>> Jon
>>>>>
>>>>>
>>>>>
>>>>> 1.)
>>>>> <jeeiaefd.png>
>>>>>
>>>>>
>>>>>
>>>>> 2.)
>>>>> <dehjghgc.png>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 11/26/12 9:13 AM, Carter Bullard wrote:
>>>>>> Hey Jon,
>>>>>> Hmmmm, so what do your other tools do that argus client tools don't do ?
>>>>>> I have found that even simple racluster() calls against argus data or even
>>>>>> netflow data can generate better reports than what's out there, but I'm biased,
>>>>>> of course.
>>>>>>
>>>>>> I'd like to work with those other tool developers to get them to use argus data,
>>>>>> not the other way around. Can I twist the conversation that way?
>>>>>>
>>>>>> Carter
>>>>>>
>>>>>>
>>>>>> On Nov 21, 2012, at 11:58 AM, jdenton <jdenton at itcglobal.com> wrote:
>>>>>>
>>>>>>> Carter,
>>>>>>>
>>>>>>> Here's a twist, can I use argus to collect data from the network, log/archive it locally, then send that data as a netflow stream
>>>>>>> to a netflow analyzer?
>>>>>>>
>>>>>>> We have multiple locations that we monitor with netflow tools and are looking at how to leverage that with argus data collection?
>>>>>>> The netflow analyzer gives us the GUI and report generation capabilities to trend by region, networks or per customer.
>>>>>>> To the flow analyzer argus would look like another flow exporter.
>>>>>>>
>>>>>>> The idea is to archive argus data for engineering trending but have a subset of that data available for other personnel
>>>>>>> to view in a known tool that is used now.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jon
>>>>>>>
>>>>>>>
>>>>>>> On 11/18/12 8:29 AM, Carter Bullard wrote:
>>>>>>>> Hey Ricardo,
>>>>>>>> Sorry for the delayed response. Yes, you use argus-client programs to collect the Netflow data, just as you collect argus data.
>>>>>>>> There is a page on the web site that talks about this, which may be a good start:
>>>>>>>>
>>>>>>>> http://www.qosient.com/argus/argusnetflow.shtml
>>>>>>>>
>>>>>>>> The syntax for the support has changed but this should work for you:
>>>>>>>>
>>>>>>>> ra -S cisco://any:9996
>>>>>>>>
>>>>>>>> Should collect whatever netflow data there is on the wire, going to port 9996, which is the default.
>>>>>>>> Can you describe a bit more why argus isn't working for you? Not sure that netflow data, is
>>>>>>>> going to be a good replacement, if you've used argus data in the past.
>>>>>>>>
>>>>>>>> Hope all is most excellent,
>>>>>>>> Carter
>>>>>>>>
>>>>>>>> Sent from my iPad
>>>>>>>>
>>>>>>>> On Nov 16, 2012, at 4:11 AM, Riccardo Veraldi <Riccardo.Veraldi at cnaf.infn.it> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> I would like to use argus to analyze netflow traffic format, but it is not very clear to me how to do it.
>>>>>>>>> Do I still need the argus daemon and to redirect netflow traffic to the machine where daemon is running,
>>>>>>>>> or simply I can run argus client on the target netflow machine ?
>>>>>>>>> Netflow traffic should be rewritten in argus format on the disk ?
>>>>>>>>> I Am sorry but I did not understand very much how to do.
>>>>>>>>> I have been using argus to monitor network traffic on mirror port since many many years, but the uplink speed
>>>>>>>>> grew to 10Gbps and this solution is no more efficent and scalable, and I must use Netflow.
>>>>>>>>> To tell the truth I am using Netflow Analyzer now but it is not so flexible as argus.
>>>>>>>>> With argus I can use my own perl scripts to search for specific traffic patterns...
>>>>>>>>>
>>>>>>>>> thank you
>>>>>>>>>
>>>>>>>>> Riccardo
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20121127/c9e5d957/attachment.html>
-------------- 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/20121127/c9e5d957/attachment.bin>
More information about the argus
mailing list