Contents

• MIBs and System Management
• System Management and MIBs
• Accessing MIB Variables Through SNMP
• SNMP Traps and Informs
• Interpreting the MIB Structure
• Object Identifiers
• Tables
• SYNTAX Clause
• MAX-ACCESS Clause
• AGENT-CAPABILITY Files

MIBs and System Management

---

This chapter includes the following sections:

• System Management and MIBs
• Accessing MIB Variables Through SNMP
• SNMP Traps and Informs
• Interpreting the MIB Structure

System Management and MIBs

Note

The Cisco UCS MIB includes Cisco proprietary MIBs and other Internet Engineering Task Force (IETF) standard MIBs. These standard MIBs are defined in Requests for Comments (RFCs). To find specific MIB information, you must examine the Cisco proprietary MIB structure and related IETF-standard MIBs supported by Cisco UCS Manager.

Network management takes place between two major types of systems:

• Systems in control, or managing systems.
• Systems that managing systems observe and control, or managed systems.

The most common managing system is the Network Management System (NMS). Managed systems include Cisco UCS, hosts, servers, or network components such as switches and routers.

To promote interoperability, cooperating systems must adhere to a common framework and a common language or protocol. In the Internet-standard management framework, that protocol is the Simple Network Management Protocol (SNMP).

The exchange of information between Cisco UCS and an NMS is essential for reliable performance of a managed network. The NMS runs the network management applications, like Data Center Network Manager, that provide management information to network managers and other users.

In a Cisco UCS fabric interconnect, specialized low-impact software modules called agents access information about the fabric interconnect and make it available to the NMS. A fabric Interconnect also maintains values for SNMP management variables and report those, as required, to the NMS. For example, an agent might report the number of bytes and packets sent or received by the fabric interconnect, or the number of broadcast messages sent and received. In SNMP, each of these variables is referred to as a managed object. A managed object is anything that can be managed or anything that an agent can access and report back to the NMS. All managed objects are contained with the MIB, which is a database of the managed objects.

An NMS monitors a fabric interconnect by sending a request to an agent for the managed switch. The requests are received as a get request, which retrieves the value of a variable or a list of variables.

The fabric interconnect responds only to the get requests. The get requests are synchronous events, which means that the NMS initiates the activity, and the SNMP agent responds.

The fabric interconnect can also send SNMP notifications to the NMS to inform it of some recent event. SNMP notifications, traps, or informs are included in many MIBs and allow the NMS to send get requests to the fabric interconnect less frequently.

The SNMP set requests are not supported on Cisco UCS.

Note	For configuration changes to the Cisco UCS Manager, use either the Cisco UCS Manager GUI, Cisco UCS Manager XML API, or the Cisco UCS Manager CLI.

Accessing MIB Variables Through SNMP

You access Cisco UCS MIB variables using SNMP. SNMP consists of three parts:

• The SNMP manager
• The SNMP agent
• The MIB

You can compile Cisco UCS MIBs with your network management software. If SNMP is configured on a fabric interconnect, the SNMP agent responds to MIB-related queries sent by the NMS.

The following table describes SNMP operations.

Table 1 SNMP Operations

Operation	Description
get-request	Retrieves a value from a specific variable.
get-next-request	Retrieves the value following the named variables. This request is often used to retrieve variables from within a table. With this operation, an SNMP manager does not need to know the exact variable name. A sequential search finds the next variable in the MIB.
get-bulk	Retrieves large blocks of data, such as multiple rows in a table. Note    This command is not a part of SNMPv1.
response	Replies to the requests get-request, get-next-request, get-bulk, and set-request. It also replies to the informs sent by an agent.
trap	Sends an unsolicited message from an agent to a manager, indicating that an event has occurred.
inform	Sends an unsolicited message from an agent to a manager, indicating that an event has occurred. An inform differs from a trap in that an acknowledgment is required from the manager. Note    This command is not a part of SNMPv1.

Note	SNMPv1 was the initial version of the protocol. SNMPv2 added support for 64-bit counters, and SNMPv3 added increased security for access, authentication, and encryption of managed data.

SNMP Traps and Informs

You can configure Cisco UCS Manager to send notifications to SNMP managers when particular events occur. You send these notifications as traps or informs. Traps are unreliable because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. However, an SNMP manager that receives an inform acknowledges the message with a response. If the sender never receives a response, the inform request can be sent again. Informs are more likely to reach their intended destinations than traps.

Notifications may contain a list of MIB variables (varbinds) that provide detailed information about these notifications.

The list of varbinds associated with a notification is included in the notification definition within the MIB. In the case of standard MIBs, Cisco has enhanced some notification with additional varbinds, that further clarify the cause of the notification. See Extending the IF-MIB for an example of these extensions in the IF-MIB.

Note	You must configure SNMP in Cisco UCS Manager. For more information, see the Cisco UCS Manager GUI Configuration Guide for the version of Cisco UCS Manager GUI that you are using.

Interpreting the MIB Structure

A MIB presents managed data in a logical tree hierarchy, using an IETF standard syntax called the Structure of Management Information (SMI). Branches of this MIB tree are organized into individual tables, which contain the managed data as leaf objects.

• Object Identifiers
• Tables
• SYNTAX Clause
• MAX-ACCESS Clause
• AGENT-CAPABILITY Files

Object Identifiers

The root of the MIB tree is unnamed and splits into three main branches:

• Consultative Committee for International Telegraph and Telephone (CCITT)
• International Organization for Standardization (ISO)
• Joint ISO/CCITT

These branches and the branches below each category have short text strings and integers to identify them. The text strings are object names, while the integers allow the management software to create compact, encoded representations of the names.

Each MIB variable is assigned with an object identifier. An object identifier is the sequence of numeric labels on the nodes along a path from the root to the object. For example, the MIB variable tftpHost is indicated by the number 1.

The following is the object identifier for tftpHost:

iso.org.dod.internet.private.enterprise.cisco.workgroup products.stack
group.tftp group.tftpHost

The following is the object identifier for tftpHost in integer form:

1.3.6.1.4.1.9.5.1.5.1

The last value is the number of the MIB variable tftpHost.

Tables

When network management protocols use names of MIB objects in messages, each name has an appended suffix. This suffix is called an instance identifier. It identifies one occurrence of the associated MIB object. For simple scalar objects, the instance identifier 0 refers to the instance of the object with that name. The following is an example of an instance:

sysUpTime.0

A MIB can also contain tables of related objects. For example, ifOperStatus is a MIB object inside the ifTable from the IF-MIB. It reports the operational state for an interface on a switch. Because switches may have more than one interface, it is necessary to have more than one instance of ifOperStatus. This instance value is added to the end of the MIB object as the instance identifier. The following example reports the operational state for interface number 2:

ifOperStatus.2

Each object in a table is constructed with a set of clauses defined by the SMI. These clauses include the SYNTAX clause, the MAX-ACCESS clause, the STATUS clause, and the DESCRIPTION clause.

The following example shows some of information in the table named vsanTable:

vsanTable OBJECT-TYPE
        SYNTAX     SEQUENCE OF VsanEntry
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
        "A table of VSANs configured on this device."
 ::= { vsanConfiguration 3 }
vsanEntry OBJECT-TYPE
        SYNTAX     VsanEntry
        MAX-ACCESS not-accessible
        STATUS     current
        DESCRIPTION
               "An entry (conceptual row) in the vsanTable."
        INDEX { vsanIndex }
        ::= { vsanTable 1 }
VsanEntry ::= SEQUENCE {
        vsanIndex                 VsanIndex,
        vsanName                  SnmpAdminString,
 }

In the following example, vsanTable contains two variables:

• vsanIndex
• vsanName

The index for this table is the ID of the VSAN, or vsanIndex. With n number of VSANs configured, n rows are present in the table. If you want to retrieve the vsanName that matches VSAN ID 3 (vsanIndex is 3), then you would issue an SNMP get for vsanName.3.

SYNTAX Clause

The SYNTAX clause describes the format of the information, or value, that is returned when you monitor or set information in a MIB.

The Cisco UCS compatible MIBs are defined with the SNMPv2 Structure of Management Information version 2 (SNMPv2-SMI) defined in RFC 1902. Some examples of SNMPv2-SMI syntax are as follows:

• Counter32—A nonnegative integer that increases until it reaches some maximum value. After reaching the maximum value, it resets to zero. For example, when the variable ifInOctets contains counter32, it counts the number of input octets on an interface.
• Gauge32—A nonnegative integer that increases until it reaches some maximum value. After reaching the maximum value, it stays fixed. There is no reset.
• Counter64—A nonnegative 64-bit integer that increases until it reaches some maximum value. After reaching the maximum value, it resets to zero. Counter64 is used for MIB objects that can reach high values in a short period of time For example, Counter64 can be used as a packet counter for a Gigabit Ethernet port.
• Integer32—An integer from -2³² to 2³²-1.
• IPAddress—An octet string that represents an IP address. For example, the variable hostConfigAddr carries the IP address of the host that provided the host configuration file.
• Timeticks—A nonnegative integer that counts the hundredths of a second that have elapsed since an event. For example, the variable loctcpConnElapsed provides the length of time that a TCP connection has been established.

MAX-ACCESS Clause

The MAX-ACCESS clause identifies the maximum access level for the associated MIB object. This clause represents one of the following five states:

• read-create—You can read, modify, or create objects as rows in a table.
• read-write—You can read or modify this object.
• read-only—You can only read this object.
• accessible-for-notify—You cannot read or write to this object. SNMP notifications send this object as part of their event information.
• not-accessible—You cannot read or write to this object. Table indices are typically objects that are not accessible.

AGENT-CAPABILITY Files

In SNMP, capabilities files provide implementation details for the associated MIB. These files, called AGENT-NAME-CAPABILITY, list supported conformance groups and any deviations from the MIB as implemented in the associated software version.

For example, the CISCO-AAA-SERVER-CAPABILITY file provides the implementation details for the CISCO-AAA-SERVER-MIB, as implemented in Cisco UCS Manager.

Note	Capabilities files may have implementation details for more than one software release. You need to match your software release to the corresponding AGENT-CAPABILITIES clause in this file.