MIB overview

This document provides information about the management information bases (MIBs) available for the device, including public and private MIBs.

A MIB is a collection of managed objects. An object can be a parameter available on a network, such as interface state or CPU usage. An SNMP network management system can access the MIB on a managed device to obtain data for the parameters of interest. MIB objects are also called nodes. Every SNMP device has a MIB. A MIB defines the hierarchy and attributes of objects, such as their names, access permission, and data type. The MIB of a managed device is available in MIB files. Typically, a device has one MIB file for a feature module.  An NMS compiles the MIB files to generate the MIB of the device. Then, the NMS reads from or writes to the objects of interest based on object access permission to manage the device. The NMS also parses SNMP notifications received from the device based on the MIB object definitions.

About MIBs

MIB modules and MIB files

A MIB is a collection of information organized hierarchically in a tree structure. Each node in a MIB is a managed object uniquely identified by an object identifier (OID). An OID is a dotted numeric string that uniquely identifies the path from the root node to a leaf node.

Collections of related objects are defined in MIB modules. Typically, each MIB module has a MIB file. You can run a MIB compiler to compile the MIB files of the managed device into a visualized MIB tree for the ease of management, as shown in Figure 1.

Figure 1 MIB tree after compilation

 

Types of MIB objects

MIB objects are classified into scalar objects, tabular objects, and notification objects. The SNMP manager can access only the instances of MIB objects.

Scalar objects

Scalar objects are single-instance objects. An example of a scalar object is sysUpTime, which contains only one object instance to store the time since the network management portion of the system was last initialized. The instance of a scalar object is identified by an index value of 0. When the SNMP manager accesses the instance of a scalar object, the SNMP manager must add a suffix of .0 to the object identifier or object name, as shown below:

Protocol version:SNMPv2c

Operation:Get

Request binding:# Request sent by the SNMP manager

1:sysUpTime.0 (TimeTicks) null

 

Response binding:# Response sent by the SNMP agent (the device)

1:sysUpTime.0 (TimeTicks) 29 days 15h:25m:15s.64th (256111564)

Tabular objects

Tabular objects define multiple related objects in conceptual tables. You can think of a tabular object as a table in which objects are columns and their instances are rows. The objects in a table are also called columnar objects. An example of a tabular object is ifDescr, which contains multiple instances to store the descriptions of different interfaces. When the SNMP manager accesses an instance of this object, the SNMP manager must add its index value, as shown below:

Protocol version:SNMPv2c

Operation:Get

Request binding:# Request sent by the SNMP manager

1:ifDescr.17 (DisplayString) null

 

Response binding:# Response sent by the SNMP agent (the device)

1:ifDescr.17 (DisplayString) Aux0 [41.75.78.30 (hex)]

To access an object instance correctly, you must add its index values correctly.

Notification objects

A notification object describes an unsolicited transmission of information about an event, for example, a failure or recovery event.

For example, the following linkUp and linkDown objects describe notifications about interface up and interface down events, respectively.

 

MIB support status

A MIB module, tabular object, or scalar object is commented as "Not supported" if it is not supported by the device. To avoid unknown issues, do not access such a MIB, table, or scalar object even if it is accessible.

If a MIB is not supported, its notifications are not supported as well.

For backward compatibility and interoperability with third-party NMSs, the software release might contain deprecated or obsolete MIB modules or objects. This document lists these MIB modules and objects but does not provide detailed information about them.

Guidelines on MIB-based configuration and management

IMPORTANT: To avoid unknown issues, do not access a MIB, table, or scalar object commented as "Not supported" even if it is accessible.

 

You can configure the device by setting its supported MIB objects. To make sure the values set in MIB objects can be restored correctly from the command line interface (CLI), use the following restrictions and guidelines:

·     As a best practice, use visible characters from 0x21 to 0x7E, except for 0x3F, which represents the question mark (?). If you need to use a special character, make sure the CLI supports that character. For example, the CLI uses the space for delimitation and uses the question mark for help indication. If a value contains a space or question mark, the CLI might be unable to restore that value.

·     Make sure the value set in the MIB object is in the value range supported in the CLI. In rare situations, an MIB object might support a different value range than the CLI. For example, an OCTET STRING type MIB object might support longer strings than the maximum length allowed in the CLI. If the value set in the MIB object exceeds the maximum length allowed in the CLI, the CLI will be unable to restore the value correctly. Conversely, if a value set in the CLI is beyond the value range for the MIB object, the system cannot set that value in the MIB object.

Obtaining SNMP notifications

To have the device send SNMP notifications to an NMS:

·     Configure the device with the same SNMP version as the NMS.

·     Configure a community string or SNMP user depending on the SNMP version:

¡     If SNMPv1 or SNMPv2c is used, use the snmp-agent community command to configure a community string.

¡     If SNMPv3 is used, use the snmp-agent group command to configure an SNMP user group, and use the snmp-agent usm-user command to configure an SNMPv3 user in the group.

·     Enable SNMP notifications. You can use the snmp-agent trap enable command to enable SNMP notifications for all feature modules except the following modules:

¡     Modules that do not use this command for notification control. For example, NQA uses the reaction trap command to control notifications.

¡     Modules that use this command only for global notification control. For example, to send link state notifications for a port, you must configure the enable snmp trap updown command in addition to the snmp-agent trap enable command.

To identify the notification control commands for these two types of modules, look up the trap keyword in the module-specific command references.

·     Use the snmp-agent target-host command to configure settings for reaching the NMS, including the IP address of the NMS and the authentication settings.

For more information about SNMP settings, see the network management and monitoring configuration guide for the device.

Types and severity levels of notifications

The notifications are divided into the following types:

·     Error notifications—Created when hardware or software exceptions occur.

·     Recovery notifications—Created when the hardware or software recovers from an error condition.

·     Informational notifications—Created when administrative operations are performed or when system events such as device state changes occur. Informational notifications typically do not require administrative intervention.

To help administrators determine whether a message requires immediate action, this document assigns a severity level to each notification depending on their impact. As shown in Table 1, the severity level for a notification can be Critical, Major, Minor, Warning, or Informational, from the highest severity to the lowest severity.

 

NOTE: The notification type and severity level information in this document is provided only as a reference for network administrators. SNMP notifications do not contain this information.

 

Table 1 Notification severity levels

Severity	Description
Critical	Asset at risk. Immediate action required. For example, a temperature control issue is critical.
Major	Significant impact or risk. Immediate action required.
Minor	Minor impact or risk. Action required with medium to low priority.
Warning	Needs to be reviewed to determine whether action is necessary.
Informational	This level applies to notifications that report  administrative operations or system state changes and typically does not require administrative action.

 

NOTE: The severity level of an error notification is set to Critical, Major, Minor, or Warning, depending on its impact. The severity level of a recovery notification is typically set to the same level as its paired error notification. The severity level of an informational notification is typically set to Informational and it might be set to a higher severity level if administrative action is desirable.

 

Using this document

This document describes MIBs in alphabetical order.

Information about scalar and tabular objects

This document presents information about scalar and tabular objects in tabular form, as shown in the following example:

Object (OID)	Access	Syntax	Value range	Description	Implementation
ifIndex (1.3.6.1.2.1.2.2.1.1)	read-only	Integer32	Integer32 (1..2147483647)	Interface index.	As per the MIB.

 

The following table provides an explanation of each field in the object information tables:

Item	Description
Object (OID)	Object name and its OID.
Access	The value of the MAX-ACCESS clause in the MIB for the object. It defines the access rights to the object. The following are types of access available for MIB objects: ·     not-accessible: The MIB object is not available for read, write, or create operations, and it cannot be used as a variable binding in a notification. This type of object is typically an index node for tabular objects and can only be used as part of the OID for a tabular object. ·     accessible-for-notify: The MIB object is not available for read, write, or create operations. However, it can be used as a variable binding in a notification. For more information about variable bindings, see "Variable bindings in SNMP notifications." ·     read-only: The MIB object is accessible only for read operations. ·     read-write: The MIB object is accessible for read and write operations. However, it is not available for create operations. ·     read-create: The MIB object is available for read, write, and create operations and can be used as a variable binding in a notification. The level of access permissions represented by these access levels increase from the top down, with not-accessible for the lowest level and read-create for the highest level.
Syntax	Data type defined in the SYNTAX clause for the object in the MIB file. Common syntax type definitions include basic types, BITS type, and textual conventions. For more information about the definitions of these syntax types, see "Syntax types."
Value range	Values or value ranges defined in the SYNTAX clause for the object in the MIB file. ·     For a numeric-type MIB object, the valid value range is the range of values that the object actually supports, including the list of values listed in enumeration. ·     For a string-type MIB object, the valid value range is typically the length range for the string.
Description	Explanation of the object.
Implementation	Implementation of the MIB object on the device. ·     If the object is implemented in full compliance with the MIB, this field displays As per the MIB. ·     If the object is accessible but it is not supported or tested, this field displays Not supported. To avoid unknown issues, do not access such MIB objects. ·     Any implementation restrictions, which might differ depending on the product model and software version.

 

For a tabular object, this document also provides information about the index or indexes used for it to identify instances and the support for table instance operations.

The support for table instance operations is presented in tabular form, as shown in the following example:

Create	Edit/Modify	Delete	Read
Supported	Supported	Supported	Supported

 

The following table provides an explanation of each field in the object information tables:

Item	Description
Create	Support of the table for the create operation and restrictions on the create operation (if any). ·     Supported—You can add object instances to the table. ·     Not supported—You cannot add object instances to the table.
Edit/Modify	Support of the table for the modify (also called edit) operation and restrictions on the modify operation (if any). ·     Supported—You can modify object instances in the table. ·     Not supported—You cannot modify object instances in the table.
Delete	Support of the table for the delete operation and restrictions on the delete operation (if any). ·     Supported—You can delete object instances from the table. ·     Not supported—You cannot delete object instances from the table.
Read	Support of the table for the read operation and restrictions on the read operation (if any). ·     Supported—You can read object instances in the table. ·     Not supported—You cannot read object instances in the table.

 

Information about notification objects

This document presents information about notification objects in tabular form, as shown in the following example:

OID	Event	Type	Severity	Recovery notification	Default status
1.3.6.1.6.3.1.1.5.3	Interface link failure.	Error	Major	1.3.6.1.6.3.1.1.5.4 (linkUp)	ON

 

The following table provides an explanation of each field in the object information tables:

Item	Description
OID	OID of the notification object in the MIB.
Event	Description of the event that triggers the notification.
Type	Notification type. This information helps you identify the health state of the device and filter notifications. ·     Error notifications—Created when hardware or software exceptions occur. ·     Recovery notifications—Created when the hardware or software recovers from an error condition. ·     Informational notifications—Created when an event occurs that does not require any administrative actions. Typically, error and recovery notifications report pairs of related events, and informational notifications report independent events. For example, a linkDown error notification is generated when a physical link is disconnected. When the physical link comes up, a linkUp recovery notification is generated. When the device is rebooted from the CLI, a coldStart informational notification is generated.
Severity	Severity of the notification. This information helps you determine whether action is required in response to the notification. SNMP notification packets do not contain this severity level information. ·     Critical—Asset at risk. Immediate action required. For example, immediate action is required to take on temperature control issues. ·     Major—Significant impact or risk. Immediate action required. ·     Minor—Minor impact or risk. Action required with medium to low priority. ·     Warning—Needs to be reviewed to determine whether action is necessary. ·     N/A—Action not required. This level applies to recovery and informational notifications.
Recovery notification	Created when the hardware or software recovers from the error condition triggered by the event. If the event triggers a recovery or informational notification, this field displays N/A.
Default status	Default status of the notification: ·     ON—The notification is enabled. ·     OFF—The notification is disabled.

 

Variable bindings in SNMP notifications

An SNMP notification contains a list of variable bindings to describe the event that triggered the notification. By parsing the variable binding list, you can obtain information such as on which interface the event occurred and which module reported the event. In the variable binding list, each binding is a pair of object instance OID and value.

This document presents information about the list of variable bindings in a notification in tabular form, as shown in the following example:

OID (object name)	Description	Index nodes	Type	Value range
1.3.6.1.2.1.2.2.1.1 (ifIndex)	Interface index.	ifIndex	InterfaceIndex	Integer32 (1..2147483647)

 

The following table provides an explanation of each field in the table of the objects bound to a notification as variables:

Item	Description
OID (object name)	The OID and name of each object in the list of variable bindings. In a notification message, this field contains the OID and indexes.
Description	Description of the object.
Index nodes	Index nodes for the variable binding. If a variable binding is a scalar object, this field displays N/A. Index nodes identify the object instances for which the notifications are generated.
Type	Data type defined in the SYNTAX clause for the object in the MIB file.
Value range	Value range defined in the SYNTAX clause for the object in the MIB file.

 

Types of bindings in the variable binding list

A variable binding list contains mandatory bindings and notification-specific bindings.

·     Objects in mandatory bindings are defined in SNMP and included in every SNMP notifications.

·     Notification-specific bindings differ depending on the definition of the notification object.

For example, Figure 2 shows the variable binding list in an SNMPv2 linkUp notification.

Figure 2 Variable binding list in an SNMPv2 linkUp notification

 

In this variable binding list, two are mandatory variable bindings and three are notification-specific bindings.

·     The mandatory variable bindings contain the following object instances:

¡     sysUpTime.0—Contains the time when the notification was generated. In this example, its value is 88308.

¡     snmpTrapOID.0—Contains the name or OID of the notification object. In this example, the notification object is linkUp.

·     The notification-specific bindings contain the following object instances:

¡     ifIndex.2—Index of the interface on which the event occurred. In this example, the interface index is 2. In addition, ifIndex is also the index for the linkUp notification object.

¡     ifAdminStatus.2—The administrative state of the interface. In this example, the index of the interface on which the event occurred is 2. The value for the administrative state of the interface is 1.

¡     ifOperStatus.2—Status of the operation on the interface on which the event occurred. In this example, the interface index is 2. The value for the operation status is 1.

The variable binding list in Figure 2 is in a user-friendly view presented by the network management software after OID translation and numeration value conversion. Figure 3 shows the binding list without OID translation and numeration value conversion. With most network management software offerings, you can choose between the two views as needed.

Figure 3 Variable binding list in an SNMPv2 linkUp notification without

 

The MIB reference documents describe only the notification-specific bindings. For example, the IF-MIB reference document provides information about the notification-specific variable bindings for the linkUp notification object as follows:

OID (object name)	Description	Index nodes	Type	Value range
1.3.6.1.2.1.2.2.1.1 (ifIndex)	Interface index.	ifIndex	InterfaceIndex	Integer32 (1..2147483647)
1.3.6.1.2.1.2.2.1.7 (ifAdminStatus)	Administrative status of the interface.	ifIndex	INTEGER	up(1) down(2) testing(3)
1.3.6.1.2.1.2.2.1.8 (ifOperStatus)	Operational status of the interface.	ifIndex	INTEGER	up(1) down(2) testing(3) unknown(4) dormant(5) notPresent(6) lowerLayerDown(7)

 

As shown in the table above, the linkUp notification object has three notification-specific variable bindings and all of them are indexed on ifIndex.

·     The ifIndex.2 variable binding represents the ifIndex object instance with an index value of 2 (ifIndex=2).

·     The ifAdminStatus.2 variable binding represents the ifAdminStatus object instance for the ifIndex object instance with an index value of 2 (ifIndex=2).

·     The ifOperStatus.2 variable binding represents the ifOperStatus object instance for the ifIndex object instance with an index value of 2 (ifIndex=2).

Because the variable binding list in this example contains the index node ifIndex, the index values for the variables can also be set to "=2".

Obtaining information about indexes in variable bindings

A notification-specific variable might be an object instance identified by one index or multiple indexes. The index values are appended to the end of the object name. To obtain information about the indexes for an object instance, use the object name in the binding as the keyword to search the MIB document for the object table. Then, you can find indexing information for that table.

For example, Figure 4 shows the variable biding list in a teTunnelUp notification.

Figure 4 Variable binding list in a teTunnelUp notification

 

The teTunnelUp notification in this example contains the following notification-specific variable bindings:

·     teTunnelName.1—Name of the tunnel on which the event occurred. In this example, the tunnel is identified by a value of index 1. Its tunnel name is Tunnel1.

·     tePathName.1.0—The administrative status of the TE path on which the event occurred. The TE path is identified by two indexes. One index has a value of 1 and the other index has a value of 0. The value for the administrative status is a zero-length string.

To obtain information about the index or indexes of teTunnelName.1 or tePathName.1.0, examine the Index nodes column in the objects table for the notification, as shown below:

OID (object name)	Description	Index nodes	Type	Value range
1.3.6.1.2.1.122.1.2.1.2 (teTunnelName)	TE tunnel name.	teTunnelIndex	SnmpAdminString	OCTET STRING (SIZE (1..32))
1.3.6.1.2.1.122.1.3.1.2 (tePathName)	Name of the path for the TE tunnel.	teTunnelIndex tePathIndex	SnmpAdminString	OCTET STRING (SIZE (0..32))

 

The objects table for the notification shows that teTunnelIndex is the index node for teTunnelName, and tePathIndex and tePathIndex are the index nodes for tePathName. Look up the two nodes in the document, you can obtain detailed information about them, as shown below:

Object (OID)	Access	Syntax	Value range	Description	Implementation
teTunnelIndex (1.3.6.1.2.1.122.1.2.1.1)	not-accessible	Unsigned32	Unsigned32 (1..4294967295)	Tunnel index.	As per the MIB.

 

Object (OID)	Access	Syntax	Value range	Description	Implementation
tePathIndex (1.3.6.1.2.1.122.1.3.1.1)	not-accessible	Unsigned32	Unsigned32 (1..2147483647)	Applicable path index.	As per the MIB.

 

You can obtain the following information from the tables above:

·     The index node for teTunnelName is teTunnelIndex and the value type of this index node is Unsigned32. Then, the index value .1 in teTunnelName.1 represents the tunnel instance indexed on TE tunnel index 1 (teTunnelIndex=1).

·     The index nodes for tePathName are teTunnelIndex and tePathIndex and the vlaue types of these two index nodes are Unsigned32. Then, the index values .1 and .0 in ePathName.1.0 represent the teTunnelIndex and tePathIndex instances with a value of 1 and 0 (teTunnelIndex=1 and tePathIndex=0), respectively.

Syntax types

The following information provides definitions of primitive data types. In SNMP messages, data types are encoded using Abstract Syntax Notation One (ASN.1) abstract data types. An NMS should parse SNMP messages based on the ASN.1 format.

Basic types

Syntax	Definition
Integer32 INTEGER	An integer in the range of -2147483648 to 2147483647.
OCTET STRING	Any binary or textual string.
OBJECT IDENTIFIER	An integer string separated by dots (.), with up to 128 segments. The maximum value for each segment is 4294967295. The 1.3.6.1.2.1.2.2.1.1 string is an example of the OBJECT IDENTIFIER data type.
IpAddress	A 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte order.
Counter32	A non-negative integer that monotonically increases until it reaches a maximum value. The value range for this data type is 0 to 4294967295.
Gauge32	A non-negative integer that can increase or decrease. The value range for this data type is 0 to 4294967295.
TimeTicks	A non-negative integer that counts the time in hundredths of a second (0.01) since some epoch.
Counter64	A non-negative integer that monotonically increases until it reaches a maximum value. The value range for this data type is 0 to 18446744073709551615. This data type is not available in SNMPv1.
Unsigned32	A non-negative integer in the range of 0 to 4294967295.

 

BITS type

Syntax

Definition

BITS

An enumerated bit string that specifies named constants for different bit positions. Look at the following example: BITS {noDefect(0), lossOfFraming(1), lossOfSignal(2), lossOfPower(3), lossOfSignalQuality(4)} Starting from the most significant bit in this enumeration, a value of 1 at bit 0 represents noDefect, a value of 1 at bit 1 represents lossOfFraming, and a value of 1 at bit 2 represents lossOfSignal, and so on.

 

Textual conventions

Textual conventions improve the readability of parameters by adding constraints to basic data types. RFCs define some basic textual conventions, and each MIB module might also defined module-specific textual conventions.

The following table lists some commonly used data types defined in RFC 2578, RFC 2579 and RFC 4001:

Syntax	Definition
DisplayString	OCTET STRING (SIZE (0..255)) The value range is limited to ASCII codes in the range of 32 to 126, as well as NUL, LF, CR, BEL, BS, HT, VT, and FF.
MacAddress	OCTET STRING (SIZE (6)) Represents an IEEE 802.11a-compliant MAC address.
TruthValue	INTEGER { true(1), false(2) }
RowStatus	INTEGER {active(1), notInService(2), notReady(3),createAndGo(4), createAndWait(5), destroy(6) } For newly-defined conceptual rows that allow creation of new object instances and or deletion of existing object instances, there should be one columnar object with a SYNTAX clause value of RowStatus. For more information, see RFC 2579.
TimeStamp	TimeTicks The value of the sysUpTime object at which a specific event occurs. This is a timer that counts in hundredths of a second (0.01) since the network management portion of the system was last initialized.
TimeInterval	INTEGER (0..2147483647) Time length in hundredths of a second (0.01).
DateAndTime	OCTET STRING (SIZE (8 | 11)) Date and time string. The length of the time string is 8 bytes when it does not include a time zone, and 11 bytes when it includes a time zone. This type of string uses a format of 2d-1d-1d,1d:1d:1d.1d,1a1d:1d, which translates to year-month-day, hour:minute:seconds.deci-seconds, +-time zone:time zone minutes. For example, the 1992-5-26,13:30:15.0,-4:0 string represents May 26th, 1992 at 1:30:15 pm with a time zone 4 hours behind UTC.
CounterBasedGauge64	Counter64 A 64-bit gauge defined with the Counter64 syntax. It represents a non-negative integer, which increase or decrease.
InetAddressType	INTEGER {unknown(0), ipv4(1), ipv6(2), dns(16) } A value that represents a type of Internet address. The InetAddressType object must precede the InetAddress object to provide a context for interpretation of the InetAddress value.
InetAddress	OCTET STRING (SIZE (0..255)) A generic Internet address in hexadecimal notation.
InetAddressIPv4	OCTET STRING (SIZE (4)) An IPv4 network address.
InetAddressIPv6	OCTET STRING (SIZE (16|20)) An IPv6 network address. The length of a global IPv6 address is 16 bytes, and the length of non-global IPv6 address is 20 bytes.
InetAddressDNS	OCTET STRING (SIZE (1..255)) DNS domain name.
InterfaceIndex	Integer32 (1..2147483647) A non-zero integer that represents an interface index.
SnmpAdminString	OCTET STRING ( 0.. 255) An octet string containing administrative information, preferably in human-readable form.

 

Supported SNMP RFCs

RFC	Title	Status
RFC 1155	Structure and identification of management information for TCP/IP-based internets	Standard
RFC 1157	Simple Network Management Protocol (SNMP).	Historic
RFC 1212	Concise MIB definitions.	Standard
RFC 1213	Management Information Base for Network Management of TCP/IP-based internets:MIB-II	Standard
RFC 2578	Structure of Management Information Version 2 (SMIv2).	Standard
RFC 2579	Textual Conventions for SMIv2.	Standard
RFC 2580	Conformance Statements for SMIv2.	Standard
RFC 3411	An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks.	Standard
RFC 3412	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP).	Standard
RFC 3413	Simple Network Management Protocol (SNMP) Applications.	Standard
RFC 3414	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3).	Standard
RFC 3415	View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP).	Standard
RFC 3416	Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP).	Standard
RFC 3417	Transport Mappings for the Simple Network Management Protocol (SNMP).	Standard
RFC 3418	Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.	Standard
RFC 3584	Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.	Best Current Practice
RFC 3826	The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model	Proposed Standard
RFC 4001	Textual Conventions for Internet Network Addresses	Standards Track
RFC 7860	HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3	Standards Track
draft-reeder-snmpv3-usm-3desede	Extension to the User-Based Security Model (USM) to Support Triple-DES EDE in "Outside" CBC Mode	Draft