9 limitations to be aware of when considering Netflow for visibility

The amount of Netflow data crossing enterprise networks is significant. Its purpose is to provide network visibility in areas of interest.  Netflow is generally free and available in some form on most network equipment, and therein lies the temptation.  While it can provide some high level usage stats on links and ports, it falls short in providing the visibility that network managers need today.  There are many commercial and open source tools that ingest Netflow to help you visualise the results.  


netflow visibility

If you’re ever considering netflow for visibility, here are 8 things you should keep in mind:

  1. 3rd Party servers & software:  To collect all the raw Netflow stats from network equipment you will need software that collects, analyses, stores & presents the stats. Tools like PRTG, ManageEngine, Solarwinds etc will need to be installed on servers and network equipment will need to be configured to generate and send Netflow to these servers.  More software, more servers and more router/switch configs to maintain.
  2. Time granularity: Netflow typically has 5 minute granularity.  This means you have to wait 5 minutes before you can see what traffic was on the network.  By that time, the problem has disappeared and the next one is in play.  Some equipment can be configured to produce Netflow every 1 minute but you’re still too far behind. 
  3. Application granularity: Most Netflow sources are port based.  So apps like instagram or Facebook will be reported as port 80/HTTP and apps like bittorrent and Skype will be reported as random port numbers.  Cisco equipment has NBAR and NBAR2 that help with classification but provide a fairly basic application library. Other attributes like URLs, application subtypes like Facebook chat, BYOD types etc. are not available from Netflow.
  4. Pervasiveness: Running a network with distributed applications and offices and private/public cloud infrastructure, means that to know what’s going on you need to be able to see across the whole environment - physical, virtual, cloud, SDN. While Netflow may be available in some equipment, it’s not as pervasive across the cloud.  
  5. Inconsistent data sources: Not all Netflow sources are the same.  Old routers have different formats and granularity to new ones. This inconsistency in versions, granularity and depth make network wide visibility clunky and complex.
  6. Load on network & equipment: No point trying to see what’s going on when you’re flooding the WAN with visibility stats.  This is very common with Netflow.  The more traffic the more the load on the network. There are servers and software that attempt to reduce this load by processing and compressing locally which adds another whole layer of complexity to network visibility.  Netflow can be sampled to reduce some load but you give up depth and granularity of reporting.  Routers
  7. Scale: Netflow may be OK for monitoring a particular router to solve a specific issue but it becomes incredibly complex to deploy, maintain and most importantly provide a clear view of what’s on the network.  The effort and complexity involved in Netflow based solutions far outweigh the visibility benefits it can provide.
  8. Speed: The granularity of Netflow is already a big obstacle when it comes to troubleshooting speed.  The network manager needs to know what’s going on now, not a minute later.  Historical queries in Netflow collector solutions are so slow and cumbersome that over time users drop using them.
  9. Time & Cost: Time to deploy, resources to manage and cost associated with missing vital bits of data due to lack of depth, breadth and scale are important considerations. 


While its good practice to use existing infrastructure to get better visibility and solve problems, a Netflow solution introduces a new layer of complexity which increases TCO and ultimately doesn’t provide the agile and deep and network wide visibility the business needs.  Network managers end up spending resources on getting visibility to work as opposed to running a great network.  Solving application performance issues on large or small networks is becoming increasingly difficult and Netflow is struggling to keep up in this challenge.