Networks tend to evolve over time. Over the past 5 – 7 years, I have seen VoIP and video push many network administrators to think beyond utilization and latency.  Prioritization is an important part of the mix today.  Although trying to absolutely guarantee QoS with Network traffic is impossible, it is possible to prioritize critical data and increase delivery time probabilities.

To minimize latency risks, enterprise networks require reporting tools that can compare interfaces and allow management to view the before and after impact of configuration changes.  Capacity planning almost always requires good reports that detail application usage, QoS, CoS or DSCP values, flow volumes, top talkers and the like.

As you are already aware, using a best at NetFlow reporting solution allows you to report on network traffic in a plethora of different ways.   Details on ToS, DSCP or QoS is a frequently sought after report.  And after carefully reviewing the current prioritized traffic over your DiffServ domain, you may see patterns that raise your eyebrows.

Loaded with new network traffic insight, you could start to think about implementing QoS policies a bit differently.  Below is an example of a 1 month ToS report on a selected interface:


Before making any changes, it is best to confirm your assumptions by analyzing traffic behaviors on other links using the same format.  Below is a similar report on a different downstream interface using the same time/date and report criteria.  Compare the differences:


It is even a good idea to compare reports between last month vs. this month.  Also, notice above that after looking at the two reports, it becomes clear that there could be some miss configured DSCP policies on the different routers.   Differences like the ones above can have a severe adverse impact on business applications.  I think this helps demonstrate that NetFlow collection and analysis are crucial in today’s network.

A good NetFlow reporting tool like Scrutinizer allows for the ability to creatively twist data in different ways so that we can study how traffic patterns can impact network performance. For Example:

  • Flow Volume: amount of flows to and from a host or network
  • Host Volume: amount of unique hosts communicating on a link or with a specific host
  • NBAR: provides actual application information beyond TCP port 80 ‘HTTP’.  NBAR tells us it is actually (e.g. displays ‘skype’ in lieu of ‘HTTP’) and the hosts involved
  • Subnet to Subnet: this report helps with MPLS reporting to see which sites are hitting a particular location the most
  • Pair Volume: amount of unique address pairs on a link in a given time frame
  • Protocols: to help diagnose if there is traffic on the network beyond TCP, UDP and ICMP
  • ToS: as shown above
  • Traffic Volume: to show overall total utilization.  This is similar to SNMP trending tools like Denika.
  • Raw Flows: when you are really getting into the minutia and need to see the raw data before the NetFlow Analyzer formatted the data.
  • Access to the raw flows is a must.
  • And a whole host of other reports

Most of us agree that NetFlow is the way to go with today’s switch and router technology.  I feel that NetFlow or sFlow support should be on the list of mandatory features in the next switch or router purchase.  Why? Because flow data provides the most insight when placing packet analyzers all over the network isn’t feasible.

Loaded with the above, it becomes much easier to confirm the impact of policy modifications on routers and switches.   Business applications can more easily be guaranteed priority delivery and upper management can provide definitive answers to questions like “why is it so slow”.

Download our free version and if you like what you see keep it.  If you want even more, try Flow Analytics.


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