nanog mailing list archives

Re: sFlow vs netFlow/IPFIX


From: "Roland Dobbins" <rdobbins () arbor net>
Date: Mon, 29 Feb 2016 15:38:10 +0700

On 29 Feb 2016, at 15:12, Pavel Odintsov wrote:

Looks like you haven't so much field experience with sflow. I could
help and offer some real field experience below.

I've already recounted my real-world operational experience with NetFlow.

I have my own netflow collector implementation for netflow v5, netflow v9 and IPFIX (just check my repository

Coding something and using something operationally are two different things. I'm not a coder, but I've used NetFlow operationally since 1998, primarily on Cisco platforms (some Junipers, but I don't know a lot about Juniper boxes).

So you know about Mirkotik implementation of netflow (they have
minimum possible active and inactive timeout - 60 seconds) ?

Yes. That does not equate to a 60s delay in detection/classifying/tracing back a SYN-flood, or anything else.

Or what about old Cisco routers which support only 180 seconds as active timeouts?

I think you're referring to the *default* value for the active flow timer, which can of course be altered.

Could they offer affordable time for telemetry delivery?

Yes, because there has never been any such router, and also because cache size and other tunable parameters, as well as FIFOing out of flows when the cache is full, guarantees that very few flows of the type seen in DDoS traffic hang around in the cache for any appreciable length of time.

Because not all netflow implementations are OK. And definitely some netflow implementations are broken.

You can search the archives on this list and see my previous detailed explanation of NetFlow caveats on Cisco 6500/7600 with EARL6 and EARL7 ASICs.

Your statements about it taking an inordinately long time to detect/classify/traceback SYN-floods and other types of DDoS attacks utilizing NetFlow implementations (with the exceptions of crippled implementations like the aforementioned EARL6/EARL7 and pre-Sup7 Cisco 4500) are simply untrue.

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


Current thread: