Netflow is a feature that was introduced on Cisco routers that give the ability to collect IP network traffic as it enters or exits an interface. By analyzing the data that is provided by Netflow a network administrator can determine things such as the source and destination of the traffic, class of service, and the cause of congestion. Netflow consists of three components: flow caching, Flow Collector, and Data Analyzer.
- 1 Protocol description
- 2 NetFlow Versions
- 3 NetFlow variants
- 4 History
- 5 See also
- 6 References
- 7 External links
Routers and switches that support NetFlow can collect IP traffic statistics on all interfaces where NetFlow is enabled, and later export those statistics as NetFlow records, toward at least one NetFlow collector - typically a server that does the actual traffic analysis.
A network flow can be defined in many ways. Cisco standard NetFlow version 5 defines a flow as a unidirectional sequence of packets that all share the following 7 values:
- Ingress interface (SNMP ifIndex)
- Source IP address
- Destination IP address
- IP protocol
- Source port for UDP or TCP, 0 for other protocols
- Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols
- IP Type of Service
Note that the Egress interface, IP Nexthop or BGP Nexthops are not part of the key, and may not be accurate if the route changes before the expiration of the flow, or if load-balancing is done per-packet.
Advanced NetFlow or IPFIX implementations like Cisco Flexible NetFlow allow user-defined flow keys.
A typical output of a NetFlow command line tool (
nfdump in this case) when printing the stored flows may look as follows:
Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows 2010-09-01 00:00:00.459 0.000 UDP 127.0.0.1:24920 -> 192.168.0.1:22126 1 46 1 2010-09-01 00:00:00.363 0.000 UDP 192.168.0.1:22126 -> 127.0.0.1:24920 1 80 1
Export of NetFlow records
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.
NetFlow Packet transport protocol
NetFlow records are traditionally exported using User Datagram Protocol (UDP) and collected using a NetFlow collector. The IP address of the NetFlow collector and the destination UDP port must be configured on the sending router. The standard value is UDP port 2055, but other values like 9555 or 9995, 9025, 9026 etc. can also be used.
For efficiency reasons, the router traditionally does not keep track of flow records already exported, so if a NetFlow packet is dropped due to network congestion or packet corruption, all contained records are lost forever. The UDP protocol does not inform the router of the loss so it can send the packets again. This can be a real problem, especially with NetFlow v8 or v9 that can aggregate a lot of packets or flows into a single record. A single UDP packet loss can cause a huge impact on the statistics of some flows.
That is why some modern implementations of NetFlow use the Stream Control Transmission Protocol (SCTP) to export packets so as to provide some protection against packet loss, and make sure that NetFlow v9 templates are received before any related record is exported. Note that TCP would not be suitable for NetFlow because a strict ordering of packets would cause excessive buffering and delays.
The problem with SCTP is that it requires interaction between each NetFlow collector and each routers exporting NetFlow. There may be performance limitations if a router has to deal with many NetFlow collectors, and a NetFlow collector has to deal with lots of routers, especially when some of them are unavailable due to failure or maintenance.
SCTP may not be efficient if NetFlow must be exported toward several independent collectors, some of which may be test servers that can go down at any moment. UDP allows simple replication of NetFlow packets using Network taps or L2 or L3 Mirroring. Simple stateless equipment can also filter or change the destination address of NetFlow UDP packets if necessary. Since NetFlow export almost only use network backbone links, packet loss will often be negligible. If it happens, it will mostly be on the link between the network and the NetFlow collectors.
NetFlow Packet header
All NetFlow packets begin with version-dependent header, that contains at least these fields:
- Version number (v5, v8, v9, v10)
- Sequence number to detect loss and duplication
- Timestamps at the moment of export, as system uptime or absolute time.
- Number of records (v5 or v8) or list of templates and records (v9)
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:
- Input interface index used by SNMP (ifIndex in IF-MIB).
- Output interface index or zero if the packet is dropped.
- Timestamps for the flow start and finish time, in milliseconds since the last boot.
- Number of bytes and packets observed in the flow
- Layer 3 headers:
- For TCP flows, the union of all TCP flags observed over the life of the flow.
- Layer 3 Routing information:
- IP address of the immediate next-hop (not the BGP nexthop) along the route to the destination
- Source & destination IP masks (prefix lengths in the CIDR notation)
For ICMP flows, the Source Port is zero, and the Destination Port number field codes ICMP message Type and Code (port = ICMP-Type * 256 + ICMP-Code).
The source and destination Autonomous System (AS) number fields can report the destination AS (last AS of AS-Path) or the immediate neighbor AS (first AS of AS-Path). depending on the router configuration. But the AS number will be zero if the feature is not supported, the route is unknown or not announced by BGP, or the AS is the local AS. There is no explicit way to distinguish between these cases.
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 is usually enabled on a per-interface basis to limit load on the router components involved in NetFlow, or to limit the amount of NetFlow records exported.
NetFlow usually captures all packets received by an ingress IP interface, but some NetFlow implementations use IP filters to decide if a packet can be observed by NetFlow.
Some NetFlow implementations also allow the observation of packets on the egress IP interface, but this must be used with care: all flows from any ingress interface with NetFlow enabled to any interface with NetFlow enabled could be counted twice.
Standard NetFlow was designed to process all IP packets on an interface. But in some environments, e.g. on Internet backbones, that was too costly, due to the extra processing required for each packet, and large number of simultaneous flows.
So Cisco introduced sampled NetFlow on Cisco 12000, and that is now used in all high-end routers that implement NetFlow.
Only one packet out of n is processed, where n, the sampling rate, is determined by the router configuration.
The exact selection process depends on the implementation:
- One packet every n packet, in Deterministic NetFlow, as used on Cisco's 12000.
- One packet randomly selected in an interval of n packet, in Random Sampled NetFlow, used on modern Cisco routers.
Some implementations have more complex methods to sample packets, like per-flow sampling on Cisco Catalysts.
The sampling rate 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)
|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.|
|v10||aka IPFIX, IETF Standardized NetFlow 9 with several extensions like Enterprise-defined fields types, and variable length fields.|
NetFlow and IPFIX
NetFlow was initially implemented by Cisco, and described in an "informational" document that was not on the standards track: 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 on the IETF standards track with RFC 5101, RFC 5102, etc. which were published in 2008.
Many vendors other than Cisco provide an equivalent technology on their routers and switches, but some use a different name for the technology, probably because NetFlow is thought to be a Cisco trademark (even though as of March 2012 it is not listed in Cisco Trademarks):
- Jflow or cflowd for Juniper Networks
- NetStream for 3Com/HP
- NetStream for Huawei Technologies
- Cflowd for Alcatel-Lucent
- Rflow for Ericsson
- AppFlow Citrix
- sFlow vendors include: Alaxala, Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Cisco, Dell, D-Link, Enterasys, Extreme, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, Mellanox, MRV, NEC, Netgear, Proxim Wireless, Quanta Computer, Vyatta, ZTE and ZyXEL
|Vendor and type||Models||NetFlow Version||Implementation||Comments|
|Cisco IOS-XR routers||CRS, ASR9000 old 12000||v5, v8, v9||Software running on line card CPU||Comprehensive support for IPv6 and MPLS|
|Cisco IOS routers||10000, 7200, old 7500||v5, v8, v9||Software running on Route Processor||support for IPv6 or MPLS require recent model and IOS|
|Cisco Catalyst switches||7600, 6500, 4500||v5, v8, v9||Dedicated hardware TCAM, also used for ACLs.||Support for IPv6 on high-end models RSP720 and Sup720, but at most 128K or 256K flows per PCF card.|
|Cisco Nexus switches||7018, 7010||v5, v9||Dedicated hardware TCAM, also used for ACLs. Up to 512K flows. Support IPv4/IPv6/L2.||MPLS not supported|
|Juniper legacy routers||M-series, T-series, MX-series with DPC||v5, v8||Software running on Routing Engine, called software jflow||IPv6 and MPLS not supported|
|Juniper legacy routers||M-series, T-series, MX-series with DPC||v5, v8, v9||Software running on service PIC, called hardware jflow or sampled||IPv6 or MPLS supported on MS-DPC, MultiService-PIC, AS-PIC2|
|Juniper routers||MX-series with MPC-3D, future FPC5 for T4000||v5, IPFIX||Hardware (trio chipset), called inline jflow||IPv6 requires JUNOS 11.4R2 (back port target), MPLS support unknown, MPC3E excluded until 12.3|
|Alcatel-Lucent routers||7750SR||v5, v8, v9, IPFIX||Software running on Central Processor Module||IPv6 or MPLS using IOM3 line cards or better|
|Huawei routers||NE5000E NE40E/X NE80E||v5, v9||Software running on service cards||Support for IPv6 or MPLS is unknown|
|Enterasys Switches||S-Serie and N-Serie||v5, v9||Dedicated hardware||IPv6 support is unknown|
|INVEA-TECH probes||FlowMon Probe 1000, 2000, 4000, 6000, 10000, 20000||v5, v9, IPFIX||Software or hardware-accelerated||Comprehensive support for IPv6 and MPLS, wire-speed|
|Nortel Switches||Ethernet Routing Switch 5500 Series (ERS5510, 5520 and 5530) and 8600 (Chassis-based)||v5, v9, IPFIX||Software running on line card CPU||Comprehensive support for IPv6|
|PC and Servers||Linux FreeBSD NetBSD OpenBSD||v5, v9, IPFIX||Software like fprobe, ipt-netflow, pflow, or softflowd||IPv6 support depend on the software used|
|VMware servers||vSphere 5.x||v5, IPFIX (>5.1)||Software||IPv6 support is unknown|
|Mikrotik RouterOS||RouterOS 3.x, 4.x, 5.x||v1, v5, v9||Software and Routerboard hardware||IPv6 support is unknown|
Cisco's NetFlow Security Event Logging
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 Monitoring Based on Standalone Probes
||This section possibly contains original research. (March 2009)|
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, NetFlow monitoring is easier to implement in a dedicated probe than in a router. However, this approach also has some drawbacks:
- probes must be deployed on every link that must be observed, causing additional hardware, setup and maintenance costs.
- probes will not report separate input and output interface information like a report from a router would.
- probes may have problems reporting reliably the NetFlow fields related to routing, like AS Numbers or IP masks, because they can hardly be expected to use exactly the same routing information as a router.
The easiest way to address the above drawbacks is to use a Packet Capture Appliance inline in front of the router and capture all of the NetFlow output from the router. This method allows for storage of large amount of NetFlow data (typically many years worth of data) and does not require reconfiguration of the network.
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.
NetFlow was originally a Cisco packet switching technology for Cisco routers, implemented in IOS 11.x around 1990. It was originally a software implementation for the Cisco 7000, 7200 and 7500, where it was thought as an improvement over the then current Cisco Fast Switching.
The idea was that the first packet of a flow would create a NetFlow switching record. This record would then be used for all later packets of the same flow, until the expiration of the flow. Only the first packet of a flow would require an investigation of the route table to find the most specific matching route. This is an expensive operation in software implementations, especially the old ones without Forwarding information base. The NetFlow switching record was actually some kind of route cache record, and old versions of IOS still refer to the NetFlow cache as ip route-cache.
This technology was advantageous for local networks. This was especially true if some of the traffic had to be filtered by an ACL as only the first packet of a flow had to be evaluated by the ACL.
NetFlow switching soon turned out to be unsuitable for big routers, especially Internet backbone routers, where the number of simultaneous flows was much more important than those on local networks, and where some traffic causes lots of short-lived flows, like Domain Name System requests (whose source port is random for security reasons).
As a switching technology, NetFlow was replaced around 1995 by Cisco Express Forwarding. This first appeared on Cisco 12000 routers, and later replaced NetFlow switching on advanced IOS for the Cisco 7200 and Cisco 7500.
- Traffic flow (computer networking)
- IP Flow Information Export (IPFIX) - IETF standards-track flow export protocol, based on NetFlow version 9
- sFlow - alternative to NetFlow (mandatory sampling, no flow cache, no templates )
- "Cisco Trademarks".
- "sFlow Products: Network Equipment". sFlow.org.
- "Cisco RSP720 Sup720 NetFlow characteristics". cisco.com. July 2010. Retrieved 2012-03-08.
- "NetFlow on Enterasys S-Serie". enterasys.com. February 2012. Retrieved 2012-03-04.
- "NetFlow on Enterasys N-Serie". enterasys.com. February 2012. Retrieved 2012-03-04.
- Phaal, Peter; Lavine, Marc (July 2004). "sFlow Version 5". sFlow.org. Retrieved 2010-10-23.
- NetFlow/FloMA: Pointers and Software Provided by SWITCH. - One of the most comprehensive list including all the open source and research works.
- FloCon - The Annual Conference put on by CERT/CC dealing with NetFlow and other flow analysis works.
- Basic NetFlow information on the Cisco Site
- RFC3334 - Policy-Based Accounting
- RFC3954 - NetFlow Version 9
- RFC3917 - Requirements for IP Flow Information Export (IPFIX)
- RFC3955 - Candidate Protocols for IP Flow Information Export (IPFIX)
- RFC5101 - Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information (IPFIX)
- RFC5102 - Information Model for IP Flow Information Export
- RFC5103 - Bidirectional Flow Export Using IP Flow Information Export
- RFC5153 - IPFIX Implementation Guidelines
- RFC5470 - Architecture for IP Flow Information Export
- RFC5471 - Guidelines for IP Flow Information Export (IPFIX) Testing
- RFC5472 - IP Flow Information Export (IPFIX) Applicability
- RFC5473 - Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports
- Using Netflow to store re-aggregated inbound and outbound flows
- AppFlow specifications and standards track discussion