sFlow vs netFlow/IPFIX

Mon Feb 29 09:42:45 UTC 2016

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