Re: sFlow vs netFlow/IPFIX

[freedman () freedman net (Avi Freedman)]

> This maybe outside the scope of this list but I was wondering if anybody had advice or lessons learned on the whole 
> sFlow vs netFlow debate. We are looking at using it for billing and influencing our sdn flows. It seems like 
> everything I have found is biased (articles by companies who have commercial offerings for the "better" protocol)
>
> Todd Crane

Most vendors that take "flow" take both so there tends not to be THAT much religion unless you talk to someone who 
hates being flooded with 1:1 flow, or debugging broken (usually NetFlow) implementations.

In our experience, they both basically work for ops use cases nowadays, for major vendors of routers, and most switches.

sFlow gives faster feedback and more accurate (adding things up, * sample rates, closer to SNMP counter data) than most 
NetFlow/IPFIX implementations.  How much varies from slightly to extreme (if you're using Catalysts for NetFlow/IPFIX).

My thesis overall re: why sFlow 'just works' a bit better is that it's just so much easier to implement sFlow because 
there's no need to track flows (hash table or whatever data structure you need).  Just grab samples of headers, parse, 
fill structs, and send.  

That said, things are hugely less sucky than 10 or even 5 years ago in the NetFlow world, and for the right vendor and 
box and software it's possible to get NetFlow/IPFIX essentially as accurate.

And has been noted, it at least in theory some boxes that do tens to hundreds of gigabits (or low terabits) of traffic 
support 1:1, which you could in theory do with sFlow as a transport, but I haven't seen a switch or router that does 
that.  Re: 1-1 flow - the boxes supporting that are generally not the biggest purchase-able from Cisco or Juniper, but 
are used as the big-boy backbone and border routers by a good number of multi-terabit networks, and even some 
multi-tens-of-terabit networks.

Good luck in your flow journeys.

Avi Freedman
CEO, Kentik