Mr Tweaks - Back to homepage

Shop | How to | Reg Edit Tips | Got An Error? | Mac Tips | About Us | Products Page | Tips | Cable & ADSL | News & Events | Strange Tips | Contact Us | Links | Security


6. What is RMON?

RMON (Remote MONitoring) is an SNMP-based standard that allows management of network traffic.

If you'll recall, SNMP is the standard way of remotely managing devices. In a typical network, you have routers, hubs, switches, backup power supplies, servers, mail gateways, and so forth. In a modern network, all these devices can be remotely managed with a centralized console. The console sends SNMP commands to monitor their status, to reconfigure them, and receive alerts from them.

Of course, each of these devices accepts different commands and support different parameters that can be monitored. For a router, you might be concerned with the rate that packets are being forwarded. For a hub, you might want to monitor for any cabling faults on the ports. For backup power supply, you will want to monitor the voltage of the power being supplied. The collection of monitorable/changeable parameters are stored in a virtual database called a MIB (Management Information Base).

RMON is just another SNMP MIB. The item that this MIB manages is the traffic on the wire. In other words, we aren't talking about managing a real thing, but a virtual device.

6.1 What does "9-group RMON" refer to?

The original RMON standard specified 9 groups or sub-MIBs. A device could claim to support RMON if it supported only one of those groups. Many products have come out that support only the least resource intensive RMON groups. In order to differentiate themselves, full RMON products have taken to calling themselves "full 9-group RMON".

The 9 groups defined by the original RMON specification are:

This contains your basic Ethernet statistics. For the most part, these statistics are only relevant for promiscuous sniffing devices. In the old days when RMON was developed, most Ethernet consisted of a single coax wire. This group was essentially a MIB for the wire itself: it monitored the load on the wire (bytes/second, frames/second), health of the wire (CRC-errors/cable-faults), and simple traffic profiling.
The golden rule of the SNMP standard is that no MIB should contain any complexity that could otherwise be accomplished by a management console. The idea was that an SNMP should be a small addition to any device. This means that other SNMP MIBs do not contain history/trending/logging mechanisms because they can take up lots of memory in order to store all that data. Such activity can be better done by the console simply by polling the MIB on a regular basis, then storing the results on the console. RMON broke the mold because it was the only MIB designed for itself. In all other cases, SNMP MIBs were added to existing equipment. In the case of RMON, equipment was built expressly to host the RMON MIB. For this reason, RMON added resource intensive items to its MIB.

The "History" group is simply the "Statistics" group, but with the ability to keep track of the variables over time. One typical thing you might do is tell the RMON box to copy the Statistics group every hour and store the samples away.

These three groups are better discussed together. They all refer to the MAC addresses seen on the wire. Every Ethernet frame starts with a destination and source MAC address identifying to whom the frame was sent, and who sent it.

The Host group monitors the traffic that each MAC address sends/receives on the wire (bytes sent/received, frames sent/received). The HostTopN group serves as a sort of History mechanism to the Host MIB. Keeping a history of all the data would take too much memory, so instead it would allow you to do historical summaries of only the most active hosts. For example, every day you might store only the 10 most active hosts.

The Matrix MIB keeps a table of all the source/destination pairs. You can think of this in a number of ways. For any host, you can identify who that host is talking to. Likewise, you can identify who is talking to that host. This MIB is extremely resource intensive.

Note that in this discussion, the word "host" means essentially "MAC address". In a normal routed TCP/IP environment, this means that you will generally see that everyone is talking to the router. Later versions of RMON extended the host concept to the IP address layer; described below.

These two groups provide the capabilities necessary to remotely sniff traffic from the wire.

The Filter group allows you to specify filters. The most common use for this is when you want to sniff a single host's traffic, or if you are sniffing for a certain protocol. The Capture group is where the sniffed traffic is placed. The management console tells the capture group to create a buffer, then turns on sniffing, then downloads the frames to the console for decoding.

An Alarm could be triggered according to other values in the MIB. For example, you could tell it to alarm whenever traffic exceeded a certain threshold. Once an alarm triggered, either a Trap could be sent to the console, or the alarm could be logged in the Event group for later retrieval.

Alarming within RMON was extraordinarily sophisticated. For example, you could set a Filter to scan for a certain pattern within network traffic and trigger an Alarm.

6.2 What kinds of products support RMON?

Originally, RMON was conceived as a remote sniffer. The idea was to create a stand-alone box (called a "probe") that you would attach to an Ethernet segment. While you can still purchase such probes, you are more likely to experience RMON as an add-on product to hubs, switches, and routers.

6.3 What is RMONv2?

Version 2 of RMON extended the traffic-management capabilities up the protocol stack. For example, the Host/HostTopN/Matrix groups were extended to the OSI Network Layer (i.e. IP) and the OSI Application Layer. This required the ability to track the Network and Application Layer protocols as well.

6.4 What is the difference between RMON and SNMP?

This question comes up rather often. The difference should be rather obvious - RMON is just one of the 100 standard MIBs defined by the IETF, and management consoles use SNMP to talk to the MIB.

However, the source of this confusion is that RMON wasn't your average MIB. It broke the mold of how people viewed SNMP. Before RMON, SNMP was designed to be a simple/lightweight protocol. The idea was that you would add this tiny little SNMP agent to all your networking equipment, and that this agent would have minimal impact on the equipment. RMON introduced new ways of thinking where the agent could be much more resource intensive. This came from the fact that RMON wasn't added to existing equipment, but instead existing equipment was designed to run RMON.

Over time, people found many of the RMON concepts useful. They extended into later MIBs and versions of SNMP. At the same time, people imbedded RMON into existing equipment like hobs, switches, and routers. In fact, the original coax Ethernet that RMON was designed for doesn't exist today; yet RMON is still a thriving/evolving standard.

6.5 Does RMON function as a remote sniffer?

In a pinch, RMON can be used to remotely sniff traffic. The problem is that it isn't very good at it. For example, with today's sniffing products, you can easily do a packet capture of all traffic and save it real time to gigabyte disk drives. If you try to do that with RMON, you'll find difficulties in trying to transfer all that data back to your management console. One way to reduce this data is to set packet capture filters. However, filtering is extremely weak in RMON. If you want to do sniffing, don't rely upon RMON to do it for you.

On the flip side, there is a big security concern that RMON is so pervasive on equipment throughout the Internet that you can often find open RMON probes that will allow remote sniffing. Again, it won't provide very good sniffing capabilities, but it will be good enough.

6.6 What are the limitations of RMON?

First of all, RMON suffers from the basic problems of SNMP. SNMP has always been a "checkbox" item that customers always want in their products, but which vendors don't spend a lot of time on. Thus, basic activities work within SNMP, but it never quite reaches the hype. Likewise, while there are a ton of products out there that support RMON, they don't always work correctly. Indeed, since RMON is so resource intensive, you will often find that heavy use of RMON crashes the remote device.

Second of all, RMON is extremely resource intensive. In RMONv2, the network-layer matrix table can quickly fill up after a few moments attached to the network.

A. More info

Here are some useful references:
Douglas E. Comer's NETBOOK
A good introduction to protocols, a book that is available on the web.
Laura Chappell's Introduction to Network Analysis
Mark Miller's publications
Especially the "LAN Protocol Handbook".

X. Glossary

Berkeley Packet Filter (BPF)
BPF (Berkeley Packet Filter)
A generic system, originally for BSD-based UNIX, that provides network packet capture capabilities. See also DLPI, NIT.
Data Link Provider Interface (DLPI)
DLPI (Data Link Provider Interface)
A built-in subsystem within Solaris (and other System V UNIX systems) for packet capture. See also See also BPF, NIT.
Network Interface Tap (NIT)
NIT (Network Interface Tap)
The system for SunOS 4 that allows monitoring of packets on the wire. Replaced by DLPI on Solaris/SuOS 5.
See packet

Click Here!