NetFlow vs. sFlow for Network Monitoring and Security: The Final Say

We’ve blogged about the differences between NetFlow and sFlow before but this debate continues to come up often enough and has been going on long enough that it needs to be put to rest once and for all. So let’s cut right to the chase:

The only people that ever say “sFlow is better than NetFlow” are those that haven’t used both and seen the difference for themselves.

This statement isn’t based on a bias toward a particular vendor or any kind of business driver but rather opinions formed over years of operational experience with both flow technologies.

Most customers that I’ve talked to, and there have been hundreds over the years, want sFlow to “just behave like NetFlow”. In fact many customers, when faced with the prospect of sampled data, will deploy NetFlow generators (sometimes called “flow probes”) such as nBox or Cisco’s NGA to create NetFlow based on SPAN ports rather than deal with the difficulties sFlow presents.

Don’t get me wrong, NetFlow and IPFIX have their challenges. NetFlow caching and export mechanics are more difficult to implement correctly, require more resources to operate especially as it relates to memory, and implementations in the field vary wildly. NetFlow is a victim of its own popularity. Everyone wants to add NetFlow-like support to their routers, switches, firewalls, load-balancers, and WAN optimizers but they don’t always stop and check with vendors like Plixer ahead of time to ensure the resulting export will work correctly. This post from last week illustrates this point. sFlow doesn’t have a problem with standardization primarily because so few vendors (that matter) have implemented it.

But NetFlow’s benefits far outweigh it’s few shortcomings:

The full story

While sampling is available for NetFlow it’s not a requirement. People just don’t like sampled data. Especially security people. Sure if you get enough packets over a long enough period you can work out the proper traffic levels but when you’re trying to hunt down an intrusion that occured over a single two minute HTTP SQL injection you need the full story. Sampling technology simply doesn’t provide the full story. It’s like only reading every 128th word in a novel. At the end of the story you have a vague outline of what happened and who the characters were, but little more. Security analysts don’t want 1 out of every 128 packets, they want one out of every one.

Better collector support

Here at Plixer we spend approximately 95% of our day working with NetFlow/IPFIX customers. Just about everybody supports either NetFlow or IPFIX so the majority of the feature requests, bugs submissions, and support calls are related to NetFlow/IPFIX. Over time this has forced us to fine tune our NetFlow support. Sure, we still support sFlow and it works as well as can be expected but it simply hasn’t had as much attention as NetFlow/IPFIX has. How could it? We are customer driven and the customers use NetFlow.

Better vendor support

In addition, many vendors have moved NetFlow processing into hardware in all of their newer product lines. Examples include Cisco’s Cat6k w/Sup2T or the Catalyst 4500E w/Sup7E. Even non-Cisco companies are innovating on the NetFlow front. Enterasys has added powerful hardware-based NetFlow support to their S Series and K Series switches. Hardware-based NetFlow removes one of NetFlow naysayers main complaints: impact on CPU.

More fields, more innovation

You have to give it to Cisco on this one, they have really put a lot of effort into NetFlow over the last few years. Flexible NetFlow, NBAR, MediaNet, ASA NAT export, PfR, the list of extended fields goes on and on.

sFlow has nothing like any of this and I’m not aware of any work to make it better. If you do know of some recent sFlow advancements that catch it up to NetFlow/IPFIX drop a comment or shoot me an email. I would love to hear about it.

Firewalls have adopted NetFlow

Firewalls tend to be located in places where visibility is most needed: at aggregation points and key access control locations often separating critical from untrusted assets. NetFlow is *perfect* for measuring and monitoring key points in the network. It took a while but the firewall vendors finally figured this out and now firewalls are among the most recent adopters of NetFlow/IPFIX support. With the exception of Fortinet, every firewall vendor thus far has chosen either NetFlow or IPFIX. The list includes: PaloAlto, CheckPoint, SonicWall, and of course Cisco’s ASA. Why do firewalls prefer NetFlow? Because their customers want the full story, not samples.

NetFlow/IPFIX works well for all event types, not just TCP/IP

sFlow is fundamentally oriented around Ethernet frames. At its heart sFlow is designed to sample packets. Nothing more, nothing less. IPFIX and NetFlow v9 are incredibly flexible. While most implementations revolve around a source and destination IP address, it’s not a requirement of the protocols. NetFlow/IPFIX can be used to export any kind of structured data. In fact, IPFIX’s variable length fields can even be used to export semi-unstructured data such as URLs, proprietary vendor strings, or hostnames.

Multiple templates can be used to export several different data sets simultaneously. The infrastructure vendor community is only now beginning to understand the potential power behind IPFIX data export. sFlow just isn’t flexible enough to accomodate the evolving role of flows in enterprise and service provider networks. And finally, while I respect the effort by the folks at sFlow.org. sFlow doesn’t have the research following that IPFIX can claim. Individuals such as Benoit Claise are driving the standardization of flow exports and consistently adding to the “how can we make flows better” discussion.

NetFlow works well over a WAN, sFlow doesn’t

The dirty little secret about sFlow that everyone likes to ignore is that the amount of sFlow leaving the router is directly proportional to the packets per second rate. This means that the higher the bps rate at a remote site, the higher the sFlow record rate leaving the site destined for the collector. NetFlow on the other hand is based on the number of active connections, not the packet rate. If I transfer a 500MB file from A to B sFlow will create *several thousand* packet samples to represent the transfer while NetFlow will create only two 46 byte NetFlow entries. This is a deal breaker for most customers. It’s entirely possible to saturate a WAN link with sFlow samples. And since sFlow runs over connectionless, uni-directional UDP, there is no way to tell the exporter to slow down.

Don’t get me wrong…

If all you have are sFlow-enabled devices you should still look into turning on sFlow exports. It’ll give you traffic stats and other bits of info that are better than nothing at all. It’s just that when I see comments like this show up I wonder who these people are and where they’ve been. The NetFlow vs. sFlow war is over. Someone should let them know. Perhaps this will help.

Not convinced? You be the judge. Plixer’s Scrutinizer flow collector accepts both NetFlow and sFlow. Download a free trial here and try it out yourself.