In any given network, switches, routers, and firewalls may support different flow protocols. After all, there’s NetFlow, sFlow, IPFIX, and J-Flow, to name a few.
With so many options, you may be wondering, “Which flow protocol should I use?”
It’s a common question, and it has a relatively simple answer: While some devices support multiple protocols, a device typically only supports one type of flow protocol, so you should use the protocol your device and collector support.
Two of the most common flow protocols you’ll run into are NetFlow and sFlow, and there are some differences between sFlow vs NetFlow to keep in mind.
What is NetFlow
We broke down the basics about NetFlow in an article covering its history, evolution, inner workings, and benefits. Here’s the Cliffs Notes version of the article.
Introduced in Cisco routers in 1995, NetFlow originally was designed as a software-based technique to summarize network flow data for packets routed over Cisco equipment.
As time passed, Cisco realized having network flow data was useful and began implementing it in network hardware. Over time, NetFlow became the de facto industry standard that other vendors have imitated. For example, Juniper has J-Flow, Huawei has NetStream, and multiple vendors use sFlow (which we’ll discuss shortly).
Today, NetFlow is a Layer 3 protocol that, over time, processes all IP packets as they enter or exit an interface on a router or a firewall. NetFlow analyzes the traffic and generates metadata that network administrators can use to see how much traffic is being generated, by whom, and where that traffic is going.
Read more: An introduction to monitoring network traffic with NetFlow
Currently, there are multiple versions of NetFlow that can be configured on a device, with the most common being NetFlow v5 and v9. The main difference between the two versions is NetFlow v9 has “empty” fields, meaning the user can add custom information—like username, country code, or proxy IP—to them. There’s also another popular version called IPFIX (also known as NetFlow v10), which has a strong base built on NetFlow v9.
Read more: How to dig deeper into network traffic when you don’t have NetFlow
What is sFlow?
sFlow—which is short for “standard flow”—originated as an industry standard for exporting packets from Layer 2 of the OSI model on switches.
While NetFlow processes all the packets flowing through the interface on a router or firewall and the metadata is created on the device itself, switches supporting sFlow send a sampling packet of the traffic it’s receiving through its interfaces. With sFlow, the device that receives the sampling packet must generate all the metadata. It’s also important to mention that sampling rate is mandatory in sFlow versus in NetFlow it’s optional.
The sampling packet is—you likely guessed it—one sample of the total number of packets passing through the interface. To determine when a packet is selected, you use a sampling rate, which is expressed in the format 1:X. By setting a sampling rate, you’re telling your device to sample one out of every X number of packets that pass through the interface and send it to the collector. The sampling rate for sFlow depends on multiple things, including how powerful the switch management plane CPU is.
Which sampling rate should you use on your devices?
While flow data from protocols like NetFlow and sFlow are typically a very light load—usually less than 0.5% of total bandwidth consumption—you can use sampling to lower CPU utilization (and bandwidth, to a lesser extent). The trade-off is you’ll lose a bit of granularity in your data.
For Auvik TrafficInsights™, which supports both NetFlow and sFlow, these are the sampling rates we like to use:
Data volume (95th percentile) | Recommended sampling rate |
---|---|
< 25 Mb/s | 1 in 1 |
< 100 Mb/s | 1 in 128 |
< 400 Mb/s | 1 in 256 |
< 1 GB/s | 1 in 512 |
< 5 GB/s | 1 in 1024 |
< 25 GB/s | 1 in 2048 |
sFlow, based on its mandatory sampling structure, is recommended on bigger networks with high traffic volumes. But, if your device supports applied samples of 1:256 or lower, it doesn’t matter which flow protocol you choose to use—feel free to use whichever one you’re most comfortable with.
Deciding between sFlow and NetFlow
When comparing sFlow vs NetFlow, sFlow offers a broader overview of network traffic than NetFlow does because it generates snapshots of emerging network trends based on samples. In contrast, NetFlow provides a clear view of everything that is going on with your network traffic as it processes all the packets. In situations where there is a sudden increase in network traffic, NetFlow can employ a few flows for massive packet volume while sFlow’s sampling will increase additional workload and may miss some traffic.
Another difference to consider when choosing between sFlow and NetFlow is that sFlow provides the ability to sample everything because it is network layer independent, whereas NetFlow can only monitor IP traffic. This means with sFlow, non IP traffic is captured and available for analysis while NetFlow does not provide any information beyond IP network traffic.
As mentioned previously, you may not have a choice between sFlow and NetFlow because many network devices will only support one or the other. However, your network likely contains equipment from multiple vendors and as a network operator, it’s important to evaluate whether your network monitoring platform supports all the network protocols that your network generates. Ensuring compatibility with your flow protocols is key to smooth network management.
Cloud-based network monitoring and management software like Auvik allows you to automate complex network tasks and easily manage network equipment from multiple vendors. You’ll gain complete network visibility, so you always know what’s on the network, even as it changes. To see how Auvik delivers network monitoring that is compatible with both sFlow and NetFlow, get your free 14-day Auvik trial.
Your Guide to Selling Managed Network Services
Get templates for network assessment reports, presentations, pricing & more—designed just for MSPs.