Netflow

This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations where appropriate. (March 2009)

NetFlow architecture

NetFlow is a network protocol developed by Cisco Systems to run on Cisco IOS-enabled equipment for collecting IP traffic information. It is proprietary and supported by platforms other than IOS, such as Juniper routers, Linux or FreeBSD and OpenBSD.

Protocol description

Cisco routers 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:

• Jflow or cflowd for Juniper Networks
• NetStream for 3Com/H3C
• NetStream for Huawei Technology
• Cflowd for Alcatel-Lucent

NetFlow and IPFIX

Although initially implemented by Cisco, NetFlow is emerging as an IETF standard: Internet Protocol Flow Information eXport (IPFIX). Based on the NetFlow Version 9 implementation, IPFIX is the industry standard with RFC5101, RFC5102, etc. Network infrastructure vendors are already adding IPFIX support to their devices.

Network Flows

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:

1. Source IP address
2. Destination IP address
3. Source port for UDP or TCP, 0 for other protocols
4. Destination port for UDP or TCP, type and code for ICMP, or 0 for other protocols
5. IP protocol
6. Ingress interface (SNMP ifIndex)
7. IP Type of Service

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.

Netflow Record

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:

• Version number
• Sequence number
• Input and output interface indices used by SNMP (ifIndex in IF-MIB).
• 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:
  • Source & destination IP addresses
  • Source and destination port numbers
  • IP protocol
  • Type of Service (ToS) value
• In the case of 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)

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.

Sampled NetFlow

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 n^th 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)

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.^{[neutrality disputed]}

NetFlow Monitoring Based on Standalone Probes

This section may contain original research or unverified claims. Please improve the article by adding references. See the talk page for details. (March 2009)

NetFlow architecture using standalone probes.

Although frequently used, the router-based approach suffers from several limitations:

• Enabling NetFlow monitoring on software-based routers (for example Cisco 7200) may reduce the routing performance.
• Even when using built-in hardware (like on Cisco or Alcatel/Lucent high-end routers) or dedicated hardware (like on Juniper or Huawei high-end routers) the number of supported packets/sec or flows/sec will be limited by the available processing power and memory (for the flow cache), and make sampling mandatory, at least on typical Internet backbone traffic.
• Due to sampling or flow processing limitations, the provided statistics may not be reliable enough for billing (under evaluation of volumes) or security applications (higher inaccuracy of Netflow when lots of small packets must be processed).
• The routers have fixed placement, and layer 3 visibility makes them a target for attacks.

For this reason, a new approach in NetFlow monitoring using standalone NetFlow probes is becoming very popular. This approach overcomes some limitations of router-based NetFlow monitoring. The probes are transparently connected to the monitored link as a totally passive appliance using the TAP or SPAN port of the appliance. NetFlow probes use a dedicated link for NetFlow exports, so they are completely invisible on the monitored link. Moreover, Deep packet inspection is easier to implement in a dedicated probe than in a router, and NetFlow can then be used to report details about packets that could less easily be provided by a router, or at least not at the same cost.

However, this approach 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 the exact same routing information as a router.

So NetFlow on dedicated probes is well adapted to the observation of critical links, whereas NetFlow on routers provides a Network-wide view of the traffic that is accurate enough, in practice, for traffic observation and network planning.

Versions

This section contains information which may be of unclear or questionable importance or relevance to the article's subject matter. Please help improve this article by clarifying or removing superfluous information.

See also

• IP Flow Information Export (IPFIX) - IETF work to standardize flow export, based on NetFlow version 9
• sFlow - alternative to Netflow (mandatory sampling, no flow cache, no templates)

External links

• NetFlow Tutorial for Cisco routers and switches
• Basic NetFlow information on the Cisco Site
• RFC3334 - Policy-Based Accounting
• RFC3954 - NetFlow Version 9
• 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

• List of software related to flow accounting