Thank you Luca, but you basically just summarized everything I already know, 
and kind of missed the question I was asking.


Is the implementation of netflow on a Cisco 3xxx switch any better from 
nprobe's perspective than the ASA?


When you say "move to nprobe", I'm already using nprobe. AFAIK, it is 
impossible to avoid using nprobe when collecting netflows, unless you're using 
span ports. ie: you can't send netflow from an ASA directly to ntopng. You have 
to send it to nprobe for translation..


If by "move to nprobe" you mean using a span port to allow nprobe directly 
collect ethernet frames, that isn't even something I'm considering. If I bother 
to set up a span port I may as well just have ntopng directly ingest the 
packets.


My two situations are:


ASA Netflow -> nprobe -> ntopng


vs


Cisco Switch Flexible Netflow -> nprobe -> ntopng


I'm not proposing this configuration, which you seem to be referring to as 
"nprobe":


Cisco switch span port -> nprobe -> ntopng


​

________________________________
From: [email protected] <[email protected]> on 
behalf of Luca Deri <[email protected]>
Sent: Wednesday, March 8, 2017 1:23 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [Ntop] asa netflow vs switch flexible netflow

Hi Matt
ASA (like PaloAlto and many others) are firewall devices that emit flows when 
the flow starts and when the flow ends, this adding a verdict (e.g. pass or 
drop according to firewall rules). ASA is a family of devices and not all area 
alike, so configuration and ASA model can make quite some difference. The flow 
format (enclosed an example) is kind of incomplete (e.g. there is no begin/end 
of a flow but just the event time) but the main problem is that the device does 
not send periodic flow updates, so in essence you are blind until the flow 
arrives and when that happens the bytes/pkts stats are broken because the flow 
bytes needs to be spread backwards, making things complicated in particular for 
long flows

So with flow-devices that are following the standard such as nProbe you have 
near-realtime (near because netflow aggregates packets so you have a flow 
exported every X sec, and thus you have an average values compared to pure 
packet based apps such as ntopng) stats and better visibility compared to ASA. 
This said nProbe/ntopng also support ASA flows so you have the freedom to 
decide if you want to stay with ASA or move to nprobe

Regards Luca

On 8 Mar 2017, at 05:31, Matt Kettler 
<[email protected]<mailto:[email protected]>> wrote:

I asked part of this question previously, but it was buried in another thread 
where I was trying to fix problems.

I'm currently exporting netflows from an asa and using nprobe on an evaluation 
basis to zmq that to ntopng.

However, I'm reading the ASA's implementation of netflow isn't exactly "flow" 
oriented, but more based on network security events, so there's no mid-flow 
updates, etc.

While it seems like router platforms are "best" for netflow with ntop, I don't 
really have one in a useful place in my network. I could however reconfigure to 
use a cisco switch to generate netflow data and use that. I've got a recent 
model cisco 3xxx series switch with ipbase licensing, which is capable of 
flexible netflow.

Beyond the obvious differences in network visibility caused by using a 
different device, are there advantages to flexible netflow on the switch 
platforms compared to the ASA platform? Is the FNF implementation on the 
current 3xxx series models comparable with the implementation on router 
platforms, at least in terms of how "normal" the flows look to ntopng?

Would there be any problems/benefits with bringing both back to ntopng? If so, 
would you do it with separate nprobe instance feeding a separate zmq to ntopng, 
or just bring it to the same probe?









*This e-mail is intended solely for the addressee. Access to this email by 
anyone else is unauthorized. If you have received this e-mail in error, please 
notify the sender immediately, delete the e-mail from your computer and do not 
copy or disclose it to anyone else.* 
*THE[cid:F94B7907-C848-458F-9165-2A941A400921]INFORMATION IN THIS EMAIL AND ANY 
ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION 
ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on it, is prohibited and may be unlawful. 
Fourth Dimension is not responsible for any damages caused by your unauthorized 
use of the materials in this e-mail.
_______________________________________________
Ntop mailing list
[email protected]<mailto:[email protected]>
http://listgateway.unipi.it/mailman/listinfo/ntop

*This e-mail is intended solely for the addressee. Access to this email by 
anyone else is unauthorized. If you have received this e-mail in error, please 
notify the sender immediately, delete the e-mail from your computer and do not 
copy or disclose it to anyone else.* *THE INFORMATION IN THIS EMAIL AND ANY 
ATTACHMENTS CONSTITUTE THE PROPRIETARY INFORMATION OF FOURTH DIMENSION 
ENGINEERING, LLC.* Any disclosure, copying, distribution or any action taken or 
omitted to be taken in reliance on it, is prohibited and may be unlawful. 
Fourth Dimension is not responsible for any damages caused by your unauthorized 
use of the materials in this e-mail.
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to