NetFlow vs sFlow

In packet switching networks, data is broken down into packets (made of a header and a payload) before being transmitted over a digital network. Data in the header is used by networking hardware to direct the packet to its destination, where the payload is extracted and used by an operating system, application software, or higher layer protocols. When a sequence of packets travels from a source to a destination it is called packet flow or network flow, or simply flow. A flow is a one-directional set of packets sharing common attributes such as source and destination IP, source and destination ports, size in bytes, and type of service, among others.

Network admins monitor packet flow in their network using flow analysis tools to extract those attributes which tell them the nature of the data, its source, and destination, among others. This gives them the visibility required to identify abnormal traffic patterns and non-compliant applications, devices, or users; as well as track the root cause of performance issues. Flow-based network monitoring provides significant advantages over other network monitoring methods because it captures more detailed useful information about network flow composition. And since flow monitoring capability is now a built-in feature in most modern network equipment, this makes it significantly less expensive and easier to deploy.

NetFlow and sFlow are the two key protocols that network administrators often turn to for flow-based network monitoring. Superficially, these protocols seem to provide similar capabilities, but they also differ in so many ways. In this article, we will examine these two flow-based network monitoring protocols. Hopefully, this will guide you in the process of choosing the right one for your environment.

What is NetFlow?

NetFlow is a Cisco proprietary protocol introduced on Cisco devices such as routers to enable it to monitor network traffic and extract data about the traffic as it enters or exits an interface. Netflow attempts to identify flows of related network packets, rather than treat each individually. This helps to better understand the context of network activities. NetFlow is akin to observing traffic patterns and collecting useful statistics on a busy highway. For instance, NetFlow can tell us how many vehicles or what type of vehicle traveled from point A to Point B.

By analyzing the data provided by NetFlow, a network administrator can figure out the source and destination of network traffic, type of service, malicious IP and traffic patterns, among others.

How NetFlow Works

NetFlow works by following a simple process of flow data aggregation, storage, sorting, and analysis.

A NetFlow monitoring system architecture consists of the following key elements:

• Flow Exporter Aggregates packets into flows and exports flow records to NetFlow collectors.
• Flow Collector Collectors are software or hardware-based devices responsible for receiving, storing, and pre-processing flow data as delivered by the flow exporter. It includes a cache or database used to store NetFlow data once the packets have been examined.
• Flow Analyzer These are tools used to analyze received flow data which then provides deeper visibility into the nature of the data.

When devices such as routers that support NetFlow receive packet flow, these packets are examined for a set of attributes. These attributes or network traffic statistics are then extracted on all interfaces where NetFlow is enabled. Once extracted, the router exports them as NetFlow records to NetFlow collectors for storage and pre-processing. This could be a dedicated Netflow analyzer tool or a full network management suite that accepts NetFlow as a complimenting feature.

The router will export flow records when it determines that the flow is completed. NetFlow employs a technique known as sampling to reduce the volume of flow records exported from network devices.  Flow records don’t contain the actual data that make up the flow. They are simply metadata—data that’s used to describe the data that’s contained in the flow.

Why Use NetFlow? 

NetFlow enables network admins and NOC staff to visualize traffic patterns throughout the entire network, profile a user’s utilization of network and application resources, discover how much traffic is related to web browsing and other activities during working hours, learn when and how often users access an application in the network and identify network performance issues. The intelligence gathered from NetFlow statistics can also be used to anticipate and plan for network growth.

More importantly, NetFlow statistics are also utilized by security and SOC teams to spot changes in network behavior or identify abnormal traffic patterns that may lead to a security breach. NetFlow data can reveal where the most network resources are being consumed. Some malicious activities such as outbound spam runs and data exfiltration drain network resources, so if there are resource spikes in unusual areas it can be a pointer to an underlying security issue.

Limitations of NetFlow

NetFlow provides lots of benefits to the network admin team, especially in the area of network traffic visibility, planning, and security. Nevertheless, there are several limitations you need to be aware of:

• Performance Impact NetFlow has a performance impact on the devices where it is implemented. All the traffic that passes through your network needs to be processed in your NetFlow cache and after a certain point, your device may experience performance issues.
• Limited Export Cisco NetFlow devices only allow you to export two flows to two NetFlow collectors. Forwarding flows to only fewer collectors than required to properly manage and troubleshoot the network may impact visibility. to properly manage and troubleshoot the network.
• Latency One of the issues with NetFlow is the time lag between traffic passing through your network and your ability to view and make sense of them. This delay can be as much as 5 minutes. In the context of computing and networks, the negative impact of this delay can be significant, especially in networks where availability and performance are paramount.

What is sFlow?

sFlow from InMon Corporation is a packet sampling protocol used to record statistical, infrastructure, routing, and other metadata about traffic traversing an sFlow-enabled network device. The letter “s” in sFlow stands for “sampled” or “sampling”, and it’s key to understanding sFlow and how it differs from NetFlow. Sampling forms an integral part of sFlow. It is similar to taking random snapshots or sampling vehicles traveling from point A to point B at a given period. SFlow was designed to perform flow-export by random sampling of packets and time-based sampling of network interfaces, and not by considering every packet. This enables it to achieve scalability, making it ideal for use in high-speed networks because of its ability to scale.

By enabling network admins to gain deep visibility into network usage and active routes of complex and high-speed networks, sFlow provides the data required to effectively control and manage network usage, ensuring that network services perform optimally. sFlow is supported by multiple network device manufacturers and network management software vendors such as IBM, HP, Cisco, Dell, Alcatel-Lucent, Aruba, and a host of others.

How sFlow Works

An sFlow system consists of multiple devices performing two types of sampling: random sampling of packets, and time-based sampling of counters. The sampled packet and counter information referred to as flow samples and counter samples respectively, are sent as sFlow datagrams to a central server running software that analyzes and reports on network traffic; the sFlow collector.

An sFlow monitoring system architecture consists of the following key components:

• sFlow Agent A function assigned to network devices such as switches and routers that collect information from outgoing packets and forward the samples.
• sFlow Collector A function assigned to review the information of each sFlow Agent created.

The sFlow exporter collects prefixes from random samples of all the packets passing through the monitored interface. Based on a defined sampling rate, an average of 1 out of n number of packets is randomly sampled. The exporter then assembles each sampled packet with device counters and sends it out to the sFlow collector. This type of sampling may not give you a high-level accuracy, but it does provide important information you need to make informed decisions. The device does not cache any of the data or sampled packet, thereby reducing resource usage. This ensures that performance is not impeded and makes it easy to scale up to high-speed networks.

Why Use sFlow? 

The network generates traffic. The sFlow protocol offers network admins the opportunity to capture and monitor this traffic for abnormal patterns. sFlow makes these abnormal traffic patterns visible with detailed information to support response efforts and corrective actions. sFlow can be used to spot congested links and identify the source of the traffic, and the associated application, device, or user.

sFlow forwarding information can be used to profile the most active routes and the type of flows carried by these routes. Understanding the routes and specific flows they carry makes it easier to know when to optimize routing to improve connectivity and performance. According to sFlow official documentation, “when sFlow is used to build a detailed traffic history a baseline of normal behavior is established, from which anomalies can be detected and suspicious activity identified”.

sFlow Limitations

The following are some of the known limitations of the sFlow protocol.

• Device Compatibility Before you can have complete visibility of what is going on in your network, every network device in your environment needs to be sFlow compatible. If the number of supported sFlow devices is limited then this is going to further weaken the quality of your results. Before adopting sFlow as a flow monitoring protocol, ensure that the devices in your network infrastructure can support the sFlow protocol.
• Lack of  In-Depth Visibility Unlike NetFlow, sFlow does not provide a packet-level details view. The use of a sampling means that only randomized packets rather than the entirety of the packets transmitted are captured. Depending on the sampling rate, this leaves large gaps in your visibility and reduces your chances of detecting malicious traffic. This makes sFlow unsuitable in networks where in-depth analysis and visibility are required.
• Accuracy Depending on the defined sampling rate, unreliable and inaccurate sample data may result. To get an accurate reading, you need to ensure that the sample rate is sufficiently high enough.

Table 1.0 | sFlow vs NetFlow: feature comparison table

Choosing Between NetFlow and sFlow

Now that we have examined the two flow monitoring protocols in detail, the burning question on the lips of many network admins is: Which protocol is better? Which one should I use? Well, there is really no definite answer. What fits perfectly from a feature and functionality standpoint for one organization may not fit for another. You need to consider some factors such as visibility, performance, accuracy, and latency, among others. Do you want to have a deep network-wide picture of what’s going on in your network or you’re just okay with the important stuff? Between accuracy and performance—which is more important to your business? Are you comfortable with a few minutes of latency? Is your network made of low-end or high-end devices?

Typically, sFlow places less demand on the network and compute resources than NetFlow. So for SMBs and smaller networks that use low-end devices, sFlow may be more suitable in such environments to minimize performance issues. Although NetFlow might collect more information and provide greater visibility, it may suffer a higher level of latency than sFlow. All the huge data captured by NetFlow may not be needed on smaller networks, and the network analyzer may not be able to process all the data.

Many networks are heterogeneous in composition—contain devices from multiple vendors. So one key factor to consider is, what protocol does your network equipment support?  If some of your equipment supports one but not the other, then it makes sense to choose the one already supported in your network. If your network infrastructure supports both NetFlow and sFlow, then you may consider using both to get the best of both worlds.