Remote Monitoring

Remote Monitoring (RMON) is an extension to the MIB address space and was developed to allow monitoring and maintenance of remote LANs. Unlike SNMP, which provides information retrieved from a single computer, RMON captures data directly from the network media and therefore can provide insight on the LAN as a whole.

The RMON MIB begins at address location .1.3.6.1.2.1.16 (as shown in Figure 21.3) and is currently divided into 20 groups, for example .1.3.6.1.2.1.16.1 through .1.3.6.1.2.1.16.20. RMON was developed by the IETF to address shortcomings with SNMP and to provide greater visibility of network traffic on remote LANs.

There are two versions of RMON: RMON 1 and RMON 2.

• RMON 1— RMON 1 is oriented toward monitoring ethernet and token ring LANs. All groups within RMON 1 are concerned with monitoring the bottom two layers, for example the Physical and Data Link layers of the OSI reference model (corresponding to the Network Access layer in the TCP/IP model). RMON 1 is described in RFC 1757, which updates RFC 1271, which was published in November 1991.

• RMON 2— RMON 2 provides the functionality of RMON 1 and also lets you monitor the upper five layers of the OSI reference model (corresponding to the Internet, Transport, and Application layers of the TCP/IP model). The specifications for RMON 2 are contained in RFCs 2021 and 2034, which were released in 1997.

Because RMON 2 listens to higher layers of the protocol stack, it can provide information on higher-level protocols, such as IP, TCP, and NFS.

The purpose of RMON is to capture network traffic data. An RMON agent (or probe) listens on a network segment and forwards traffic data to an RMON console. If the network includes several segments, a different agent listens on each segment. RMON information is gathered in groups of statistics that correlate to different kinds of information. The RMON 1 group names are as follows:

• Statistics— The Statistics group holds statistical information in the form of a table for each network segment attached to the probe. Some of the counters within this group keep track of the number of packets, the number of broadcasts, the number of collisions, the number of undersize and oversize datagrams, and so on.

• History— The History group holds statistical information that is periodically compiled and stored for later retrieval.

• Alarm— The Alarm group works in conjunction with the Event group (described later). Periodically the Alarm group examines statistical samples from variables within the probe and compares them with configured thresholds; if these thresholds are exceeded, an event is generated that can be used to notify the network manager.

• Hosts— The Hosts group maintains statistics for each host on the network segment; it learns about these hosts by examining the source and destination physical addresses within datagrams.

• Host top n— The Host Top n group is used to generate reports based on statistics for the top defined number of hosts in a particular category. For instance, a network manager might want to know which hosts appear in the most datagrams, or which hosts are sending the most oversized or undersized datagrams.

• Matrix— The Matrix group constructs a table that includes the source and destination physical address pairs for every datagram monitored on the network. These address pairs define conversations between two addresses.

• Filter— The Filter group allows the generation of a binary pattern that can be used to match, or filter, datagrams from the network.

• Capture— The Capture group allows datagrams selected by the Filter group to be captured for later retrieval and examination by the network manager.

• Event— The Event group works in conjunction with the Alarm group to generate events that notify the network manager when a threshold of a monitored object has been exceeded.

• Token Ring— The Token Ring group maintains collected information that is specific to token ring.

RMON 2 provides additional groups related to its oversight of the upper-level protocols.