NetFlow is a protocol for collecting, aggregating and recording traffic flow data in a network. NetFlow data provide a more granular view of how bandwidth and network traffic are being used than other monitoring solutions, such as SNMP.
NetFlow was developed by Cisco and is embedded in Cisco’s IOS software on the company’s routers and switches and has been supported on almost all Cisco devices since the 11.1 train of Cisco IOS Software. Many other hardware manufacturers either support NetFlow or use alternative flow technologies, such as jFlow or sFlow.
There are technically ten different versions of NetFlow. However, several versions were released only internally or were never widely implemented beyond specific hardware.
The original NetFlow version 1 is considered obsolete, and seldom used today. Versions 2 through 4 were internal versions, no public implementation was ever released.
Version 5 is still commonly used today, because of a large existing install base of Cisco routers and switches released while it was the standard version. It added Border Gateway Protocol information and flow sequence numbers to NetFlow Exports. It only works with IPv4 flows.
Version 6 is no longer supported and was not released widely. Version 7 added support for Cisco Catalyst switches using hybrid or native mode. Version 8 has support for when router-based NetFlow aggregation is used.
Version 9 is the current version and is template-based. As such, it allows for expanded support without necessitating a change to the flow-record format. This version is preferred for IETF IP Information Export (IPFIX) WG and IETF Pack Sampling WG (PSAMP) and works with both IPv4 and IPv6.
IPFIX is often referred to as NetFlow v10 because it is based on NetFlow v9, but actually it is not NetFlow.
|v1||First implementation, now obsolete|
|v2||Internal version, no public release|
|v3||Internal version, no public release|
|v4||Internal version, no public release|
|v5||Still commonly used today, only works with Ipv4 flows|
|v6||No longer supported|
|v7||Added support for Cisco Catalyst switches|
|v8||Supports router-based NetFlow aggregation|
|v9||Current version, template-based, works with IPv6|
|v10||Used for identifying IPFIX|
Almost all Cisco devices support NetFlow. The only exception are Cisco 2900, 3500, 3660, 3750. Moreover, NetFlow is available for many routers and switches of other vendors.
|Vendor + Type||Models||Supported NetFlow Versions|
|Alcatel-Lucent router||7750SR||v5, IPFIX|
|Juniper legacy router||M-series, T-series, MX-series with DPC||v5, v8, v9|
|Juniper router||MX-series, FPC5 for T4000||v5, IPFIX|
|Enterasys Switch||S-Serie, N-Serie||v5, v9|
|Flowmon Probe||1000, 2000, 4000, 6000, 10000, 20000, 40000, 80000, 100000||v5, v9, IPFIX|
|Nortel Switch||ERS5510, ERS5520, ERS5530, 8600||v5, v9, IPFIX|
|Huawei router||NE5000E, NE40E/X NE80E||v5, v9|
Creating a flow
A flow is a way of grouping a unidirectional stream of packets into a specific set. These sets can be configured based on matching attributes in each packet including:
- IP Source
- IP Destination
- Source Port
- Destination Port
- Class of Service
- Layer 3 Protocol Type
As each packet is forwarded, the above attributes are examined. A flow is generated by the first packet passing through the standard switching path. Each additional packet with the same parameters (source and destination IP, address, source and destination port, class of service) is grouped into a single flow. Any variation in the value of any one of the parameters creates a new flow.
High-end Cisco routers support sampled NetFlow where only one out of a certain number of packets is examined. This is for use on routers where examining every packet is impractical due to volume of traffic. Sampled flows significantly reduce the performance impact when sending flow information.
Monitoring and grouping every packet forwarded by a router or switch generates a lot of data. This data is condensed into a database within the network device called the NetFlow cache. A flow record is kept for each active flow. Data is expired and then exported from the cache to a NetFlow collector server at regular intervals based on flow timers. The NetFlow cache is checked every second by default.
Flows are grouped for export into a NetFlow Export datagram. Each datagram consists of up to 30 flows. According to Cisco, standard NetFlow exports use about 1.5 percent of the total analyzed switched traffic.
The Version 9 flow record is template based. That means that future enhancements can be accommodated without having to change the basic flow record. The record format is defined by a packet header, followed by at least one template FlowSet and data FlowSet. The template FlowSet provides a description of what is coming in the data FlowSets. This is what allows for the extensibility of the record. Rather than pre-defining in a specification what data is coming and where, that definition is done within the packet itself.
The packet header is basically the same as in Version 5. It contains, among others, the version number for the packet, the system uptime (in milliseconds), a sequence number and the Source ID.
NetFlow data is periodically reported to a NetFlow collector. The collector is a different server or computer running a NetFlow receiver software designed to gather, record, filter, and analyze the resulting flows, such as Paessler’s PRTG NetFlow Analyzer. The collector software must support the same NetFlow version as the exporting server. For example, to monitor a Cisco router using NetFlow 5, one would need to use the NetFlow V5 Sensor in PRTG Network Monitor. For a router using NetFlow 9, one would need the NetFlow V9 Sensor. Both sensors can be enabled on the same machine at the same time, so that a single collector can receive and report on data from both NetFlow versions.
NetFlow datagrams are exported using User Datagram Protocol (UDP). The IP address of the collector and the destination port must be configured on the router or switch itself. In some cases, SNMP can be used to turn on NetFlow and configure the collector’s IP address to send the data to.
Within Cisco IOS, the ip flow-export command may be used to configure the destination IP from the command line.
One of the most popular ports used for NetFlow exports is 2055, but basically you can use any port as long as you specify it correctly in the NetFlow receiver. As NetFlow exports are pushed to the collector, there is no need for polling, but there is no auto-discovery process for NetFlow available like with SNMP because of this.
It is possible to access some NetFlow data via SNMP using the NetFlow MIB. While not designed to be a replacement for NetFlow export, it does offer a way to gain access to NetFlow data via another mechanism. Data available includes number of flows, flows per second and packets or bytes per flow. The ability to access a list of “top talkers” might also be useful in certain cases, but you get this data anyway when receiving and monitoring flows.
There are many traffic categories that can be monitored with NetFlow. The NetFlow V9 Sensor for PRTG, for example, allows monitoring and categorizing of numerous traffic types by default,
- Infrastructure (DHCP, DNS, ICMP, SNMP)
- Remote Control Protocols
- Total Traffic
The following shows the NetFlow Top Talkers command, which lists the largest packet and byte consumers of the network. Before using the Top Talkers command, it has to be configurated:
The top 10 talkers in network sorted by packets:
R3#show ip flow top-talkers
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Et1/0 172.16.10.2 Et0/0 172.16.1.84 06 0087 0087 2100
Et1/0 172.16.10.2 Et0/0 172.16.1.85 06 0089 0089 1892
Et1/0 172.16.10.2 Et0/0 172.16.1.86 06 0185 0185 1762
Et1/0 172.16.10.2 Et0/0 172.16.1.86 06 00B3 00B3 2
Et1/0 172.16.10.2 Et0/0 172.16.1.84 06 0050 0050 1
Et1/0 172.16.10.2 Et0/0 172.16.1.85 06 0050 0050 1
7 of 10 top talkers shown. 7 flows processed.
Network, user and application monitoring
The most obvious use for NetFlow is network monitoring. NetFlow data provides detailed bandwidth usage information that can be segmented in numerous ways, including by user, client system, time and application. The data arriving at the NetFlow collector is near-real time, allowing for specific granular monitoring and for aggregating data to look at the big picture as it is happening.
Monitoring traffic patterns, user patterns and application patterns can alert an administrator to potential problems before they happen and provide a valuable troubleshooting resource. A single computer or service using a sufficiently large amount of bandwidth can affect network performance for other users. An administrator watching a comprehensive user interface or dashboard may be able to detect this outcome before it happens, or an alert could be generated to let the network administrator know about unusual patterns.
The PRTG NetFlow V9 Sensor overview, for example, indicates Top Talkers, Top Connections, Top Protocols as wells as a breakdown by protocol, showing at a glance if some server or application is using too much (or too little) bandwidth.
The ability to detect and react to changing network conditions is a valuable ability. Even better is the capacity to see what is coming and proactively address any issues.
Capturing NetFlow data over longer periods of time and analyzing trends found within the data provides an opportunity to know in advance what the network requires. Perhaps various applications running at the end of the month generate additional traffic that affects network performance. In that case, other high-bandwidth activities could be scheduled for different times of the month to prevent bottlenecks.
Furthermore, NetFlow data can help determine when traffic growth is actually becoming too high for the current hardware to handle, offering plenty of lead-time to purchase, install and configure additional or faster routers and switches.
Usage-based billing and reporting
With its ability to identify specific traffic streams (including where they originated and which applications triggered them), NetFlow data can be analyzed to enable billing to clients, internal cost charge backs or show how much of the network is being used by specific users, groups or applications. With such detailed data collection, it is easy to adjust billing rates based on time of day or application usage or total bandwidth.
Application reporting and profiling
NetFlow data can show not only how much traffic an application generates, but when and for whom. NetFlow can tell if the application is optimized for the accounting group, but generates lots of traffic for a different department.
NetFlow can help with network security as well. Is a user suddenly generating large amounts of traffic not usually required for their job? Perhaps the account has been compromised? NetFlow data quickly reveals anomalies in network traffic, whether it’s a worm trying to spread, malware trying to contact a control server or a disgruntled employee copying sensitive company data.
While the overall traffic generated by NetFlow is relatively low, it is important to locate the NetFlow collectors strategically to avoid sending data over expensive connections or via those without the ability to handle additional traffic. Local collection works best for most environments.