> On Sep 1, 2015, at 6:51 PM, Roland Dobbins <rdobb...@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

Reply via email to