Re: asa netflow vs switch flexible netflow
"Warren Daly (OPUS)" <[email protected]>
| Newsgroups | gmane.linux.ntop.general |
|---|---|
| Message-ID | <[email protected]> |
Thank you. This simplifies the config and is a great new feature. ~W On 08/03/17 19:13, Simone Mainardi wrote: > Hi, > > On Wed, Mar 8, 2017 at 12:10 PM, Warren Daly (OPUS) > <[email protected] <mailto:[email protected]>> wrote: > > Hi Matt, > I run several ASA5510 and ASA5505 Firewalls running 9.1.7+ and > they're all sending V9 Netflow streams to several NProbe > collectors on 1 server (they listen on different ports) NTOPNG is > running on the same machine. This allows me to view different > 'interfaces' so I can view traffic i/o on the various ASAs. > > I would be really interested in seeing/comparing flows if you sent > flows from FNF to 1 instance of Nprobe, and flows from V9 from the > ASA to another instance of Nprobe (this is similar to my setup of > using multiple Nprobe collectors all running on different ports. > > From the Cisco docs..."NetFlow version 9 is a flexible and > extensible NetFlow format used by Flexible NetFlow" So I'm really > interested in finding out how and why Flex Netflow differs from > Netflow V9. I thought it was just marketing department stuff... > but it seems you might have spotted a huge difference. > > Sorry, you probably know this already.. but FYI > My ntop config shard is > > -i=tcp://127.0.0.1:5555 <http://127.0.0.1:5555> > -i=tcp://127.0.0.1:5556 <http://127.0.0.1:5556> > -i=tcp://127.0.0.1:5557 <http://127.0.0.1:5557> > -i=tcp://127.0.0.1:5558 <http://127.0.0.1:5558> > -i=tcp://127.0.0.1:5560 <http://127.0.0.1:5560> > -i=tcp://127.0.0.1:5561 <http://127.0.0.1:5561> > -i=tcp://127.0.0.1:5563 <http://127.0.0.1:5563> > -i=tcp://127.0.0.1:5564 <http://127.0.0.1:5564> > -i=tcp://127.0.0.1:5565 <http://127.0.0.1:5565> > -i=tcp://127.0.0.1:5566 <http://127.0.0.1:5566> > > and then I start nprobe several times... > > nprobe --zmq tcp://*:5555 -i none -n none --collector-port 2055 > nprobe --zmq tcp://*:5556 -i none -n none --collector-port 2056 > nprobe --zmq tcp://*:5557 -i none -n none --collector-port 2057 > nprobe --zmq tcp://*:5558 -i none -n none --collector-port 2058 > nprobe --zmq tcp://*:5559 -i none -n none --collector-port 2059 > nprobe --zmq tcp://*:5560 -i none -n none --collector-port 2060 > nprobe --zmq tcp://*:5561 -i none -n none --collector-port 2061 > nprobe --zmq tcp://*:5562 -i none -n none --collector-port 2062 > nprobe --zmq tcp://*:5563 -i none -n none --collector-port 2063 > nprobe --zmq tcp://*:5564 -i none -n none --collector-port 2064 > nprobe --zmq tcp://*:5565 -i none -n none --collector-port 2065 > nprobe --zmq tcp://*:5566 -i none -n none --collector-port 2066 > > and on my ASA1 I send to 192.168.x.x port 2055, ASA2 I send to > 192.168.x.x port 2056 etc.. etc.. > > > In the latest ntopng dev we have added a feature that creates new > interfaces on the basis of the exporter ip address. This means that > you no longer need to spawn multiple nprobe instances. You you can > point all your routers to a single nprobe instance and then enable the > dynamic interface creation from the ntopng preferences page. > > You only have to make sure nprobe is sending EXPORTER_IPV4_ADDRESS > template field. > > > > On 08/03/17 15:55, Matt Kettler wrote: >> >> 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] >> <mailto:[email protected]> >> <[email protected]> >> <mailto:[email protected]> on behalf of Luca Deri >> <[email protected]> <mailto:[email protected]> >> *Sent:* Wednesday, March 8, 2017 1:23 AM >> *To:* [email protected] <mailto:[email protected]> >> *Cc:* [email protected] <mailto:[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.* *THEINFORMATION 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 >>> <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] <mailto:[email protected]> >> http://listgateway.unipi.it/mailman/listinfo/ntop >> <http://listgateway.unipi.it/mailman/listinfo/ntop> > _______________________________________________ Ntop mailing list > [email protected] <mailto:[email protected]> > http://listgateway.unipi.it/mailman/listinfo/ntop > <http://listgateway.unipi.it/mailman/listinfo/ntop> > _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop