Previous Table of Contents Next


5.7 The SNMPv2 MIB

The April 1993 version of SNMPv2 (RFCs 1441–1452) provided three MIB documents. The first, RFC 1450, described a MIB module for SNMPv2 objects, which was identified by {snmpModules 1}. The second, RFC 1451, coordinated multiple management stations and was therefore called the Manager-to-Manager MIB, identified as {snmpModules 2}. The third module, RFC 1447, supported the SNMPv2 security protocols and was called the Party MIB {snmpModules 3}.

With the removal of the security-related aspects in the January 1996 version of SNMPv2 (RFCs 1901-1908), the MIB required revision as well. The fundamental structure is still the same, however (review Figure 5-1):

Branch OID RFC References

snmpV2 { 1.3.6.1.6 } 1442, 1902
snmpDomains Ӓ 1.3.6.1.6.1 } 1442, 1902, 1906
snmpProxys { 1.3.6.1.6.2 } 1442, 1902, 1906
snmpModules { 1.3.6.1.6.3 } 1442, 1902
snmpMIB { 1.3.6.1.6.3.1 } 1450, 1907
snmpM2M { 1.3.6.1.6.3.2 } 1451
partyMIB { 1.3.6.1.6.3.3 } 1447

Note that the last two branches (the Manager to Manager MIB and the Party MIB) are placeholders (with no currently defined objects) pending completion of the work in these areas. When that work is complete, it is possible that entirely new MIBs, having new OIDs, will be developed as replacements for snmpM2M and partyMIB. Make sure to consult the final RFC documents when these issues are settled.)

In view of the work that is incomplete at the time of this writing, this section focuses on the structure of the snmpMIB branch, from RFC 1907 [5-8]. The changes include:

  The inclusion of the system group from MIB-II; the addition of object resource information, which describes the SNMPv2 entity’s support for various MIB modules, is also added to the system group (see Figure 5-8a).


Figure 5-8a.  The system and snmp groups implemented for SNMPv2

  The inclusion of the snmp group from MIB-II, making obsolete a number of objects and adding two new ones: snmpSilentDrops { snmp 31 } and snmpProxyDrops { snmp 32 } (see Figure 5-8a).
  Changes to the snmpMIB group, making obsolete a number of objects and adding others (see Figure 5-8b). The objects within snmpMIB now fall into several categories: information for notifications and well-known traps; a set group, which allows managers to coordinate set operations; conformance information; and compliance statements.


Figure 5-8b.  The snmpMIB group for SNMPv2

Further details on these revisions are available in RFC 1907; use the other references in the table above as supplementary resources.

5.8 Coexistence of SNMPv1 and SNMPv2

The Coexistence document, RFC 1908 [5-9], presents a number of guidelines that outline the modifications necessary for successful coexistence of SNMPv1 and SNMPv2. Some of the issues noted in RFC 1908 deal with MIB structures, such as object definitions, trap definitions, compliance statements. and capabilities statements, that must be updated to conform to the specifications in SNMPv2.

From a practical point of view, two methods are defined to achieve coexistence: a proxy agent and a bilingual manager.

The proxy agent translates between SNMPv1 to/from SNMPv2 messages (see Figure 5-9). When translating from SNMPv2 to SNMPv1, GetRequest, GetNextRequest, or SetRequest PDUs from the manager are passed directly to the SNMPv1 agent. GetBulkRequest PDUs are translated into GetNextPDUs. For translating from SNMPv1 to SNMPv2, the GetResponse PDU is passed unaltered to the manager. An SNMPv1 Trap PDU is mapped to an SNMPv2-Trap PDU, with the two new variable bindings, sysUpTime.0 and snmpTrapOID.0, prepended to the variable bindings field.


Figure 5-9.  SNMPv1/SNMPv2 proxy agent operation

The second alternative is a bilingual manager, which incorporates both the SNMPv1 and SNMPv2 protocols. When the manager needs to communicate with an agent, it selects the protocol appropriate for the application.


Previous Table of Contents Next