Re: NetFlow - path from Routers to Collector

["Roland Dobbins" <rdobbins () arbor net>]

On 2 Sep 2015, at 6:06, Jared Mauch wrote:

> You are, Avi has said that the number of people with a network is 
> outnumbered about 50:1 using his most favorable numbers.

Again, to clarify - I count VLANs/VRFs as being sufficiently out-of-band 
to handle flow telemetry on a reasonable basis without mixing it in with 
customer traffic.

That changes the ratio.

> 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.

I agree with you, Avi, and others that a dedicated OOB network *just for 
flow telemetry* doesn't make economic sense in most (any?) scenarios.

What I'm saying is that it oughtn't to be mixed in with customer 
data-plane traffic.  Ideally, all management-plane traffic would 
traverse a separate physical infrastructure.  Since we don't live in an 
ideal world, virtual separation is generally Good Enough.

> 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

Concur 100%.  I spend a lot of time explaining to customers that no, 
they don't need/want 1:1 even if they could get it, and that the 'wake' 
left by attack traffic stands out very well even at relatively high 
sampling ratios.

Most of the network-oriented folks seem to grasp this pretty quickly.  
It's generally the 'security' types who often seem 
conceptually/attitudinally incapable of understanding these principles.

> .  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 know you do this, and I understand why.  Not everyone agrees with this 
and does it, and I also understand why (not).

ntp is easy, because there's the timesync packet-size classification 
hook.  It gets a little dicier with other things.

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

And it's valuable experience to share, nobody disputes that.

> 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.

I'm pretty sure the CRSes I referred to with the linecard-reboot issue 
in my example aren't datacenter-class equipment.

;>

> 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.

This is very true.  IPv6 flow telemetry is another area in which 
IPv4/IPv6 feature parity lags.  Because of your focus on large-scale 
IPv6 deployment over the course of many years, you see and experience a 
lot more IPv6-related deficiencies than most folks.

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

Yes, and yes.

;>

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

Concur 100%.

Another annoying vendor trait is use-case obsession.  In many contexts, 
the right answer is to understand that there is a baseline plateau of 
vitally necessary scaling (that word, again) capacity and required 
functionality which is universally applicable, irrespective of 
variations in particular use cases.

I recently had a discussion with someone who was asking me how many 
attack sources one typically sees in a given DDoS attack.  My response 
was that there is no 'typical'; and that for IPv4, the theoretical 
potential is 2^32 sources, while in IPv6, the theoretical potential is 
for 2^128 sources.

It was a light-bulb moment.

;>

-----------------------------------
Roland Dobbins <rdobbins () arbor net>