Previous | Table of Contents | Next |
The original RMON MIBs for Ethernet and token ring networks are primarily concerned with the operation and management of the Physical and Data Link Layers of a remote network. As such, they can compile statistics and historical information regarding Ethernet collisions, token ring frame copied errors, and so on, but they cannot look into the operation of the OSI Network through Application layers of that remote network.
RMON2, defined in RFC 2021 [3-26], extends the RMON capabilities to those higher layers by adding 10 new groups, designated {rmon 11} through {rmon 20}. Figure 3-21 illustrates the OID branches for both RMON and RMON2. Thus, the higher layer protocols, such as TCP/IP or SPX/IPX, can be monitored for greater management visibility within the internetwork. The ten groups within RMON2 are:
Group | Description |
---|---|
protocolDir (11) | Protocol Directory: lists, in a table, the inventory of protocols that the probe has the capability of monitoring. Each protocol is described by an entry in the table. |
ProtocolDist (12) | Protocol Distribution: collects the relative amounts of octets and packets for the different protocols that are detected on a network segment. Each protocol is described by an entry in a table, and the network management station can easily determine the bandwidth consumed per protocol by accessing the information in that table. |
addressMap (13) | Address Map: correlates Network Layer addresses and MAC Layer addresses, and stores the information in tables. |
nlHost (14) | Network Layer Host: counts the amount of traffic sent from and to each Network Layer address discovered by the probe, and stores the information in tables. |
nlMatrix (15) | Network Layer Matrix: counts the amount of traffic sent between each pair of network addresses discovered by the probe, and stores the information in tables from both source to destination and destination to source. |
alHost (16) | Application Layer Host: counts the amount of traffic, by protocol and by host, that is sent from and to each network address discovered by the probe. |
alMatrix (17) | Application Layer Matrix: counts the amount of traffic, by protocol, sent between each pair of network addresses discovered by the probe, and stores this information in tables. This group is similar to the nlMatrix group, but the focus is on the protocol in operation. |
usrHistory (18) | Combines mechanisms seen in the alarm (3) and history (2) groups to provide user-specified history collection, and storing that information in tables. |
probeConfig (19) | Controls the configuration of various operational parameters by the probe, such as the Ethernet and token ring RMON groups that are supported by the probe, software and hardware revision numbers of the probe, a trap destination table, and so on. |
rmonConformance (20) | Describes the requirements for conformance to the RMON2 MIB. |
Figure 3-21. RMON1 and RMON2 object trees.
Figures 3-22a, 3-22b, and 3-22c show the various RMON2 groups and objects. Reference [3-27] provides a good overview of the technology.
Figure 3-22a. RMON2 OID tree
Figure 3-22b. RMON2 OID tree, continued
Figure 3-22c. RMON2 OID tree, continued
Many vendors have developed private MIBs that support hubs, terminal servers, and other networking systems. You can find these MIBs under the enterprises subtree, {1.3.6.1.4.1.A}. The A indicates a private enterprise code, defined in the Assigned Numbers RFC (currently RFC 1700) in the network management section. (Appendix F lists these enterprise numbers.)
Information on these private MIBs is available via anonymous FTP from host venera.isi.edu, directory /mib. One interesting file is snmp-vendors-contacts, which lists the currently assigned private enterprise codes. Many vendors also place their private MIBs in this subdirectory. Because of these private MIBs are vendor-specific, interoperability is not always possible.
Previous | Table of Contents | Next |