In its pure form RMon is limited to monitoring and diagnosing network traffic at the Media Access Control (MAC) layer. Tasks such as identifying network hosts and sources beyond the router connection remain out of reach.
Not prepared to sit still though, the industry is currently finalising development of RMon2, a standard designed to provide network managers with full seven-layer network visibility and analysis capabilities. The RMon2 standard is yet to be fully ratified by the IETF, but already a number of vendors are offering products with RMon2 features.
There are two basic components to any RMon implementation: a probe and a monitor. The probe may be built in to existing hardware, or be a stand-alone unit attached to the network. The actual placement of the RMon probe is irrelevant, provided there is one RMon agent on each physical segment of the LAN. The monitor is a Unix or PC workstation to which RMon statistics are reported.
There are nine major monitoring groups specified by the RMon Management Information Base, the first four of which have been available via standard network reporting for some time. These are:
STATISTICS - standard IP readings on LAN performance and errors.
HISTORY - trend analysis through intermittent sampling.
HOST - MAC address statistics.
ALARMS - setting network activity levels.
Beyond these four are:
TOP N - recording the top talkers on the network MAC address statistics.
MATRIX - determining the traffic pattern.
EVENTS - triggering actions when a threshold is exceeded.
FILTER - defining the scope of monitoring packet-selectionPACKET CAPTURE - collecting and uploading raw network data.
A tenth group, TOKEN RING, has also been developed to handle issues specifically related to that protocol.
In order for a vendor to say its equipment is RMon enabled it need only support one of the nine groups. It is common for much hardware to have supported the first four groups in a proprietary manner prior to the RMon standard.
There are currently two methods of installing RMon, depending on the nature of the network equipment in place. Much hardware currently sold includes embedded RMon probes, although commonly not much of this is being used. In such a scenario RMon components may be activated later and RMon activities conducted. However, there is often a drain on equipment performance that goes along with the extra processing power required to perform RMon. Older network hardware-based embedded RMon probes are often limited to the basic first four groups.
For older networks, or for networks where it is not practical to activate the embedded RMon probes, stand-alone probes may be attached to the network to do the monitoring. Stand-alone probes have the advantage of not affecting hardware performance, but may prove to be expensive.