NetFlow is a network protocol developed by Cisco Systems for collecting IP traffic information. NetFlow has become an industry standard for traffic monitoring and is supported by platforms other than Cisco IOS and NXOS such as Juniper routers, Enterasys Switches, vNetworking in version 5 of vSphere, Linux, FreeBSD, NetBSD and OpenBSD.
Contents |
Cisco routers and Enterasys Switches that have the NetFlow feature enabled generate NetFlow records; these are exported from the router in User Datagram Protocol (UDP) or Stream Control Transmission Protocol (SCTP) packets and collected using a netflow collector. Other vendors provide similar features for their routers but with different names:
Although initially implemented by Cisco, NetFlow is described in an informational document: RFC 3954 – Cisco Systems NetFlow Services Export Version 9. The NetFlow protocol itself has been superseded by Internet Protocol Flow Information eXport (IPFIX). Based on the NetFlow Version 9 implementation, IPFIX is the industry standard with RFC 5101, RFC 5102, etc. Network infrastructure vendors are already adding IPFIX support to their devices.
A network flow has been defined in many ways. The traditional Cisco definition is to use a 7-tuple key, where a flow is defined as a unidirectional sequence of packets all sharing all of the following 7 values:
Flexible NetFlow and IPFIX support user-defined flow keys.
The router will output a flow record when it determines that the flow is finished. It does this by flow aging: when the router sees new traffic for an existing flow it resets the aging counter. Also, TCP session termination in a TCP flow causes the router to expire the flow. Routers can also be configured to output a flow record at a fixed interval even if the flow is still ongoing. In Flexible NetFlow (FNF) an administrator could actually define flow properties on the router.
A NetFlow record can contain a wide variety of information about the traffic in a given flow. NetFlow version 5 (one of the most commonly used versions, followed by version 9) contains the following:
Some routers will also include the source and destination Autonomous System (AS) number. Depending on the router configuration, it can also be the immediate neighbor AS. That information is not always accurate, and the local AS will be indicated by the same value (zero) as any unknown AS.
NetFlow version 9 can include all of these fields and can optionally include additional information such as Multiprotocol Label Switching (MPLS) labels and IPv6 addresses and ports,
By analyzing flow data, a picture of traffic flow and traffic volume in a network can be built. The NetFlow record format has evolved over time, hence the inclusion of version numbers. Cisco maintains details of the different version numbers and the layout of the packets for each version.
NetFlow records are usually sent via a UDP or SCTP in newer software, and for efficiency reasons, the router does not store flow records once they are exported. Therefore, if the NetFlow record is dropped due to network congestion, it is lost forever—there's no way for the router to resend it (this is correct for UDP NetFlow only). The IP address of the netflow collector and the port upon which it is listening must be configured on the sending router but is usually either on ports 2055, 9555, or 9995. NetFlow is also enabled on a per-interface basis to avoid unnecessary burdening of the router's CPU. NetFlow is generally based on the packets input to interfaces where it is enabled. This avoids double counting and saves work for the router. It also allows the router to export NetFlow records for dropped packets.
ICMP records use the Destination Port number field to define the ICMP Type and CODE in HEX. The type and code are concatenated before the conversion. An ICMP Host Unreachable message would be TYPE 3 with a CODE of 01 (301). NetFlow converts this value to a hex value of 769 when exported.
This variant was originally introduced by Cisco, but is now used in all high-end routers that implement NetFlow. Maintaining NetFlow data can be computationally expensive for the router and burden the router's CPU or hardware to the point where it runs out of capacity. To avoid problems caused by router CPU load, Cisco provides "Sampled NetFlow". Rather than looking at every packet to maintain NetFlow records, the router looks at every nth packet, where n can be configured (as in Deterministic NetFlow, used on Cisco's GSRs) or it is a randomly selecting interval (as used in Random Sampled NetFlow, used on all other Cisco platforms). The sampling is often the same for all interfaces, but can be adjusted per interface for some routers. When Sampled NetFlow is used, the NetFlow records must be adjusted for the effect of sampling - traffic volumes, in particular, are now an estimate rather than the actual measured flow volume.
The sampling rate is indicated in a header field of NetFlow version 5 (same sampling rate for all interfaces) or in option records of NetFlow version 9 (sampling rate per interface)
Introduced with the launch of the Cisco ASA 5580 products, NetFlow Security Event Logging utilizes NetFlow v9 fields and templates in order to efficiently deliver security telemetry in high performance environments. NetFlow Security Event Logging scales better than syslog while offering the same level of detail and granularity in logged events.
NetFlow collection using standalone NetFlow probes is an alternative to flow collection from routers and switches. This approach can overcome some limitations of router-based NetFlow monitoring. The probes are transparently connected to the monitored link as a passive appliance using the TAP or SPAN port of the appliance.
Historically, Deep packet inspection is easier to implement in a dedicated probe than in a router. However, this approach also has some drawbacks:
NetFlow collection from dedicated probes is well suited for observation of critical links, whereas NetFlow on routers provides a Network-wide view of the traffic that can be used for capacity planning, accounting, performance monitoring, and security.
| Version | Comment |
|---|---|
| v1 | First implementation, now obsolete, and restricted to IPv4 (without IP mask and AS Numbers). |
| v2 | Cisco internal version, never released. |
| v3 | Cisco internal version, never released. |
| v4 | Cisco internal version, never released. |
| v5 | Most common version, available (as of 2009) on many routers from different brands, but restricted to IPv4 flows. |
| v6 | No longer supported by Cisco. Encapsulation information (?). |
| v7 | Like version 5 with a source router field. Used (only?) on Cisco Catalyst switches. |
| v8 | Several aggregation form, but only for information that is already present in version 5 records |
| v9 | Template Based, available (as of 2009) on some recent routers. Mostly used to report flows like IPv6, MPLS, or even plain IPv4 with BGP nexthop. |
| IPFIX | aka v10; IETF Standardized NetFlow 9 with several extensions like Enterprise-defined fields types, and variable length fields. |