sFlow vs netFlow/IPFIX

Mon Feb 29 08:53:44 UTC 2016

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

-- 
Sincerely yours, Pavel Odintsov