Request a quotation from the Info-Stor team

+44 (0)204 592 0995

Email us

Close form
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

NetFlow in more detail

11th March 2019

In the last blog I looked at some of the basics of how data gets from one network device to another by using the 7-layer OSI model.

In this blog I am going to talk in more detail about NetFlow and in the next blog I will discuss a major alternative called sFlow and what the differences are.

CISCO’s NetFlow is designed to record and export 100% of all the IP conversations (Layers 3 and 4) on each network interface that it is configured on and NetFlow is the best way to get as complete a picture as possible of the TCP/IP traffic on your network.

The NetFlow calculations are performed on the incoming network interface. So, for accurate reporting of the outbound interface, NetFlow should be enabled on all interfaces of a network device.

NetFlow is stateful in that it maintains data about each session and so captures the statistical information associated with each IP conversation.

NetFlow looks for 7 key criteria on each packet of information to determine if it belongs to the same conversation on the network:

  • IP source address
  • IP destination address
  • Source port
  • Destination port
  • Layer 3 protocol type
  • Class of Service
  • Router or switch interface

If all 7 criteria match a previous packet, NetFlow assigns that packet to the same flow or conversation.

As such NetFlow creates a logical stream or flow of packets from a sending application to a receiving application.

NetFlow caches this statistical data locally on the device. When the cache fills up or when the conversation ends or after certain time periods, it is exported to the NetFlow collector where it is analysed by advanced software such as Plixer Scrutinizer.

NetFlow technology was originally developed in the late 1990’s and was proprietary to CISCO devices and runs in CISCO IOS software.

A concern I have heard expressed is that in busy networks with older CISCO devices and older versions of NetFlow, turning on NetFlow monitoring and exporting can seriously impact those devices. And in fact CISCO do say that in such circumstances that NetFlow can consume as much as 15%- 20% of CPU.

However modern higher end CISCO devices (and other manufacturers who support NetFlow) perform NetFlow in hardware which removes these additional CPU loads. However, you need to check exactly which devices this applies to.

According to Plixer who make the market leading NetFlow collector software Scrutinzer, with modern switches and routers and in situations where the load is moderate switching on NetFlow is not overly burdensome and “In general, most customers see only a very slight CPU increase (ie 2-3%) on routers when NetFlow is enabled”.

Even if performance is a concern then one answer is to use a NetFlow generator or software probe which can span a port on a switch or router and take the load off the device entirely.

There is a lot more detail about this on this blog article on the Info Stor web site

My advice would be that before you turn on NetFlow on any of your devices you give us here at Info Stor a call as our experienced team will be very happy to advise you.

Under the right conditions NetFlow can be an efficient and scalable technology that can potentially work on hundreds of NetFlow enabled network devices to a central NetFlow collector or distributed NetFlow collectors. The other big advantage is that NetFlow will capture the entire IP application conversation giving a forensic level of completeness. For IT security purposes this is highly desirable.

The downsides are that NetFlow will only work with IP traffic (layer 3 and 4), though very often in modern networks that makes up a considerable amount of what you will be looking at anyway. Not every manufacturer supports NetFlow and for those that don’t or where performance is a concern an additional NetFlow generator or software probe may need to be used as an extra cost option. Finally, NetFlow data can generate a very considerable amount of data that may need to be stored for extended periods.

In very high volume, very high-speed LAN switching environments the use of sampling may be more appropriate. The latest versions of NetFlow support Sampled NetFlow which will only look at one in every 10/100/1000 packets or whatever you set the interval to be.

As I have mentioned before Plixer Scrutinizer is a great choice for a NetFlow collector.  I would recommend that you give us a call here at Info Stor. Our friendly team will answer all your questions and help you with a no obligation 30-day trial.

Read more in my series of blogs:

1. Help! Why has my Cisco network gone slow again?

2. What’s in an OSI layer? Your data!

4. sFlow in more detail

Let's talk

Tell us what you want to achieve and we’ll get in touch…

Free Consultation!