About MIBs
Each network device managed by SNMP must have a MIB that describes its manageable objects. MIBs are collections of objects or definitions that define the properties of the managed objects. Each managed object has specific characteristics.
The manager relies upon the database of definitions and information about the properties of managed resources and the services the agents support. When new agents are added to extend the management domain of a manager, the manager must be provided with a new MIB component that defines the manageable features of the resources managed through that agent.
The data types and the representations of resources within a MIB, as well as the structure of a particular MIB, are defined in a standard called the Structure of Management Information (SMI).
Object Identifiers and Instance IDs
Each managed object/characteristic has a unique object identifier (OID) consisting of numbers separated by decimal points (for example, 1.3.6.1.4.1.9148.1); numeric OIDs can also be translated into human-readable form. The MIB associates each OID with a readable label and various other parameters related to the object. The OID identifies the location of a given managed object within the MIB tree hierarchy by listing the numbers in sequence from the top of the tree down to the node, separated by dots.
By specifying a path to the object through the MIB tree, the OID allows the object to be uniquely identified. The digits below the enterprise OID in the tree can be any sequence of user-defined numbers chosen by an organization to represent its private MIB groups and managed objects.
An instance ID identifies developments that have occurred for the managed object. The instance ID values are represented as a combination of the OID and the table index. For example, you can find the following instance ID in the TCP connection table:
tcpConnState.127.0.0.1.1024.127.0.0.1.3000
- tcpConnState is the OID
- 127.0.0.1 is an IPv4 address
- 1024 is the port number
- 127.0.0.1 is another IPv4 address
- 3000 is another port number
MIB Tree Structure
MIBs are arranged in a tree-structured fashion, similar in many ways to a operating system directory structure of files. The following diagram illustrates a MIB tree with a sample of the standard MIBs shown under the mib-2 node and a sample of a system management enterprise MIB under the enterprise node. (The listing is only a partial sample of the MIB contents.)
The diagram shows how the OID is a concatenation of the prior addresses up to that point. For example, the OID for apSysCPUUtil is 1.3.6.1.4.1.9148.3.2.1.1.1.
Managed Objects
Managed objects are made up of one or more object instances, which are essentially variables. Managed objects can be scalar (defining a single object instance) or tabular (defining multiple, related instances).
Scalar MIB Objects
Scalar MIB objects contain one precise piece of data (also referred to as discrete). These objects are often distinguished from the table objects by adding a .0 (dot-zero) extension to their names. Many SNMP objects are scalar. That is, the operator merely has to know the name of the object and no other information. Discrete objects often represent summary values for a device, particularly useful for scanning information from the network for the purposes of comparing network device performance. If the extension (instance number) of the object is not specified, it can be assumed as .0 (dot-zero). See the Enterprise SNMP Get Requests chapter for examples of scalar MIB objects.
Table MIB Objects
Table MIB objects contain multiple pieces of management data. These objects are distinguished from the scalar objects by requiring a . (dot) extension to their names that uniquely distinguishes the particular value being referenced. The . (dot) extension is also referred as the instance number of an SNMP object. In the case of table objects, this instance number is the index into the SNMP table. (In the case of scalar objects, this instance number is zero.)
SNMP tables allow parallel information to be supported. Tables are distinguished from scalar objects, in that tables can grow without bounds. For example, SNMP defines the ifDescr object as a standard SNMP object, which indicates the text description of each interface supported by a particular device. Since network devices can be configured with more than one interface, this object could only be represented as an array. By convention, SNMP objects are always grouped in an Entry directory, within an object with a Table suffix. (The ifDescr object described above resides in the ifEntry directory contained in the ifTable directory.) See the Enterprise SNMP Get Requests chapter for examples of table MIB objects.