nanog mailing list archives

Re: sFlow vs netFlow/IPFIX


From: Pavel Odintsov <pavel.odintsov () gmail com>
Date: Mon, 29 Feb 2016 12:59:02 +0300

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 () 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 () arbor net>



-- 
Sincerely yours, Pavel Odintsov


Current thread: