There was a time when enterprises looking for network hardware compared and selected their equipment based on forwarding capabilities, bits supremacy, expansion options, integrated services, redundancy, manageability and more. Even though bandwidth was expensive, traffic monitoring and analytics were secondary. Terms such as distributed denial of service (DDoS) attacks, zero-day malware, non-business applications, social media, teleworking, bring your own device and software-as-a-service were mostly unknown.
Today, all of these developments are familiar territory to IT execs. And with those developments, factors such as bandwidth, security and application priority or problems encompassing bandwidth hogs, bottlenecks, phishing attempts and rogue applications have become everyday chores. Traffic analytics and bandwidth monitoring are now a necessity.
For those shopping for new network hardware, built-in traffic analytics are near the top of the desired features list. But when considering flow-based analytics technologies such as NetFlow and sFlow, which is best and how do you choose between them?
First, some background. NetFlow is a proprietary Cisco protocol supported on almost all Cisco IOS devices, starting from the 800 series. While most routers support NetFlow, among Cisco switches, older or low end models do not come with NetFlow support. Alternatively, you need additional services cards or the latest supervisor engine. If you have the budget for high-end switches like the 6500 series or newer Cisco switches like Nexus, 3850, etc., NetFlow is built in. It is also supported on Adtran devices, some models of Enterasys Networks Inc. switches, firewalls from Check Point Software Technologies Ltd., Cisco ASA, Palo Alto Networks and Sonicwall, as well as WAN accelerators from Riverbed Technology.
sFlow is a standard from the sFlow.org consortium. It is supported on a number of devices, including those manufactured by Alcatel-Lucent, Allied Telesis, Brocade Communications Systems (including Foundary), Dell Inc., Enrarasys, Fortinet Inc., HP, IBM, Maipu Communication Technology, NetGear and Vyatta.
Captured information: Flows versus packets
NetFlow is what it claims to be -- flow analysis. When an IP flow passes through an interface, key information about the flow is captured and stored in a cache. This data, known as NetFlow, is then exported based on the active and inactive timeouts. Here, "flow" refers to a traffic conversation between two hosts through an interface. NetFlow, due to its focus on flows, captures information about all IP traffic conversations that pass through an interface and reports the entire interface traffic.
sFlow is a packet sampling technology. sFlow captures 1 in "n" packets (where "n" is the sampling rate) from the interface traffic, copies the first "x" bytes (the default is 128 bytes for sFlow v5) of the sampled packet and exports them in user datagram packets (UDP) packets called sFlow datagrams. The first "x" bytes cover the relevant header data required to construct information about the traffic. But sFlow can miss IP flows, due to its focus on packets. When packets are captured for analysis, it is not necessary that the sampled packets represent every IP flow (conversation) that passed through an interface. IP flows whose packets were not collected will not be accounted for, resulting in some visibility gaps in network conversations.
Numerous, even legendary debates about accuracy
There have been numerous, and even legendary, debates about the accuracy of NetFlow versus sFlow packets. NetFlow, reflecting its focus on flows, will not miss IP conversations. With NetFlow, the total volume and packet count is bound to be closer to the actual stats. sFlow, due to its sampling nature, can miss out on IP conversations. For example, if packets that were part of a high-volume conversation were not captured for sampling, your sFlow traffic reports would not be able to account for those conversations and their volume. You may miss out on short bursts of IP conversations if their packets do not fall in the sampled set.
In my opinion, the difference is clear, but there are users who claim equal accuracy with NetFlow and sFlow. One advantage sFlow does enjoy is that it can capture all network traffic including IP and even legacy protocols such as IPX, Appletalk, etc., while NetFlow is limited to IP traffic and cannot capture legacy protocol information. For me, this is not a major advantage, but it's possible that there are a few environments where those legacy protocols still represent a significant portion of the traffic. (But I hope not.)
Do you want results right away?
After NetFlow metrics are generated and stored in the cache, they are exported based on the active and inactive timeouts. The lowest possible value for exporting active flows is one minute and inactive conversations are exported every 15 seconds. This means that information about ongoing conversations is exported with a delay of at least 1 minute. With sFlow, there are no active or inactive timeouts. The first "x" bytes of the sampled packets are captured and sent to your flow analysis tool in real time. For someone who really needs near real-time reports, sFlow can be the first choice, but you'll also have to invest in a tool that can report in less-than-one-minute averages.
Performance impact on the network
With NetFlow, the network device OS has to decode packets, extract information and create entries in the cache, which is then updated and exported. In high-traffic networks, this can impact the CPU. That's because the same CPU that takes care of packet processing also has to handle the NetFlow packets. According to Cisco, NetFlow export at 10,000 flows per second (fps) causes around 7% additional CPU utilization. At 65,000 fps, additional CPU utilization jumps to about 22%.
sFlow uses a dedicated chip built into the hardware for flow processing and therefore causes minimal impact to device performance. This allows sFlow enablement even on high traffic devices, yielding less concern about how it might impact other core processes. Scalability is an advantage for sFlow because it doesn't consume additional resources as the number of conversations increases. With the recent release by Cisco of the sampled NetFlow protocol to support ultra-high volume connection monitoring, however, that advantage has essentially been nullified.
Regardless of which technology you select, there will be an impact on collector bandwidth if you have thousands of distributed devices exporting to a single flow collector. That said, I've never seen a scenario where flow export took down a network, but if you do a lot of monitoring you will notice it on your gauges.
High-speed networks versus security
At 10 Gb and higher speeds, networks concentrate more conversations over fewer links, which, in turn, means more NetFlow or sFlow packets per device. NetFlow, due to being handled by the software, may cause performance issues when enabled on devices handling huge volumes of traffic. sFlow theoretically can be enabled on even 100 Gb networks and still not affect performance.
Security analytics call for the ability to analyze each network conversations in detail to detect small network anomalies that can cause big problems. For these applications, NetFlow is a better choice for network anomaly detection, due to its ability to capture all conversations. sFlow too may be used for anomaly detection, but the chance of it missing a critical flow is high because of its sampling nature. If your anomaly detection is at the edge where every conversation is critical, sFlow may fail to meet expectations.
New Technology Support
Cisco offers a robust set of monitoring features, further extended by Flexible NetFlow. This allows reporting on such components as network based application recognition (NBAR), Medianet, performance routing and application visibility and control (AVC) with the same tools you're already using for your traffic data. In addition, Flexible NetFlow supports new technologies like IPv6 traffic, MPLS labels, multicast traffic, media access control addresses, VLAN identification, jitter and round-trip time of media traffic. The downsides are that IOS upgrades are required and may not be available for all hardware, that it's still limited to IP protocol information and, finally, that most flow analyzers do not come with "out-of-the-box" support for new data fields.
Vendors other than Cisco don't offer the same range of monitoring technologies, and, for the technologies that are available, sFlow integration is not an option. But when it comes to traffic monitoring, sFlow -- since it's based on actual packet headers -- can cover Layer 2 to Layer 7 information, including new technologies. sFlow can also accommodate legacy protocols, along with IP protocols. Keep in mind: Though your devices may not need an upgrade to support new technologies in sFlow, your flow analyzer must be capable of processing the new fields.
When in doubt, ask around
So, will it be NetFlow or sFlow? Each technology has its own advantages. sFlow's advantages include the absence of a flow cache, which allows devices to concentrate on their core routing and switching functions. On the other hand, NetFlow is more accurate, enables users to drill down on each IP flow (which allows for better scope for root cause analysis) and is well-suited to detect any anomalies in network behavior.
If you need flow analysis at the access and distributed layer, including on switch ports, sFlow may be a fine choice. sFlow is supported by most of these devices and can report on important network conversations. It can also be enabled on switch ports, unlike NetFlow. When you move to the core layer, both flow technologies are suitable.
Although NetFlow cannot be enabled on switch ports and you will be limited to seeing only the switched traffic from your L3 interfaces, its accuracy, ability to account for all layer 3 conversations and use in LAN-level network anomaly detection give it an advantage. The same argument holds for edge devices too. WAN traffic analysis is critical and NetFlow is the ideal choice at the WAN and edge due to its reporting accuracy.
(The advent of software-defined networking and OpenFlow may also elevate sFlow over NetFlow, although it's too early to authoritatively comment. This could change if the IP Flow Information Export standard is quickly adopted by more vendors interested in IPFIX's variable length string advantage for sending data.)
Finally, it's all about making use of both NetFlow and sFlow, based on what is available and your individual requirements. It's also important to use the correct network traffic analyzer tool, one that can handle both NetFlow and sFlow data and present all of your traffic data in a single view. Using a protocol-agnostic tool from a reliable vendor, you can select the best flow technology for each segment of your network, giving you the best of both worlds.
Don Jacob is a SolarWinds Head Geek. He worked as a tech support engineer, product blogger, product evangelist and tech marketing lead before joining SolarWinds in 2013. His interests include network performance monitoring solutions, flow-based monitoring technologies like NetFlow, sFlow and IPFIX, and Cisco's offering for traffic analytics such as Flexible NetFlow, Cisco ASA NSEL, Cisco NBAR, Cisco QoS reporting, Cisco IPSLA and Cisco Medianet and MediaTrace.
This was first published in June 2013