On 29 Feb 2016, at 15:53, Pavel Odintsov wrote:
It's not about default. It's about minimal possible.
To my knowledge, there has never been a Cisco router which only allowed an active flow timer value of 180s, which wasn't user-configurable. I would appreciate the details of any such router.
For Mikrotik routers same issue. Minimal possible timeout is 60 / 60. And impossible to decrease it.
As we've seen already from another poster in this thread, that isn't the case.
Also so much routers could not do enough accurate netflow without additional (and very expensive) line cards just for netflow generation.
I believe you're referring to PICs on Juniper routers, yes? Or perhaps the requirement for E3 or E5 linecards on Cisco 12Ks? Or maybe DFCs on Cisco 6500s/7600s? Or possibly M-series linecards on Cisco N7Ks (which are switches, of course)? TANSTAAFL.
OK, we could handle some sort of SYN flood.
As noted previously, this is indeed the case.
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?
Attacks of this nature generally leave a 'wake' or 'contrail' which is pretty easily spotted if one's statistical anomaly detection routines are optimal.
Actually it could wait for active/inactive timeout and you will get bad news from ops guys about network downtime.
As a network ops guy, I can assure you that you are incorrect, largely because you don't seem to understand the interplay of active flow timer, inactive flow timer, NetFlow cache size, NetFlow cache FIFOing, and normal flow cache baselines.
But sflow will handle it with flying colors without delay.
NetFlow handles 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?
Of course not, for classical flow telemetry templates - but that's when one drops from the macroanlytical to the microanalytical. And flow telemetry doesn't 'drop' anything. For some reason, you don't mention Flexible NetFlow at all. It's true that it's taken a while to become practical to use (back when the then-Cisco NetFlow PM asked me to create the CLI grammar and syntax for FNF, I noted that it wouldn't take off until there was a decent control-plane interface for creating, configuring, and tearing down dynamic flow caches, as well as some degree of ASIC support on larger platforms), but now that the various 'SDN'-type provisioning mechanisms are being implemented, and now that at least partial FNF is supported to varying degrees on various ASICs, this will hopefully change.
Netflow haven't any information about http headers but sflow has.
See above. This isn't necessary, and it isn't possible at scale with s/Flow, either.
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.
There's no need to do this with flow telemetry. Once the attack has been detected/classified/traced back, one drops to the microanalytical for situationally-appropriate mitigation.
When we speaking about "very rough" DDoS attack mitigation and filtering we could use netflow.
Not just 'very rough', see above.
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.
This is demonstrably incorrect. Many of the largest networks in the world successfully utilize NetFlow telemetry for all these purposes; they have for many years, and will continue to do so. [And, btw, nothing has 'perfect precision'.] That doesn't mean that NetFlow (or IPFIX) is perfect, and it doesn't mean that all implementations are perfect, and it doesn't mean that the ability to get more information about traffic via FNF or IPFIX EE mechanisms isn't desirable. But you are simply wrong about the utility of NetFlow and/or IPFIX with classical flow templates.
I really like to hear feedback about my vision.
See above. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>