Bandwidth monitoring hasn’t been as big a concern for as long as some of us might think. Ethernet was founded in 1973 by Bob Metcalfe and David Boggs.


(Ron Crane is the founder of LAN Media)

However, the first RFC for Ethernet “RFC 826” didn’t show up until November of 1982. Six years later, the first SNMP request for comment was shows up “RFC 1067” which was published in August of 1988. I guess it took the industry a few years to run into bandwidth issues? I’m sure network traffic monitoring wasn’t the only problem needing to be addressed by SNMP.

I started working at Cabletron Systems in 1992 and SNMP was already a big part of their marketing efforts. It was obvious to me that network traffic analysis was a growing concern.

RMON (Remote Monitoring) was introduced a short time later but, it never seemed to take off. Certainly it was a big part of the Cabletron sales pitch but, it wasn’t implemented for several reasons:
* CPU intensive on the switches (done in hardware later)
* few switch vendors supported it

Today more switch vendors support RMON but, because of the introduction of NetFlow and sFlow analysis tools (in early 2000) RMON never really entered the limelight. RMON is a polling technology where as NetFlow and sFlow push the data to the NetFlow collector.

Anyway, SNMP in and of itself is awesome. Take this graph for example, I can tell how much bandwidth is being used with a high degree of accuracy.


The above is very useful as it can tell us when we need to buy more bandwidth however, what if current bandwidth is being abused?  SNMP (ignoring RMON) isn’t very useful for figuring out what end system is using the bandwidth.  NetFlow or sFlow reporting delivers details that allow us to determine exactly who is causing the problem. It is much like a packet analyzer but, with much less data to deal with.


Click to expand the above and notice that the inbound traffic is on top and the outbound traffic is on the bottom. The pagination at the bottom of the tables allows me to navigate to all flows during the selected time frame.

Look at some of the reports you can get from NetFlow:

You might think “Wow, why would anyone want to limit themselves to SNMP?”. Well, SNMP is not limited to interface utilization trends, it can also be used to collect information on the routers CPU.


It can be used to collect errors, per interface, CBQoS information including information available on IP SLA such as Jitter, MOS and latency.


SNMP and NetFlow
As most of you already know, we’ll all be using SNMP, NetFlow and sFlow for the foreseeable future. As Flexible NetFlow matures, expect it to assume more and more of the responsibilities currently addressed with SNMP but, I doubt it will replace it completely in the next 5-10 years. There are a lot of networks out there.

The Future of NetFlow

Best at NetFlow Analysis tools are already reporting on NetFlow data such as that from the Cisco ASA which reports on syslog type information as well as network bandwidth utilization.

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