NetFlow compared to sFlow for network monitoring

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 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.

Adam Powers

Experienced technology professional specializing in information security. Skilled orator and accomplished public presenter (see webinars, blogs, etc below). Lead advocate for NetFlow and IPFIX technology adoption.


Big Data

Sankey Flow Graph

One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the…

14 comments on “NetFlow vs. sFlow for Network Monitoring and Security: The Final Say

  1. Great post Adam. The people that I work with find sFlow limiting and most of the time are quite disappointed in the results. Network monitoring has evolved and so has flow technology. Not only do we need to see who was talking to who and what they are saying but we also need to know the applications they were using. We need to know if there are “nasty’s” hanging out in our Layer 3 and we need to know it now. Basically, we need more insight. NetFlow and IPFIX have grown to meet that need. From Cisco’s MediaNet all the way down to nBox and it’s URL reporting, NetFlow and IPFIX have continued to excel. sFlow doesn’t, won’t and can’t.

    1. Hi Peter, good to hear from you. A “war” metaphor might be a bit sensationalist but the fact is that customers constantly ask which is “better”. And it’s a legit question that we feel should be addressed based on practical experience. If a customer comes to me and says “Adam I have to choose between Enterasys and Extreme. I understand that Enterasys supports NetFlow and Extreme supports sFlow. What are your thoughts on the differences? If you had to choose a vendor based on the flow technology they support which would you choose?”

      Well, based on lots of past experience along with the points made in this blog, I would obviously choose Enterasys. Sure, the decision for who you choose includes many other facts but all things being equal NetFlow is a differentiator that can’t be easily overlooked.

      I don’t want to come across as overly confrontational on this topic but what happens more often than not is the customer will blame the collector for problems that exist in the flows. I’ve always been focused quite sharply on security. Sampling tech – in NetFlow or sFlow – negatively impacts the reports and alerting ability of the collector, so I simply cannot recommend sFlow for anything other than simple bandwidth reporting or ISP-level DoS attacks.

      Having said all that… we will continue to support sFlow and make the best of it we can. I would love to hear about any new developments on the way from any of the key sFlow vendors. The more context (usernames, app IDs, ACL info, NAT data, latency, etc) the flows can provide the better the user’s experience. To your point: everyone wins.

  2. Adam, customers should choose the mix of solutions that best meet their requirements. Which solution is “better” depends on your goals. Your perspective is of perimeter security in corporate firewalls and WAN routers and your customer comments reflect the concerns of that market.

    I would argue that sFlow has significant advantages over NetFlow in monitoring 10G, 40G and 100G data center switches, particularly when you look at monitoring tunneling protocols such as TRILL/SPB, GRE, NVGRE and VxLAN.

    Another topical area is software defined networking (SDN), and again sFlow has significant advantages:

    Many of the recent developments in sFlow focus on unifying network, server and application performance monitoring in cloud data center environments. Layer 7 sFlow (embedded in web servers, application servers and load balancers) provides detailed visibility into application response times, URLs etc. Host sFlow extends sFlow’s counter push mechanism to include server cpu, memory and disk IO. Most recently, NVIDIA added sFlow GPU performance metrics for GPU-based compute clusters.

    A final area where sFlow has significant advantages is in monitoring large scale wireless access networks:

    As I said in my previous post, NetFlow and sFlow are complementary and a solution for most customers will involve both technologies, each used where it is most appropriate.

  3. I have the same request coming over and over: NetFlow/IPFIX versus Sflow.
    So great article coming from someone independent. My views might appeared biased 😉

    Regarding SFlow on the nexus 3000: this was THE exception, not the Cisco strategy, and SFlow will not spread over other platforms. I don’t see any advantages…

    Regards, Benoit.

  4. Peter, I’ve been reading your blog posts for years and you write with a silver tongue when it comes to NetFlow and IPFIX. In fact, you’ve consistently made claims about sFlow and NetFlow/IPFIX over the years that aren’t true or at least leave out facts.

    Peter Phaal “This focus on IP flow export is consistent with the IETF’s responsibility for the TCP/IP suite of protocols and explicitly avoids addressing layer 2 monitoring (switches)”

    Truth: “Explicitly avoids” is a bit strong. Several vendors including Cisco have implemented IPFIX with layer 2 details (e.g. Mac Address) including packet samples similar to sFlow. Also, NetFlow was built to export IP flows and not just TCP/IP.

    Peter Phaal: “sFlow is a standard”

    Truth: sFlow is no more of a standard than NetFlow. To my knowledge, you have never posted a URL to the IEEE or IETF that outlines the sFlow standard. You have frequently stated that NetFlow is proprietary to Cisco when it is no more proprietary than sFlow. J-Flow, NetStream are both basically NetFlow. IPFIX is the proposed standard for flow technology.

    Peter Phaal: “It is clear that the 4948E doesn’t have hardware support for 1 in N packet sampling.”

    Truth: NetFlow-Lite does support 1 in N packet sampling, I tested it with our engineers in our lab. I have never come across an sFlow switch that can sample every packet. It may exist, I just haven’t heard of it.

    Peter Phaal: “NetFlow has no mechanism to compensate for lost records”

    Truth: NetFlow / IPFIX developed something called SCTP. I’m sure you knew this yet omitted it from your post. What is the sFlow mechanism? Wait for another sample I presume.

    Peter Phaal: “NetFlow monitoring generates periodic bursts of traffic”

    Truth: I’ve only seen sFlow implemented in 1 out of X configurations. If there is a spike in traffic, I’ve seen similar issues with sFlow and NetFlow. Why can’t you be a bit more honest with your comparisons?

    I hope my point is clear. You have repeatedly looked for ways to belittle NetFlow/IPFIX. I hope that Cisco’s support for sFlow will encourage you to be more accurate in your posts. IMO: I think the very name sFlow which arguably should be named sPacket shows how slippery your motives can be. What is ‘flowish’ about sFlow?

    sFlow Vs. NetFlow:

  5. Mike, each technology has it’s strengths and weaknesses. Choosing whether to use sFlow or NetFlow in any given situation depends on customer requirements and the capabilities of the customer’s equipment. I think if anyone reads the articles you referenced, they will find that they make reasonable points that are worth considering.

    Given that the tag line for Scrutinizer is “NetFlow & sFlow Analyzer” – it has been surprising to see how anti-sFlow Plixer has become. NetFlow/IPFIX and sFlow each have their place and performance analysis tools should make the most of both technologies in order to best serve customers.

    I am not sure what point you are trying to make with the sPacket comment. The fact that sFlow is packet oriented is one of its strengths. Shifting the flow cache out of the switch to external sFlow analyzer software allows sFlow to report on all the new protocols (TRILL, VxLAN, GRE, FCoE etc.) being deployed in the data center

    Benoit, I hope that now that Cisco has an sFlow implementation it will have an open mind about sFlow and listen to customer feedback. There are good reasons for Cisco to support both sFlow and NetFlow as other network equipment vendors have done.

  6. Thank you Peter for continuing to post. I agree, sFlow has tremendous value. I will make sure that I do a better job of highlighting it’s strengths. By the way, although I sometimes lift an eyebrow when reading your blogs, I appreciate the effort you put into them. I know it isn’t easy! Maybe we’ll meet some day at Cisco Live.

  7. Question: are NetFlow and IPFIX the same thing?
    My question is our Avaya switches use IPFIX. Will NetFlow communicate with
    IPFIX on our Avaya switches?

    Thanks in advance

    Paul Jamieson
    Toronto, Canada

  8. Hi Paul,

    NetFlow is owned by Cisco. IPFIX is the proposed standard for NetFlow. Any company wishing to copy NetFlow should use IPFIX. Even Cisco is moving to IPFIX (E.g. Cisco AVC exports IPFIX).

    Regarding Avaya, are those old Nortel switches? Nortel called it IPFIX but, it was really NetFlow.

Comments are closed.