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 <rdobb...@arbor.net>
