[183421] in North American Network Operators' Group
Re: NetFlow - path from Routers to Collector
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Sep 1 19:08:30 2015
X-Original-To: nanog@nanog.org
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <ECA18BD1-E747-44C7-983E-69AF5D7B17B9@arbor.net>
Date: Tue, 1 Sep 2015 19:06:50 -0400
To: Roland Dobbins <rdobbins@arbor.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Sep 1, 2015, at 6:51 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
>=20
>=20
> On 2 Sep 2015, at 5:38, Jared Mauch wrote:
>=20
>> Please stop digging,
>=20
> 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=E2=80=99t ended for them. If you aren=E2=80=99t listening to Avi, =
please
trust me, you don=E2=80=99t need your own OOB network for flow, nor is =
putting your flow there going to provide you some magical value. If you
can=E2=80=99t provision enough bandwidth for your telemetry data, you =
will obviously need to prune it back. 1:10k sampling works and you =
don=E2=80=99t
need much more than that unless you=E2=80=99re 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=E2=80=99re mostly UDP based attacks, see: =
https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 for some =
advice/input.
I=E2=80=99ve shared my own input at recent NANOG meetings, including =
policers to keep the attacks under control.
>> Sounds like you haven=E2=80=99t used Cisco recently.
>=20
> 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=E2=80=99m 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=E2=80=99t see is true =E2=80=9Cscale=E2=80=9D[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=
