Since NetFlow is an important part of our business model, one of my jobs is to make sure we are on top of where the NetFlow industry is going.  Although I have no crystal ball to forecast where I think Cisco is headed with the technology, I can speculate where the technology is going based on features I have already seen Cisco and other vendors deliver on.

First of all, what is NetFlow and what can it be used for? It was developed by Cisco Systems to provide a key set of services for IP applications, including:

  • Network traffic accounting and usage-based network billing
  • Network planning and security (e.g. Denial of Service monitoring)
  • Network monitoring and Reporting

What’s In a Flow?
When enabled, the router maintains a cache of the flows coming in on each of its interfaces.  In general, summary information about these flows are exported every 60 seconds.  The summary information includes but is not limited to:

  • Source and Destination IP Address
  • Source and Destination Port
  • Source and Destination Mask
  • Protocol
  • Next Hop
  • TCP Flags
  • Time Stamps
  • Delta Bytes
  • Delta Packets

The reason I say ‘Delta’ Bytes and Packets is because if the flow lasts several minutes, the delta (i.e. not the total) of packets and bytes since the last export is exported.  This is not the total since the start of the flow.  A single flow is one of up to 30 flows exported in a single NetFlow v5 datagram (24 flows in NetFlow v9). Imagine a router exporting 10 NetFlow packets per second.  This represents up to 1800 flows per minute and then some of the same flows are exported again in the following minute.  So, what causes a flow?

What Causes a Flow?
Lets say you bring up your web browser and surf to  This simple URL causes a flow(s). Then, you enter the search criteria (e.g. cute kittens) and the results come back displaying 10 links and a few images.  Then, you start clicking on the links and then backing up in your browser to hit the other links.  Since each URL you click on takes you to a page displaying images of several cute kittens, every page causes more flows.  Now you can appreciate why so many flows are created by a single person using a web browser and why routers export so many NetFlow datagrams.  Imagine a large college campus at 8PM at night.  I’ve seen single router export as many as 1000 NetFlow datagrams per second. Students do a lot of surfing, I mean studying.

NetFlow Reports

NetFlow analysis and reporting tools such as Scrutinizer collect NetFlow and provide valuable information about network users and applications, peak usage times, and traffic routing.

Option Templates
Option templates are what I would consider one of the hints on where Cisco is going with NetFlow.  When most people think about NetFlow, Top IP addresses, Applications, Conversations, etc. come to mind. This is because NetFlow v5 is the most popular version and it is limited to these types of reports.

Although not supported by most vendors, routers can export what is known as option templates.  These option templates include things such as flow counters, interface names, applications  and more.

Above is a NetFlow option template displaying interface names.  This can be used in lieu of SNMP.

What’s New From NetFlow
New from NetFlow is the ability to export details such as the MAC address of IP hosts, VLAN IDs or even syslog information (e.g. Cisco ASA).

Above is a example of a Flexible NetFlow export where MAC address and VLAN ID are included in the NetFlow template.  Syslogs can also be exported via NetFlow which has been made available on the Cisco ASA since the fall of 2009.

Flexible NetFlow is the Future
Flexible NetFlow is the latest version of NetFlow and is really a way to capitalize on the existing Netflow v9 architecture. Flexible NetFlow empowers administrators to export more details beyond the traditional NetFlow v5 limitations.  For example, NetFlow NBAR exports the actual application name (e.g. skype) rather than just the source and destination ports.  In short, NetFlow NBAR determines the applications by observing a series of packets, but it requires IOS v15.1.

Cisco also allows a full packet capture and export via NetFlow of all TCP or UDP packets however, it can overwhelm the CPU of the router and it can be difficult to turn off once the router is overwhelmed.  In my opinion, Cisco needs to implement a way via SNMP to turn it on and off as well as configure filters.  Sending all TCP or UDP datagrams is just to broad not to mention the additional overhead to the routers CPU and the network connections.

Latency via NetFlow is coming about as well where the RTT (round trip time to the client)  and the server latency (time to respond to a packet) are exported.  We are already seeing this in utilities such as nprobe.  The nprobe is also capable of exporting URL information, RTP and SIP details as well as several other interesting fields.  Scrutinizer a leader in NetFlow Analysis is one product that can be used to view this data.

Because the popularity of NetFlow is growing, customers want to save more and more data.  This means enabling NetFlow and sFlow on more and more routers and switches and potentially overwhelming the collector.  For this reason, Cisco developed sampling which is similar to sFlow.  With sFlow, entire packets are exported and there is no aggregation.  Sampling for consumers such as services providers and universities is the only option as no individual collector on the market can handle the NetFlow generation potential of Cisco’s latest switch technologies such as the Nexus 7000.

What’s Needed from NetFlow?
I think we need to see SNMP information exported by NetFlow as SNMP doesn’t scale as well as NetFlow nor is it as flexible.  I would also like to see more definable criteria so that I can export whatever I want through the use of scripts.  Who knows what Cisco has planned, do you have crystal ball?

Mike Patterson author pic


Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.


Big Data

Sankey Flow Graph

One of the greatest benefits of NetFlow collection for traffic analysis, is we’re provided with the ability to visualize the…

Leave a Reply