NetFlow - path from Routers to Collector

Tue Sep 1 23:06:50 UTC 2015

> On Sep 1, 2015, at 6:51 PM, Roland Dobbins <rdobbins at arbor.net> wrote:
> 
> 
> On 2 Sep 2015, at 5:38, Jared Mauch wrote:
> 
>> Please stop digging,
> 
> Since I'm not digging, I've no reason to stop.  I see and deal with the various quirks of more different platforms exporting flow telemetry than most folks, all day, every day, so I know just a little bit about this topic.

You are, Avi has said that the number of people with a network is outnumbered about 50:1 using his most favorable numbers.  This means for your one example there are 50 people not doing this and the world hasn’t ended for them.  If you aren’t listening to Avi, please
trust me, you don’t need your own OOB network for flow, nor is putting your flow there going to provide you some magical value.  If you
can’t provision enough bandwidth for your telemetry data, you will obviously need to prune it back.  1:10k sampling works and you don’t
need much more than that unless you’re at extremely low bitrates.  Most attacks last under 1 hour and even the small ones shout out
in netflow data doing a simple hash sort algorithm with the proper keys.  You can even use QoS to mitigate if your goal is attack
traffic as they’re mostly UDP based attacks, see: https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 for some advice/input.

I’ve shared my own input at recent NANOG meetings, including policers to keep the attacks under control.

>> Sounds like you haven’t used Cisco recently.
> 
> I use Cisco all the time, thanks.  They aren't perfect - no vendor is.  They have various issues with their NetFlow implementations on various platforms - for example, bursts of wildly inaccurate flow statistics from CRS boxes when a linecard is rebooted, a problem which has persisted for years and is just now being addressed. Odd stuff with EARL8 on Sup2T/DFC4 in certain configurations, and so forth.

I’m not talking about datacenter class equipment that you seem so focused on like the Earl7 with the TICO etc that did software sampling out of the hardware tcam and would be overrun.

> But Niels is grossly exaggerating. I get very usable flow telemetry from them in many, many networks.  I deal with  flow telemetry from many, many vendors/platforms, and I can confidently assert that Cisco are nowhere near the bottom of the heap when it comes to the verisimilitude and functionality of their flow telemetry export.  Quite the opposite

What people often don’t see is true “scale”[1] of netflow.  When you have enough attributes or want to actually look at your IPv6 there have been significant shortcomings.  We had to remind the patent holder for netflow how to implement it for their own hardware.

- Jared

aside: will you be in Yokohama?  We should get lunch/dinner.

[1] - I hate this word, vendors use it as an excuse to hardcode limits and to not properly respond to valid use cases