NetFlow - path from Routers to Collector
Roland Dobbins
rdobbins at arbor.net
Wed Sep 2 00:01:49 UTC 2015
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 at arbor.net>
More information about the NANOG
mailing list