If there’s one area that’s certain to get people confused when it comes to SNMP, it would have to be the understanding the purpose of a Management Information Base (MIB). The concept isn’t so difficult if you tear away most of the techno-jargon. Every SNMP managed device includes an MIB. Think of an MIB as a database that stores management information about a device. This database is made up of different manageable objects that have properties. For example, one standard MIB object is known as “sysName”. This object can hold a value – the name of the managed device. If an NMS were to query the device for its “sysName”, the value stored in that MIB object would be returned. Similarly, another standard MIB object called “sysUpTime” stores a value that outlines how long a device has been running since its last boot. The MIB stored within a managed device controls how it can be managed via SNMP.
RFC 1213 defines what is known as the standard MIB, which contains 171 manageable objects. All SNMP-manageable devices implement this MIB, which includes various objects capable of measuring and monitoring protocol activity, providing name and description information, and so forth. Furthermore, registered organizations like Cisco can also define their own private MIB extensions that provide additional management capabilities for their particular equipment. Cisco has defined hundreds of manageable objects within their private MIB.
MIBs are defined as part of a tree-like structure. Every MIB object is defined according to a name and associated object identifier (OID) number. The standard SNMP MIB, known as MIB-II, is identified by the OID 1.3.6.1.2.1. It can also be identified by its name – iso.org.dod.internet.mgmt.mib-2. Private organizations (like Cisco) are allocated a branch in the “private” portion of the tree. In particular, Cisco’s OID branch begins at 1.3.6.2.4.1.9. Beneath this portion of the MIB tree, Cisco can define its own private MIB objects, having said that, all objects privately defined by Cisco will start with the OID 1.3.6.2.4.1.9. Similarly, those defined by Microsoft will start with 1.3.6.2.4.1.311.
As mentioned earlier, an MIB is stored within a managed device. While this makes the device capable of being managed by SNMP, an NMS still needs to be configured to know about the particular MIB used by a device, since it probably includes private extensions. Think of it this way. Since vendors can create their own MIB extensions specific to their devices, there are literally thousands of possible MIB objects defined for different products, by different vendors. For an NMS to know about them all would first and foremost be almost impossible, and secondly, a huge waste of resources. To account for this, most NMS products support only the standard SNMP MIB by default. However, vendors usually supply MIB files with their products, and make then available by download from their websites. These MIB files can subsequently be compiled into an NMS, thus making it capable of managing the custom MIB settings of a particular device.
