NetFlow Monitor - Overview

NetFlow Overview

At first some theory and terminology;o)

1. What is NetFlow Flow?

NetFlow is a traffic monitoring technology developed by Cisco Networks. Flow is unidirectional data flow defined by seven fields: source IP address, destination IP address, L3 protocol type, source port, destination port, ToS byte (DSCP), input logical interface (ifIndex). Any other fields in NetFlow exports are determined for first flow packet or are or-ed (TCP flags) or summarized (bytes,packets).

2. What is NetFlow Export?

All data (only some fields of packet headers) walking through router or switch are cached in router and after expiration are flows grouped together into "NetFlow export" UDP datagrams for export to collector. UDP protocol isn't reliable, but UDP is faster and simpler then TCP protocol. Current Cisco IOSes support NetFlow only for ingress traffic, but for MPLS in new Cisco IOSes is feature to use NetFlow for egress traffic, too. See your vendor road-map if egress traffic is supported. All next is based on Cisco's features and terminology.

3. What is it good for?

NetFlow exports can be used with many applications, for example to:

  • network monitoring,
  • network planning,
  • security analysis,
  • application monitoring,
  • user monitoring,
  • traffic engineering,
  • peering agreement,
  • usage-based billing,
  • destination sensitive billing etc...
Main idea is accounting extensive data flow on active parts of your network with relatively simply and quick protocol.

4. NetFlow versions

A number of network equipment vendors have implemented their own versions of NetFlow. Now, several versions is used, but some aren't too used. Version 1 was first NetFlow export version and now isn't supported by routers (my collector support it for backward compatibility), version 5 is the most complete version, versions 6 and 7 are used on switches, version 8 is router-based aggregation and last version 9 is new flexible and extensible version. A number of network equipment vendors have implemented their own versions of NetFlow. Current public version of NetFlow Monitor supports non-aggregated NetFlow (versions 1,5,6 and 7) and is capable of analyzing NetFlow data from a number of vendors.
Non-aggregated NetFlow creates a flow record containing detailed information describing each IP flow. However, there is some variation in implementations from device to device and vendor to vendor, and so some fields may be missing or incomplete. The following table lists the attributes of a NetFlow version 5 record and identifies possible issues relating to each field:

  • Sampling interval - If packet sampling is used then the sampling interval needs to be known in order to properly scale traffic measurements.
  • Seven basic NetFlow types - non-aggregated description of IP flow is required. Some implementations allow IP addresses to be masked, make sure that this feature is disabled.
  • Next Hop - Important for understanding routing behavior.
  • Input and output SNMP ifIndex - Some implementations do not provide input/output interface information. This means that flows cannot be attributed to interfaces and interface utilization analysis is not possible.
  • Packets and octets - Accurate accounting of packets and octets within flows is essential for accurate traffic monitoring. Some implementations only account for the first packet in each flow, or do not provide octet counts.
  • Start and end Time - Accurate start and end times are essential for combining flow records to determine traffic breakdowns by time. Typically times are expressed in hundredth of a second, however, some implementations use seconds instead. NetFlow Monitor save all timestamps in seconds.
  • Source and destination AS - Important when monitoring BGP routers. NetFlow allows either source/destination AS number or source/destination peer AS numbers to be exported, but not both.

5. Vendors

The following vendors have devices capable of exporting NetFlow data:

  • Cisco Networks - Cisco's support for NetFlow varies by device and IOS release.
  • Enterasys
  • Extreme Networks - Doesn't support input/output interface, octets or first and last times.
  • Foundry Networks
  • Juniper Networks - Doesn't support sampling interval. First and last times in seconds rather than milliseconds.
  • Riverstone Networks - No native NetFlow support. However, Riverstone provides a converter that translates the LFAP records from their devices into NetFlow.

For more check cisco web pages.


Flows exported from a router/switch are encapsulated in a UDP datagram. Each {engine_type,engine_id} pair generate a unique sequence number. The sequence number is the total flows generated by the linecards. There are no cryptographic checksums and no retransmissions for lost packets. The sequence number is 32 bits, engine_type and engine_id are both 8 bits. This leads to 65536 unique 32 bit sequence numbers.

In the future NetFlow Monitor will log out of sequence flow export packets. It will be possibility to reject out of sequence. Logging will be done via syslog.

Loss of flow exports is usually a result of resource exhaustion on the router, link to the flow collector, or the flow collector itself. "router# show ip flow export" on the router will list some sources of lost flows. Check output drops on the interface directly connected to the NetFlow Collector. On 7500's the interface command "transmit-buffers backing-store" can reduce output drops. Use netstat -s on the flow collector to display UDP packets dropped due to full socket buffers. This is usually an indication of an overworked server.

The sequence numbers change fast enough on a busy router that an attacker would probably need to snoop the path between the exporter and the router to successfully inject packets for a valid engine. Unfortunately there is nothing preventing an attacker from using an {engine_type,engine_id} pair that is not in use by the router to inject their own flows. There is currently no way to know which {engine_type,engine_id} pairs the router will use.

To defend against an attacker injecting bogus flow exports the path between the router and flow collector must prevent source IP address spoofing, either with access lists or unicast RPF(reverse-path-forwarding) checks. NetFlow Collector can restrict access (source address(es)) from which accept netflow packets. (see Option->Plugins->InputACL). Configure 'ip flow-export source loopback0' and set a loopback0 address on the router to ensure the same IP address is always used when exporting flows.

Another option the attacker has is to disable or disrupt the flow collection server. This could be done by packet flooding the server or the path to it, resulting in lost flow exports. Ideally the flow collector would be directly connected to the router on a dedicated interface with strict access lists only permitting the flow exports and administrative traffic.