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.

The 9 groups defined by the original RMON specification are:

Statistics

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.

History

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.

Host/HostTopN/Matrix

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.

Filter/Capture

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.

Alarm/Event

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.

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.

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.

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.

Douglas E. Comer's NETBOOK

A good introduction to protocols, a book that is available on the web. http://www.netbook.cs.purdue.edu/index.htm

Laura Chappell's Introduction to Network Analysis

http://www.podbooks.com/

Mark Miller's publications

Especially the "LAN Protocol Handbook". http://www.diginet.com/publications.html