Now in its third version (RFC 2819 is the latest), RMON was developed to allow network management stats to be gathered from remote sites and equipment, without incurring the overhead of SNMP constantly polling across the WAN. RMON monitors - typically probes, though you can get some limited RMON information from some switches - gather the information and pass it back to management stations. They can also store it should the link be unavailable, so you don't lose information. And because it's a standard, you should be able to use RMON-compliant probes that don't necessarily come from the same vendor as the management platform.
The RMON MIB standard defines data source objects which point to MIB-II interfaces, identified by instances of ifIndex objects. There are nine groups (ten if you count the Token Ring-specific one that was added as an RFC extension) that cover the areas that can be monitored on your network devices by probes. Any RMON management platform should be able to then interrogate the probes to retrieve this information and display it in a graphical report format. If they all support the same standard, you can choose the management and reporting platform that gives you the best front-end to this information, or that fits into your existing systems management portfolio.
Statistics - per interface stats on utilisation figures
History - periodic statistical samples that can be retrieved later (in the standard there is actually a separate group listed that controls this setup, but it's not normally referred to)
Alarms - raised if values exceed previously configured thresholds
Hosts - per host stats. The host MAC addresses are discovered by looking at source/destination fields within the frames
Host TopN - top talkers on the network
Traffic Matrix - conversations between hosts
Filters - configuration option for capturing data or generating events
Packet Capture - the ability to capture MAC frames for further investigation and decode
Events - this group controls the generation and notification of messages, linked to the alarms group.
The problem with RMON was that it only dealt with MAC-layer information. The trouble was that as soon as you wanted to start looking at traffic going outwith its LAN segment, all you could get was lots of traffic going to and from the local router. So RMON 2 (RFC 2021) extended the concept to look at information from the network layer and above.
The groups that RMON 2 adds over and above the initial RMON are:
Protocol directory - the list of network protocols that can be distinguished. You should be able to add to this by configuring your own protocols by port number
Protocol distribution - per protocol stats
Address mapping - MAC to network layer address (typically IP nowadays, but could also be IPX addresses etc)
Network layer host - per host stats
Network layer matrix - conversations
Application layer host - per hosts stats
Application layer matrix - conversations
User history - user-definable history collection
Probe configuration - information on the RMON probe itself
The next problem that RMON faced was how to handle switched networks. A probe on a shared LAN has no problems seeing everything that's going on if it has a promiscuous NIC. A switched environment changes all that, so RMON analysis for switched networks (SMON) was defined. The SMON MIB (RFC 2613) extends RMON to allow for other types of objects to be defined as data sources for the data.
SMON capabilities include:
smonVlanStats - 802.1Q stats
smonPrioStats - traffic distribution based on the priority field in the VLAN header
dataSource - one of three sources: port-based (the traditional RMON source); VLAN-based; or a separate physical entity
portCopy - the ability to copy data from one switch port or ports to another port(s).
High Capacity networks
The last development we've seen to date is a new RFC (3273) that's designed to help RMON better cope with the massive amounts of information that can be generated in today's high speed networks. Apart from adding one new, media independent group, this RFC just adds to existing groups already specified within RMON/RMON 2, but with greater allowance for higher capacities.
RMON has come a long way since 1991. With the amount of information you can get, it's an essential management and troubleshooting tool, especially with the ability to import RMON data into your existing RMON-compliant management platforms. But if you're looking at the capabilities of RMON probes, best check out which of all the above standards they support to make sure you're not missing out on anything useful.