sFlow vs netFlow/IPFIX

Mon Feb 29 08:38:10 UTC 2016

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 at arbor.net>