argus and Netflow

Mon Nov 26 19:43:14 EST 2012

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/20121126/da189698/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/20121126/da189698/attachment.bin>