sFlow and NetFlow are two of the most commonly-used flow protocols in networking today. Though many other flow protocols have risen up over the years, few have developed the traction of these two. The sFlow vs NetFlow debate has arisen as administrators look for the best way to gain transparency over network traffic.
>>>Jump to sFlow and sFlow analyzers and collectors<<<
There may be some similarities between these two flow protocols, but they couldn’t be any more different in practice. Whether it’s the random sampling approach of sFlow or the NetFlow cache, both of these protocols have their own unique characteristics. Unsurprisingly, their differences haven’t stopped there being debates over which protocol is better. In this article, we’re going to compare these two protocols to see what they do well and see which is best for your network.
Contents
- 1 What is a Flow?
- 2 What is sFlow?
- 3 Why Does sFlow Sample Packets? Doesn’t this Decrease Visibility?
- 4 sFlow Limitations
- 5 What is NetFlow?
- 6 How NetFlow Works: The Basics
- 7 NetFlow and Sampling
- 8 Limitations of NetFlow
- 9 sFlow vs NetFlow
- 10 NetFlow and sFlow Analyzers and Collectors
- 11 sFlow vs NetFlow: NetFlow for Visibility
What is a Flow?
Before we look at sFlow and NetFlow specifically, we need to identify what a flow is. In a nutshell, a flow is a series of packets sent from one application to another. When an application sends data from one application to another, the data is broken down into packets before being transmitted to the receiving device. Each flow protocol has its own unique method of packaging this data and sending it on.
What is sFlow?
sFlow is a type of sampling technology that was initially introduced by HP in 1991. Today, sFlow is used by hardware vendors all over the world. The key concept behind sFlow is sampling packets at random in order to work out the wider trends of network traffic. An sFlow system is comprised of multiple devices performing random sampling of packets and time-based sampling of counters.
Once sFlow samples packets and counters the recovered data is then sent on to an sFlow collector as sFlow datagrams. Unlike NetFlow, sFlow can collect traffic from OSI Layers 2 through 7 because it isn’t limited to monitoring IP traffic.
sFlow has two main components:
- sFlow Agent – An internal function within a switch/router that collects information from sent packets that forwards the samples to an sFlow collector.
- sFlow Collector – A function designed to analyze the information passed on by the sFlow Agent.
When setting up a switch with sFlow you would need to configure two things: a polling interval and a sample rate. The polling interval counts the number of packets that transfer through the switch and exports this figure. This means that when the information is passed on to the sFlow collector the collector knows how many packets are in the export.
The sample rate is used to refer to what percentage of packets you’re sampling. For instance, if the speed of your connection was 10Mb/s and you had a sampling rate of 1 every 200, sFlow would collect 1 packet of every 200 that passes through.
Why Does sFlow Sample Packets? Doesn’t this Decrease Visibility?
The practice of random sampling for visibility can seem counterintuitive but it all boils down to identifying trends. sFlow differs from NetFlow in its network monitoring abilities and is used to collect information over long periods of time. sFlow provides you with just enough packets to give you a snapshot of your network activity. This approach isn’t as transparent as NetFlow but it is still considered effective and accurate.
Research from sFlow Packet Sampling Basics indicates that an sFlow measurement will have 5% accuracy if it is based on over 1,500 samples. 5% accuracy is maintained no matter how many switches there are within a network. As such this suggests that sFlow is a reliable way to monitor network traffic.
The main area where sampling is advantageous is in troubleshooting and identifying abnormal/problematic traffic patterns. You don’t need to put any CPU strain on your switch by attempting to record everything (as happens often with NetFlow) and you can still diagnose unusual behavior promptly based on patterns.
sFlow Limitations
sFlow may be a popular protocol but it isn’t without its problems. In this section, we’re going to look at some of the areas where sFlow doesn’t perform so well.
Limited Packet Detail Analysis
The use of a sampling rate means that sFlow doesn’t provide the packet level details of a protocol like NetFlow. You only have the ability to view randomized packets rather than the entirety of the packets transmitted. This may allow you to find general trends but it leaves large gaps in your visibility. These gaps are not ideal for conducting more in-depth analysis.
Accuracy
While accuracy isn’t a problem if sFlow is using a high sample rate, it is if the sample rate is low. Users who fail to ensure the sample rate is high enough will be rewarded with unreliable and inaccurate sample data. In order to get an accurate reading, you have to make sure that the sample rate is sufficiently high enough.
Devices Need to be sFlow Compatible
Every switch and router in your network needs to be sFlow compatible if you’re to develop a clear view of what is happening. If the number of components that support sFlow is too limited then this is going to dilute your results even further than the initial sampling technique. Before using sFlow as part of your monitoring strategy make sure that your network infrastructure can support the sFlow protocol.
Limited Threat Identification
Whenever sFlow conducts random sampling there are a ton of packets that are unviewable by the user. This is terrible for threat identification because it means that a malicious packet must be recognized in the captured sample. This reduces your chance of diagnosing attacks, like worms, and leaves your network vulnerable to outside attackers.
What is NetFlow?
NetFlow is Cisco’s proprietary protocol that gets used in Cisco switches and routers. The NetFlow protocol enables devices to export IP flow data to collectors or analyzers where it can be further examined by an administrator. The main difference between NetFlow and sFlow is that NetFlow is limited to monitoring IP traffic.
NetFlow allows you to collect traffic so that it can be analyzed. NetFlow collects the traffic and then proceeds to send it on to a collector or analyzer.
NetFlow is made up of two components:
- NetFlow Cache – The NetFlow cache is designed to store IP flow information
- NetFlow Export Mechanism – NetFlow export mechanism sends the cached data on to an analyzer or collector for further analysis
How NetFlow Works: The Basics
Whenever a new packet reaches a router/switch, the device will make a decision on whether to route the datagram. If the router/switch decides to route the datagram it will then reach the flow cache. The flow cache includes the following information:
- Destination IP Addresses
- Source IP Address
- Destination Port Number
- Source Port Number
- Source Interface
- Layer 3 Protocol Type
- ToS Byte (Type of Service Byte)
- Input Logical Interface (ifIndex)
In order to be forwarded onwards, the packet must match certain criteria. This criterion is based on attributes including IP source address, IP destination address, source port, destination port, Layer 3 protocol type, class of service, and router or switch interface. If a packet has the same source address, destination IP address, source port, destination port, protocol interface, and class of service it will be grouped into a flow.
Once this flow information is determined, it is then organized within the NetFlow cache. The number of entries in the NetFlow cache varies greatly and can be anywhere from hundreds of thousands of entries to millions. Once a packet has been taken into the flow cache it will be routed onwards to its final destination. The destination will be a NetFlow collector or analyzer where the flows will be analyzed to see if there are any usage trends.
NetFlow and Sampling
Sampling is one of the unique characteristics associated with sFlow but it is easy to forget that NetFlow has its own sampling abilities as well. There are many occasions in which administrators modify the sampling rates of NetFlow so as to maintain network performance. The more traffic recorded with NetFlow the more database records there are and the higher the device’s CPU utilization is. As such the more traffic you record the more negative the impact will be on the performance of your switch or router.
Rather than allowing the performance of a switch or router to suffer it is often advantageous to switch to using sampling instead. A low sampling rate reduces the amount of information that is being processed and sent onwards. The only issue is that sampling comes at the cost of your visibility. Essentially you’re making the choice to forfeit visibility over packets to improve device performance.
Limiting your transparency in this way is problematic for your quality of service monitoring and the detection of threats. So if you’re monitoring your network with NetFlow you’ll want to stay clear of sampling where possible. With NetFlow it is often worth outsourcing the NetFlow record-making process to a NetFlow Probe. You will retain complete visibility but the processing burden of the records will pass on to the probe instead.
Limitations of NetFlow
Even though NetFlow is considerably more popular than the sFlow protocol there are a number of limitations you need to be aware of with NetFlow. It is true that NetFlow provides more visibility than sFlow but it still needs to be managed properly.
Time Granularity
One of the biggest issues with NetFlow is the delay between traffic passing through your network and your ability to view that traffic. It will take roughly 5 minutes for NetFlow traffic to become available. This is far from ideal as by the time you view the data new problems are already emerging. There is the ability to configure some products to reduce the delay but you’re still going to be one step behind.
Limited Visibility in More Complex Networks
On traditional legacy networks NetFlow has excellent visibility but on more complex networks with cloud services and software-defined networking, you’ll struggle to see what is going on. NetFlow doesn’t have the ability to be able to monitor virtual services in any meaningful way. This is a big blow to the transparency that NetFlow was originally designed to thrive on.
Performance Strain
We’ve mentioned CPU performance strain before but it is worth reiterating because it is one of the most significant problems with NetFlow. The more traffic that passes through your network, the more strain is put on your physical infrastructure. All that traffic needs to be processed in your NetFlow cache and after a certain point, your switch/router is going to experience performance issues.
You Need a Third-Party Flow Collector
In order to use any of the NetFlow data on your network, you’ll need to download a NetFlow collector or analyzer. There are various products like this, such as SolarWinds NetFlow Traffic Analyzer and Paessler PRTG Network Monitor, but you still have to install them. Likewise, you will have to configure these tools to get any use out of your data. While this is easy on most tools it is still extra leg work you need to do.
sFlow vs NetFlow
Feature Comparison Table
Feature | NetFlow | sFlow |
---|---|---|
Vendor Support | Cisco Only | Multiple Vendors |
Packet Captures | No | Partial |
Interface Counters | No | Yes |
Real-time Data collection | Partial | Yes |
Protocol Support Comparison Table
Protocol Support | NetFlow | sFlow |
---|---|---|
IP/ICMP/UDP/TCP | Yes | Yes |
Ethernet/802.3 | No | Yes |
Packet Headers | No | Yes |
IPX | No | Yes |
Appletalk | No | Yes |
There are many people on both sides of the NetFlow vs sFlow debate but there is a particularly strong argument behind the NetFlow side. There are many reasons for this but they all come down to convenience. In many ways, NetFlow is simply more convenient and comprehensive than sFlow. In this section, we’re going to look at this in further detail.
You Don’t Need to Sample with NetFlow
One of the main reasons why people argue for the use of NetFlow is that the samples harvested by sFlow don’t provide you with the complete picture. NetFlow allows you to see exactly what is going on with your network traffic and doesn’t obscure your perspective with random samples. While you can generate a clear perspective with sFlow sampling you need to wait longer for it.
NetFlow Works Better Over WANs
One of the biggest advantages NetFlow has over sFlow is its ability to perform well over WANs. sFlow doesn’t perform well within WANs because the amount of sFlow being put out is proportional to the packets per second rate. With larger networks, this results in thousands of packet samples correlating to the transfer. In contrast, NetFlow output is based on the number of active connections which cuts down on the white noise on larger networks.
The Variety of NetFlow Collectors Available
When it comes to analyzing your flow data, NetFlow has more flow collectors than sFlow hands down. NetFlow support is one of the first things that vendors add support for when creating a flow analyser. While sFlow isn’t restricted by IP traffic it is restricted by the number of sFlow collector providers available. Even though Cisco is relegated to Cisco it has still received widespread adoption.
Firewalls Support NetFlow
If you want to ensure the security of your network against unwanted intruders and malicious attacks, NetFlow has a distinct advantage over sFlow. This is because firewalls have started to offer support for NetFlow and IPFIX to allow users to monitor key entry points to the network. Fortinet is one of the few firewall vendors who hasn’t supported the NetFlow protocol. In other words, if you want to get the most out of your firewall then NetFlow is going to be the better choice ninety percent of the time.
NetFlow and sFlow Analyzers and Collectors
With both sFlow and NetFlow, you need additional collectors/analyzers in order to view the data you’ve collected. We’ve provided you with a quick list of some of the top products on the market.
This is by no means an exhaustive list but it does include the highest functioning products. It is worth noting that there is much more variety available with NetFlow Analyzers than sFlow Collectors.
NetFlow Analyzers / NetFlow Collectors
- Paessler PRTG Network Monitor
- ManageEngine NetFlow Analyzer
- SolarWinds NetFlow Traffic Analyzer
- NTOPNG
- Scrutinizer Plixer
- Wireshark
sFlow Analyzers / sFlow Collectors
- Paessler PRTG Network Monitor
- ManageEngine NetFlow Analyzer
- SolarWinds sFlow Collector Tool with NetFlow Traffic Analyzer
- inMon sFlowTrend
- Plixer Scrutinizer
sFlow vs NetFlow: NetFlow for Visibility
While NetFlow has distinct advantages over sFlow in a number of areas, the truth is that both sFlow and NetFlow have a place within modern networking. sFlow receives lots of criticism based on its focus on random sampling. By comparison, NetFlow gets criticized for its effects on performance and time granularity. Yet each has its own unique advantages over the other in many facets.
For generating a snapshot of emerging trends on your network sFlow is great because it cuts out excessive information in favor of the raw trend. While this doesn’t give you the same detail over every packet that is offered by NetFlow it does allow you to get a general impression of what is happening. sFlow also gives you the chance to sidestep the performance concerns that come with NetFlow.
In the interests of complete network monitoring, you’re probably going to want to incorporate a mixture of the two into your monitoring environment. That way you get the best of both worlds. You’ll find there’s much more competition among NetFlow analyzers than sFlow collectors so you’re likely to get a better selection pool with the former than the latter.