Q: Can you perform billing with sFlowsamples?

A: Yes, depending on how you need to invoice.

Being a vendor that supports NetFlow and sFlow reporting, we deal with lots of flow questions.  Most recently, I was dealing with a customer that was trying to figure out how to do billing with sFlow.  Depending on how you want to invoice, sFlow may or may not be appropriate.  This document from Inmon sums it up nicely by saying, “sampling does not provide a 100% accurate result.”  The document goes on to state, “but it does provide a result in which the error can be accurately characterized.” Which is really a fancy way of saying that sampling allows you to be ‘fairly’ accurate.

In my experience, reactive traffic reporting with sFlow over a short period of time (e.g. last 10 minutes) when compared to NetFlow statistics is significantly different.  As much as half the entries in the TopN sampled by sFlow will be different from those accurately counted by NetFlow. If however you look at the data over time (i.e. not reactively) of lets say 24 hours, then sFlow starts to be more accurate.

One might argue to increase the sampling rate, however, this is often a poor choice.  Increasing the sampling rate causes more traffic over the network (i.e. often much more than NetFlow) and can overwhelm even the fastest collectors.

Q: Is sFlow better than NetFlow?

A: No

I agree with section 4 of the above PDF that overtime sFlow becomes more and more accurate, however, I take issue with the sentence, “Billing by lower bound of the confidence interval ensures that no customer is overcharged.”  My question is: Why not accurately charge? The answer is because you can’t with sFlow.

Also, in regard to the shortcomings of NetFlow for billing, the Inmon sFlow billing document states: “This method requires a variable, but significant amount of memory, especially under high load conditions, for example during a denial of service attack when every packet is a separate short-lived flow there may be 30,000 flows per second and the switch must export data rapidly to avoid flow cache overflow. In such a situation flow data will be lost.”

sFlow or NetFlow under Attack.

Depending on the attack, a 30,000 flow per second denial of service attack may end up being 1-20 flows exported in a single NetFlow packet. An over aggressive sampling rate (e.g. 1:100) on an sFlow switch would cause over 100 packets back to the collector.  This could cause a micro burst in traffic and lead to an interruption in my VoIP traffic.  My point is that this could be twisted in either direction and I feel the document is a bit biased.  Consider the author.

If you are trying to do accurate billing with NetFlow and are concerned about the volume of flows it will create, use Flexible NetFlow and export by subnet.  In my experience, smart implementations of NetFlow doesn’t  hammer the CPU.

Hardware has its Problems

Probably the biggest problem with sFlow could be it’s bragging point (all in hardware).  Cisco and Enterasys are both exporting NetFlow in hardware, however, we still need the CPU to export custom data types (e.g. interface names, counters like sFlow, etc.). By the way, NetFlow can be used to sample traffic!  Version 5 of sFlow has been available for years.  Where is the latest version?  Where is the NBAR like capabilities like NetFlow for deep packet inspection to identify applications (e.g. Skype, BitTorrent, PC Anywhere, etc.)?  Where is the ability to export things such as jitter, packet loss, round trip time, etc. for voice and video, like we see from Cisco Medianet and the nProbe?


I would limit sFlow billing to physical interfaces on the switch.  This would be accurate.  IMO: Trying to invoice based on IP addresses using sFlow is asking for trouble.  I don’t dislike sFlow.  I do dislike trying to hype it up to be accurate for something that NetFlow is far better suited for.  If your switches support sFlow, turn it on and take advantage of it, but don’t try to make it NetFlow by cranking up the sample rate.

I believe that sFlow sampling is awesome and it is great that so many switch vendors can implement it inexpensively and hence keep the cost down on their hardware. We have two sFlow switches on our network.

NetFlow is a thriving technology with the support of Cisco, Avaya, Alcatel, AT&T, IBM, Nokia, PSG, Qualcomm, and several others behind it and encouraging the emerging standard for NetFlow called IPFIX. The future of sFlow is guided by Inmon and that is about it.  Sure, lots of vendors implement sFlow chips, but how many are helping to guide the technology’s future?

These two technologies aren’t in the same league. SFlow is often a second thought feature on switches that implement it and it provides insight that SNMP simply can’t provide, it is easy for vendors to implement and its inexpensive.  Finally, everyone should know that none of these technologies are standards, not sFlow, not NetFlow and not even IPFIX.  However, look at the activity in the IETF IPFIX working group.   Clearly, IPFIX is the flow technology of the future for networking statistics and this includes sampling.

Jim D author pic

James Dougherty

I have worn many hats in my professional life. Support engineer, developer, network admin and manager are all points on my resume, but the one common thread with all of these jobs is that I enjoy working with people; that is what I do here at Plixer. I make sure that everyone understands our product and can get the most out of it. It's just simple 'no bull' support!

Let me know if you have any questions, I would be happy to help.

- Jimmy D


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…

Leave a Reply