Following the Flow: Looking at Network Traffic in Two Ways
NetFlow and sFlow give administrators a new perspective.
By Michael Patterson
As network complexity has grown, network monitoring methods have evolved. Originally, network monitoring for most companies simply meant making sure the connections were live. A utility would regularly ping all of the critical devices on the network, and if one didn't respond, it sent out a notification. In the early 90s, these utilities started generating synthetic transactions to ensure, not only that there was a connection, and that the actual application was running. This enabled the generation of response time and availability reports. Now, most network monitoring applications are even providing SNMP (Simple Network Management Protocol) trends.
In the meantime, networking hardware vendors enhanced management features for their own equipment, including improving graphical interfaces to configure their gear. The hardware vendors also upped the granularity of the data they provide to the Network Management System (NMS). Cisco released NetFlow as part of its Internet Operating System and Inmon Corporation created sFlow, an embedded chip-based reporting technology. Cisco made its NetFlow technology available for use by other vendors, and NetFlow v.9 now forms the basis of the Internet Engineering Task Force's Internet Protocol Flow Information eXport (IPFIX). Either sFlow or NetFlow are supported by most major networking vendors including Alcatel-Lucent, Brocade, Cisco, Enterasys, Extreme Networks, Foundry Networks, Hewlett-Packard, Hitachi, IBM, Juniper, NEC, and others.
Both technologies are designed to address the same problem -- finding what traffic is moving across a router or switch by examining the packets -- but they take very different approaches.
NetFlow and sFlow each consist of two different elements: a flow generator and a flow collector. A generator is the function within the switch or router that examines the characteristics of the packets coming through. A flow collector is a server with software that collects the flow data from the network devices, stores and analyzes that data, and provides reports and alerts. There are dozens of different collectors, some of which work with NetFlow and sFlow, as well as other related technologies such as IPFIX, jFlow, and NetStream.
A flow consists of a stream of packets being transmitted from a source to a destination. Traditional NetFlow uses seven key fields (source IP address, destination IP address, source port, destination port, Layer 3 protocol, Type of Service byte, and input interface) to identify a packet and determine if it belongs to a particular flow. It then creates a record for that flow detailing the number of packets in the flow, as well as the listing the seven fields. It assembles data on up to thirty flows and transmits this as a group to the collector.
The latest release, NetFlow v.9, incorporates Flexible NetFlow, allowing users to select which of those seven fields to use rather than collecting all of them, saving bandwidth. Users can select additional data fields to store with the stream information, such as timestamps and subnet masks.
Originally developed by Inmon Corporation, sFlow is now a public standard managed by sFlow.org. In addition to Inmon, members include Brocade, Extreme Networks, Plixer, Hewlett-Packard, Hitachi, and Network Instruments. Instead of utilizing the switch's processing power, sFlow comes embedded on its own chip. Unlike NetFlow (which analyzes every packet to determine what flow it belongs to), sFlow samples the packets, only analyzing one out of every X number of packets. (NetFlow can be configured for sampling, but in most cases analyzes each one.) As with NetFlow, you will need a collector to act as an sFlow monitor.
Sampling creates a tradeoff between speed and accuracy. Analyzing each packet with NetFlow provides greater accuracy, but under very heavy loads can slow traffic by overloading the processor. As a result, it is common to have only certain ports watched by NetFlow rather than looking at everything going through the switch. Sflow, on the other hand, eliminates this issue both by having its own processor and by using sampling. Although this may not be as accurate, every port can be watched. Another sFlow advantage is that it examines Layer-2 data, which NetFlow does not. However, since NetFlow is non-sampled, it provides very accurate Layer-3 and Layer-4 data for billing purposes. Enterasys is the only vendor known to have implemented NetFlow support in hardware (i.e., similar to sFlow).
In addition to the usual chip-based sFlow, InMon also created a software version to address problems of virtualization. VMware and Xen make use of "virtual switches" to connect virtual machines together and to the network. InMon's Virtual Probe software provides sFlow monitoring on those virtual switches.
Middle of the Road
Flow monitoring fits in between SNMP monitoring (which provides a high level view of the aggregate amount of traffic through a switch) and packet analyzers (which provide a very granular look at that traffic). Each has its own purpose.
Because flow monitoring indicates which applications or users are generating the traffic, flow monitoring serves several purposes outside of just monitoring the load on a switch. By analyzing and utilizing flow information, developers can tune their applications for greater efficiency and users can be blocked from hogging bandwidth with unauthorized activities.
Usage can be tracked for billing purposes. In addition, identifying how much traffic each application generates makes it easier to do capacity planning. Administrators can also set up alarms to inform them when unauthorized traffic is on the network, and the flow collection software can alert the security system to automatically shut down certain users or ports to prevent damage or data loss.
Making a Choice
Given these characteristics, which technology is better?
Both have their advantages and their advocates, and most administrators will never need to answer that question. The equipment vendor decides which protocol to support, and, NetFlow vs. sFlow will probably not be the key issue in selecting a piece of hardware.
The real question, then, is what type of flow collection software to buy. What is the best NetFlow analyzer to meet your requirements? Several simple freeware versions are available that may be adequate for your needs when you are first exploring the advantages of flow monitoring. For full functionality, including integration with NMS software and security applications, there are commercial versions. One key feature to look for is the number of flow protocols it supports. Even if you are fully a Cisco shop today, getting multiprotocol flow software protects against vendor lock-in.
Michael Patterson is the product manager for the Scrutinizer NetFlow and sFlow Analyzer at Plixer International. Previously, Plixer Michael worked for Cabletron Systems as the director for outsourced network management. You can contact the author at email@example.com