RMON (4 groups)

Diagram highlighting 4 RMON groups supported by most switch vendors

If you look carefully at the data sheets for almost any managed switch you are likely to see RMON mentioned as a network management feature with one of the following qualifiers: mini-RMON, RMON (4 groups), RMON (groups 1,2,3 and 9) or RMON (statistics, history, alarm and event). The RMON feature is almost never used, it's a bit like the human appendix, a remnant left behind by evolution.

The RMON standard was developed by the IETF during the early 1990's to provide an SNMP interface to probes used for remotely monitoring Ethernet and Token Ring LANs. At the time, LANs consisted of coax cables that where shared by a number of hosts. Repeaters were used to connect the the cables and extend the network. In this environment, a single RMON probe would see all the traffic on the shared network, providing complete network visibility.

In the mid 1990's demand for bandwidth increased and switches started to become popular. However, while segmenting the network using switches helped improve performance, segmentation dramatically increased the number of probes needed to monitor the network since a probe was required for each segment. Many customers depended on the visibility that RMON probes provided and switch vendors felt pressure to provide embedded RMON functionality.

The RMON standard defines 20 different types (groups) of measurement, including: traffic matrices, top talkers, top protocols, trending etc. Implementing all these features on a switch is difficult, requiring a significant area on the switch ASIC, resources that the switch vendors wanted to allocate to more advanced switching features like QoS, rate limiting, VLANs etc.

Four RMON groups were identified that were easy to implement, requiring minimal ASIC resources. Since the RMON standard allowed a vendor to claim RMON compliance by implementing any of the RMON groups, many switch vendors decided to implement the four RMON groups in order to be able to market their products as supporting the RMON standard. The proliferation of devices, many with very limited capabilities, all claiming RMON compliance undermined the value of the RMON standard and it has fallen out of favor as a network monitoring technology.

Today, even though hardly anyone uses the four RMON groups they are now part of the design of most switch ASICs and leaving the feature in is easier than going to the trouble of redesigning the chip to remove it.

In 2001, the sFlow standard was developed to address the need to monitor network traffic in switched LAN environments. The sFlow standard describes a minimum set of functions (packet sampling and counter polling) that are easily implemented in a switch ASIC. Requiring that all sFlow compliant switches implement these features, ensures that every sFlow compliant switch delivers the full range of features needed for network visibility.

Diagram highlighting RMON functional areas addressed by sFlow

The sFlow monitoring architecture provides the full range of traffic monitoring functions by shifting complexity from the switches to a central sFlow analyzer (see Choosing an sFlow analyzer). The architecture has proven successful and today most switch vendors embed sFlow monitoring.

Probes

The RMON (Remote MONitoring) standard was developed in the early 1990's to standardize network monitoring devices (usually referred to as "probes"). At the time, Ethernet LANs consisted of coax cables that where shared by a number of hosts. Repeaters were used to connect the the cables and extend the network. In this environment, a single RMON probe would see all the traffic on the shared network, providing complete network visibility.

Multi-port switches started to become popular in the mid 1990's and SPAN/mirror ports were added to switches to continue to allow probe-based monitoring. The increasing number of ports per switch and the increasing port speeds has made the use of probes a challenge. The need for embedded instrumentation was becoming clear.

In the late 1990's, Cisco introduced the NetFlow protocol, embedding L3-4 monitoring in routers and in 2001 the sFlow protocol was introduced, embedding L2-7 monitoring in switches. Interest in network visibility has accelerated the adoption of the sFlow standard among switch vendors, further limiting the role of probes.

The chart clearly shows the trend toward embedded monitoring. Google Insight for Search was used to trend the popularity of the search terms sFlow, NetFlow, RMON and Probe compared to overall searches relating to Network Monitoring & Management. The sFlow and NetFlow lines track closely and exceed general interest in Network Monitoring & Management, indicating that they are increasingly important topics. The RMON and Probe lines track closely with each other and show a rapid decline compared to Network Monitoring & Management, indicating declining interest in probes as monitoring shifts from probes to embedded instrumentation.

Current trends toward data center convergence increase the need for visibility and control. Complete network visibility is likely to involve both NetFlow and sFlow. NetFlow provides visibility into routers while sFlow extends visibility into the increasingly important switching layer, including: virtual servers, blade servers and edge switches.

Note: The overall downward trend in all the lines results from the increasing population of Internet users. As more people use the Internet, the proportion of Internet users interested in any one topic is diluted. This is particularly true of technical topics. In the past, the technical barriers to using the Internet skewed the user population and resulted in more searches relating to technical topics. Now that everyone is online, the majority of searches relate to more populist topics.