Thanks for explained answer! But actually it's mistake to think I haven't real field experience just because I'm developer. In world of big companies nobody could do ops and development. But I'm trying to keep close to both worlds. And could conclude it's definitely possible. It's definitely possible thanks to my flexible company :) But actually "I think you're referring to the *default* value for the active flow timer, which can of course be altered." It's not about default. It's about minimal possible. For Mikrotik routers same issue. Minimal possible timeout is 60 / 60. And impossible to decrease it. Also so much routers could not do enough accurate netflow without additional (and very expensive) line cards just for netflow generation. OK, we could handle some sort of SYN flood. But what about 20 Gbps http flood with valid requests when each customer are real (and not spoofied) and they are sending huge post requests and hang on connection? How netflow will handle correctly handshaked connection, established http session but haven't closed correctly for a while? Actually it could wait for active/inactive timeout and you will get bad news from ops guys about network downtime. But sflow will handle it with flying colors without delay. What about destination http host detection with netflow? Could it extract "host" header from netflow? And drop only part of traffic to our own host? Definitely not. Netflow haven't any information about http headers but sflow has. What about same issue for dns flood when somebody flood out some certain host? You could detect this attack with netflow. But you could not extract information about certain type of DDoS attack and attacked domain. When we speaking about "very rough" DDoS attack mitigation and filtering we could use netflow. But when we are really care about network stability, customer service SLA and ability to filter malicious traffic with perfect precision we should use sflow. I really like to hear feedback about my vision. On Mon, Feb 29, 2016 at 11:38 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
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>
-- Sincerely yours, Pavel Odintsov