MIB overview

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

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 vendors, 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.

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 an event occurs that typically does not require any administrative intervention.

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.

To help administrators determine whether a message requires immediate action, this document classifies notifications into the severity levels in Table 1.

 

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.

 

NOTE: The severity level of a recovery notification is typically set to Warning or the same level as its paired error notification. The severity level of an informational notification is typically set to Warning and it might be set to a higher severity level if administrative action is desirable. In this document, a hyphen (-) or N/A might be used to represent the Warning severity level for a recovery or informational notification.

 

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 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.

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.
Syntax	Data type defined in the SYNTAX clause for the object in the MIB file.
Value range	Values or value ranges defined in the SYNTAX clause for the object in the MIB file.
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.

 

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. In this document, a hyphen (-) or N/A might be used to represent the Warning severity level for a recovery or informational notification.
Recovery notification	Created when the hardware or software recovers from an error condition.
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.

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

 

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 a variable, look up teTunnelName and tePathName in the document. You can then find tabular objects teTunnelTable and tePathTable, respectively. The index information is right below the tabular object name.

teTunnelTable

The table index is teTunnelIndex.

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..2147483647)	Tunnel index.	As per the MIB.
teTunnelName (1.3.6.1.2.1.122.1.2.1.2)	read-create	OCTET STRING	OCTET STRING (1..32)	Tunnel name.	As per the MIB.

 

Because the table index for teTunnelTable is teTunnelIndex, the index value .1 in teTunnelName.1 represents the tunnel index with a value of 1.

tePathTable

The table indexes are teTunnelIndex and tePathIndex.

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.
tePathName (1.3.6.1.2.1.122.1.3.1.2)	read-create	OCTET STRING	OCTET STRING (1..32)	Application path index.	The object is read only.

 

Because the table indexes of tePathTable are teTunnelIndex and tePathIndex, the index values .1 and .0 in ePathName.1.0 represent the teTunnelIndex and tePathIndex instances with a value of 1 and 0, respectively.