|
|
Management Information Bases (MIBs) are a collection of objects or definitions that define the properties of the managed objects.
To enable the SNMP manager or management application to operate intelligently on the data available on the managed device, the manager needs to know the names and types of objects in the device. This is made possible by the MIB modules, which are specified in the MIB files usually provided with managed devices.
It should be understood that MIB is only an abstraction of data and not a physical database or a physically executable object.
The following sections are dealt with in detail in this topic:
IAB recommended a two-pronged strategy for the development of Internet network management standards. The SNMP was used in the short run and the use of OSI network management framework was examined in the long run. On this basis, two documents were created, which defined the SMI and MIB. The documents were framed to be compatible with both the SNMP and OSI network management framework. In the short run, this strategy proved successful.
However, the report of the Second Ad Hoc Network Management Review Group stated that the SNMP and OSI framework did not fulfill the exact requirements. Therefore, both were suspended which in due course led to the drafting of MIB II.
MIB-I was the first version issued as RFC1156. MIB-II is a super set of MIB-I with some additional objects and groups and is defined in RFC1213.
The SNMP manager or the management application uses a well-defined naming syntax to specify the variables to the SNMP agent. Object names in this syntax are called Object Identifiers (Object IDs or OIDs). OIDs are series of numbers that uniquely identify an object to an SNMP agent.
OIDs are arranged in a hierarchical, inverted tree structure. The OID tree begins with the root and expands into branches. Each point in the OID tree is called a node and each node will have one or more branches, or will terminate with a leaf node. The format of OID is a sequence of numbers with dots in between. There are two roots for Object Identifiers, namely iso and ccit. iso starts with .1 and ccit starts with .0. Most Object Identifiers start with .1.3.6.1, where 1=iso, 3=org, 6= dod, 1 = internet. The internet subtree branches into mgmt and private.
To understand the concept of relative and absolute Object Identifiers, let us consider the zoho Object Identifier .1.3.6.1.4.1.2162. It specifies the path from the root of the tree. The root does not have a name or a number but the initial 1 in this OID is directly below root. This is called an absolute OID. However, a path to the variable may be specified relative to some node in the OID tree. For example, 2.1.1.7 specifies the sysContact object in the system group, relative to the internet (.1.3.6.1) node in the OID tree. This is called a relative OID.
The internet subtree branches into mgmt and private. All the standard MIBs are under mgmt, while the private MIBs are under the private.enterprises subtree.
The standard MIBs are those that have been approved by the IAB. Equipment and software vendors define the private MIBs unilaterally. A branch within the private.enterprises subtree is allocated to each vendor who registers for an enterprise Object Identifier. The distinction between the standard and private MIBs is based on how the variables are defined.
The best example of a standard MIB is the RFC1213-MIB (also known as MIB-II). It is a MIB module which is typically supported by all SNMP agents on TCP/IP-enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, as well as the Object ID, syntax, and access privileges for each variable in the MIB.
To know more on RFC, visit http://www.rfc-editor.org/rfcfaq.
One key aspect of MIBs is that, only the types of objects on the managed device are specified by the MIB and not the specific objects (or instances). For example, ifInOctets in RFC 1213-MIB specifies a type of object, for number of input octets on an interface, but the specific objects or instances of that type are specified as ifInOctets.1, ifInOctets.2, etc., depending on the number of interfaces. When specifying an object to the SNMP agent, a proper Object ID, which includes the instance, needs to be used by the manager. When not properly specified, the agent responds with a "No such variable" error.
Object Identifier with Instance Indexes
To obtain values of objects from the agent, you need to specify the instance of the object. Appending an instance index to the object identifier specifies the instance of an object. For example, the last 0 in:
.iso.3.dod.1.mgmt.mib-2.1.sysUpTime.0
is the instance index. An instance index of "0" (zero) specifies the first instance, "1" specifies the second instance, and so on. Since sysUpTime is a scalar object, it has only one instance. Therefore, an instance index of zero is always specified when retrieving the value of a scalar object. An instance index higher than 0 can only be used in the case of columnar objects (in table), which can have multiple instances.
Structure of Management Information (SMI) is a set of rules used to specify the format for defining managed objects.
SMI describes the MIB naming tree that is used to identify managed objects and defines the branch of the MIB tree where SNMP managed objects reside. The SMI does not define a managed object but describes a format for defining a managed object.
The two versions of SMI are SMIv1 and SMIv2. SMIv1 is defined by RFC1155, RFC1212, and RFC1215 and the SMIv2 is defined by RFC1902, RFC1903, and RFC1904.
SMIv1 is a backward compatible update of SMIv1. This means that it is possible to convert an SMIv2 MIB to SMIv1 except for objects whose data type is Counter64. But when it comes to converting SMIv1 to SMIv2, there is no mechanical way of doing it because there is more information in the SMIv2 than in SMIv1. Also, the SMIv2 format contains constructs to define requirement specifications and implementation specifications, which do not form a part of the SMIv1.
|
|