NetFlow - path from Routers to Collector

Tue Sep 1 22:49:22 UTC 2015

> On Sep 1, 2015, at 6:37 PM, Roland Dobbins <rdobbins at 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