sFlow vs netFlow/IPFIX
rdobbins at arbor.net
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
> 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
> 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
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>
More information about the NANOG