On Sep 1, 2015, at 6:37 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
On 2 Sep 2015, at 3:34, Nick Hilliard wrote:
If you want to handle netflow data export for large amounts of traffic, it would be pretty dumb to push it through the management plane of the router.
Concur 100%. You must use a port capable of doing so.
My experience in running large networks is these ports often can’t handle the traffic involved. The packet path in a juniper (for example to go from the PFE -> RE -> Ethernet) is very sensitive to the jitter introduced by increased traffic loads and may result in the box becoming unstable. Other platforms (e.g.: IOS-XR based) have issues with the MgmtEther interfaces which make them inoperable for many use-cases. There are many technical details that are easily overlooked by those not using the routers to their abilities, so a small network (as Wes mentioned before with 2500s/T1s) still as OOB is unlikely to see data rates comparable to what is seen from a large router exporting data from hundreds of gigs of flows. Often net flow vendors tell customers things that create more flow records which equals slightly higher data resolution but no actual net difference in results except for the lowest of bitrates. Making sure your flow implementation is optimized (ingress only, relevant links only) is one part of having it scale. I’ve seen many a solution that scales poorly or requires dozens of boxes for datasets that don’t require it. It’s easy to say over specify for an attack because of the “Think of the Children^WDDoS” mentality that exists, but when you are on the receiving end of a large attack there are better tools to use. - Jared