sFlow vs netFlow/IPFIX

Mon Feb 29 09:59:02 UTC 2016

Thanks for detailed question!

I have only one question. Why you against sFLOW protocol telemetry
with so huge passion ? :)

It's not proprietary technology and not an product from yet another
big company. I'm not trying to sell anything because... nothing to
sell. Really, isn't it?

It's just yet another open standard  to analyze data approved and
implemented as RFC.

If somebody developed this standard. Implemented it in ASIC (they have
very huge price for development and production you know). That's means
"somebody" really want it and will definitely use it.

Actually, sflow is not so popular as netflow. But to be honest it's
pretty young standard in compare with netflow and it implements
slightly different approach. Which will be useful in some cases.

For example, at huge Internet Exchanges you actually haven't any
netflow enabled devices (just check design architecures from AMX-IX,
DEC-IX, LINX or even MSK-IX).

Almost all IX developed with L2 in ming and they actually haven't any
devices which could produce netflow.

So IX could not use netflow even if they want. But you vote for "sflow
is weird protocol and you should avoid it".

How IX could monitor traffic if they haven't netflow? So if they
follow your recommendations they should drop idea about traffic
monitoring at all :)

I do not like holy wars about something vs something.  But actually in
modern network world every technology has applicable usage and it's
not good idea to avoid it just because your religion (I'm speaking
about netflow religion) prohibit it for you.

Actually you are writing this email from company email and I could
conclude it's Arbor vision and is not your own. Could you clarify it?
Could I use your vision as Arbor's vision in public speeches /
presentations?

Thanks!

On Mon, Feb 29, 2016 at 12:42 PM, Roland Dobbins <rdobbins at arbor.net> wrote:
> 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>

-- 
Sincerely yours, Pavel Odintsov