Cisco AJ732A - MDS 9134 Fabric Switch User manual

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Cisco MDS 9000 Family MIB Quick Reference
Text Part Number: OL-18087-01
February, 2009
This document describes the private, or local, Management Information Base (MIB) files for the Cisco
MDS 9000 Family of multilayer directors and fabric switches. The Cisco MIB files are provided with
all Cisco MDS NX-OS and SAN-OS software releases. The MIB files contain variables that can be set
or read to provide information about network devices and interfaces.
This document provides the following information:
•MIBs and Network Management, page 1
•About Cisco MIB Files, page 7
•Accessing and Downloading Cisco MIB Files, page 9
•MIBs Supported by Release in the Cisco MDS 9000 Family, page 10
•Cisco-Specific MIBs Supported in the Cisco MDS 9000 Family, page 20
•Supported Notifications, page 51
•Understanding the ENTITY-MIB and Extensions, page 54
•Extending the IF-MIB, page 55
MIBs and Network Management
The Cisco MDS 9000 Family MIB Quick Reference lists Cisco proprietary MIBs as well as many other
Internet Engineering Task Force (IETF) standard MIBs. These standard MIBs are defined in documents
called Requests for Comments (RFCs). To find specific MIB information, you must examine the Cisco
proprietary MIB structure and related IETF-standard MIBs supported by the Cisco MDS 9000 Family.
From the perspective of a network manager, network management takes place between two major types
of systems: those in control, called managing systems, and those observed and controlled, called managed
systems. The most common managing system is called a network management system (NMS). Managed
systems can include hosts, servers, or network components such as switches or intelligent repeaters.
CiscoWorks is an example of an NMS.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
To promote interoperability, cooperating systems must adhere to a common framework and a common
language, called a protocol. In the Internet-standard management framework, that protocol is the Simple
Network Management Protocol (SNMP).
The exchange of information between managed network devices and a robust NMS is essential for
reliable performance of a managed network. Because some devices have a limited ability to run
management software, most of the computer processing burden is assumed by the NMS. The NMS runs
the network management applications, such as Fabric Manager, that present management information to
network managers and other users.
In a managed device, specialized low-impact software modules, called agents, access information about
the device and make it available to the NMS. Managed devices maintain values for a number of variables
and report those, as required, to the NMS. For example, an agent might report such data as the number
of bytes and packets sent or received by the device 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, anything that an agent can access and report back to the NMS. All
managed objects are contained in the MIB, which is a database of the managed objects.
An NMS can control a managed device by sending a request to an agent of that managed device,
requiring the device to change the value of one or more of its variables. The managed devices can
respond to requests such as set or get. The NMS uses the set request to control the device. The NMS
uses the get requests to monitor the device. The set and get requests are synchronous events, meaning
the NMS initiates the activity, and the SNMP agent responds.
The managed device can send asynchronous events, or SNMP notifications, to the NMS to inform the
NMS of some recent event. SNMP notifications (traps or informs) are included in many MIBs and help
to alleviate the need for the NMS to frequently send get requests to the managed devices.
Accessing MIB Variables Through SNMP
You can access the Cisco MIB variables through SNMP. The SNMP system consists of three parts:
SNMP manager, SNMP agent, and MIB. You can compile Cisco MIBs with your network management
software. If SNMP is configured on a device, the SNMP agent responds to MIB-related queries sent by
the NMS.
Table 1 describes the SNMP operations.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
SNMP has been updated twice since its inception. SNMPv1 is the initial version of the protocol.
SNMPv2 added support for 64-bit counters, and SNMPv3 added robust security for access,
authentication, and encryption of managed data.
SNMP Traps and Informs
You can configure the Cisco MDS 9000 Family switch to send notifications to SNMP managers when
particular events occur. You can send these notifications as traps or inform requests. 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 request
acknowledges the message with an SNMP response. If the sender never receives a response, the inform
request can be sent again. Thus, informs are more likely to reach their intended destinations.
Notifications may contain a list of MIB variables or varbinds that clarify the status being relayed by the
notification. The list of varbinds associated with a notification is included in the notification definition
in the MIB. In the case of standard MIBs, Cisco has enhanced some notifications with additional
varbinds that further clarify the cause of the notification. See the “Extending the IF-MIB” section on
page 55 for an example of this in the IF-MIB.
Table 1 SNMP Operations
Operation Description
get-request Retrieves a value from a specific variable.
get-next-request Retrieves the value following the named variable. Often used to retrieve variables
from within a table.1
1.With this operation, an SNMP manager does not need to know the exact variable name. A sequential search finds the next variable
from within the MIB.
get-bulk2
2.The get-bulk and inform commands are not a part of SNMPv1.
Retrieves large blocks of data, such as multiple rows in a table, which would
otherwise require the transmission of many small blocks of data.
set-request Stores a value in a specific variable.
response Replies to the above commands sent by an NMS and to the informs sent by an
agent.
trap Sends an unsolicited message by an SNMP agent to an SNMP manager indicating
that some event has occurred.
inform2Sends an unsolicited message by an SNMP agent to an SNMP manager indicating
that some event has occurred. Differs from a trap in that an acknowledgement is
required from the manager.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Use the SNMP-TARGET-MIB to obtain more information on trap destinations and inform requests.
Refer to the Cisco MDS 9000 Family CLI Configuration Guide for more information on configuring traps
and informs.
Note Notifications must be enabled through SNMP, Fabric Manager, or the CLI. Refer to the Cisco MDS 9000
Family CLI Configuration Guide.
Interpreting the MIB Structure
A MIB presents the 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. Understanding these concepts is fundamental to
interpreting the management information provided by the MIB.
This section provides the following information:
•Object Identifiers, page 4
•Tables, page 5
•SYNTAX Clause, page 6
•MAX-ACCESS Clause, page 6
•AGENT-CAPABILITIES, page 7
Object Identifiers
The MIB structure is logically represented by a tree hierarchy. The root of the tree is unnamed and splits
into three main branches: Consultative Committee for International Telegraph and Telephone (CCITT),
International Organization for Standardization (ISO), and joint ISO/CCITT.
These branches and those that fall below each category have short text strings and integers to identify
them. Text strings describe object names, while integers allow computer software to create compact,
encoded representations of the names.
Each MIB variable is assigned an object identifier. The 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 object identifier for tftpHost is
iso.org.dod.internet.private.enterprise.cisco.workgroup products.stack group.tftp group.tftpHost or
.1.3.6.1.4.1.9.5.1.5.1. The last value is the number of the MIB variable tftpHost.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
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 (for example, sysUpTime.0).
A MIB also can 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 device. Because devices
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 (for example,
ifOperStatus.2 reports the operational state for interface number 2).
Each object in a table is constructed with a set of clauses defined by the SMI. These clauses include the
SYNTAX clause, MAX-ACCESS clause, STATUS clause, and DESCRIPTION clause.
An excerpt of the information in the VSAN table (known as vsanTable) from CISCO-VSAN-MIB
follows:
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 example, vsanTable contains two variables: vsanIndex and vsanName. (There are more values in
the actual vsanTable.) The index for this table is the ID of the VSAN, or vsanIndex. With nnumber of
VSANs configured, nrows 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.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
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 MDS 9000 Family 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 rolls over to zero. For example, the variable ifInOctets, with a
Counter32 syntax, 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 (no roll over).
•Counter64—A nonnegative 64-bit integer that increases until it reaches some maximum value. After
reaching the maximum value, it rolls back to zero. Counter64 is used for MIB objects that can reach
high values in a short period of time (for example, a packet counter for a Gigabit Ethernet port).
•Integer32—An integer from -232 to 232-1.
•IPAddress—An octet string that represents an IP address. For example, the variable hostConfigAddr
indicates the IP address of the host that provided the host configuration file for a device.
•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 can represent one of the following five states: read-create, read-write, read-only,
accessible-for-notify, and not-accessible.
•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 can 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.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
AGENT-CAPABILITIES
In SNMP, capabilities files provide implementation details for the associated MIB. These files, called
AGENT-CAPABILITIES, list supported conformance groups and any deviations from the MIB as
implemented in the associated software version. For instance, the
CISCO-AAA-SERVER-CAPABILITY provides the implementation details for the
CISCO-AAA-SERVER-MIB, as implemented in the Cisco MDS NX-OS or SAN-OS.
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.
About Cisco MIB Files
The Cisco MDS 9000 Family MIB files can be obtained by File Transfer Protocol (FTP) from
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml, under Cisco Storage Networking.
Cisco MIB files are a set of objects that are private extensions to the IETF standard MIB II. MIB II is
documented in RFC 1213, Management Information Base for Network Management of TCP/IP-based
Internets: MIB-II. Portions of MIB-II have been updated since RFC 1213. See the IETF website
http://www.ietf.org for the latest updates to this MIB.
If your NMS cannot get requested information from a managed device, such as a Cisco switch, the MIB
that allows that specific data collection might be missing. Typically, if an NMS cannot retrieve a
particular MIB variable, either the NMS does not recognize the MIB variable, or the agent does not
support the MIB variable. If the NMS does not recognize a specified MIB variable, you might need to
load the MIB into the NMS, usually with a MIB compiler. For example, you might need to load the Cisco
private MIB or the supported RFC MIB into the NMS to execute a specified data collection. If the agent
does not support a specified MIB variable, you must find out what version of system software you are
running. Different software releases support different MIBs.
Note Cisco and IETF MIBs are updated frequently. You should download the latest MIBs from
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml whenever you upgrade your Cisco
MDS NX-OS or SAN-OS.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Cisco MIB File Directories
Cisco MIB files are organized into two directories: SNMPv1-SMI MIBs are in the SNMPv1 directory,
and SNMPv2-SMI MIBs are in the SNMPv2 directory. The list of supported MIBs for the Cisco MDS
9000 Family is available at:
ftp://ftp-sj.cisco.com/pub/mibs/supportlists/mds9000/MDS9000MIBSupportList.html
Cisco also includes supported IETF-standard MIBs at this website. Use this support list to access and
download the individual MIB files.
MIB Loading Order
Many MIBs use definitions that are defined in other MIBs. These definitions are listed in the IMPORTS
section near the top of the MIB.
For example, if MIB B imports a definition from MIB A, some MIB compilers require you to load
MIB A prior to loading MIB B. If you get the MIB loading order wrong, you might get an error message
about what was imported, claiming it is undefined or not listed in IMPORTS. If you receive an error,
look at the loading order of the MIB definitions from the IMPORTS of the MIB. Make sure that you have
loaded all the preceding MIBs first.
Here is a list of MIBs from which many other MIBs import definitions. The MIBs are listed in the order
in which you should load them:
•SNMPv2-SMI.my
•SNMPv2-TC.my
•SNMPv2-MIB.my
•RFC1213-MIB.my
•IF-MIB.my
•CISCO-SMI.my
•CISCO-TC.my
•CISCO-ST-TC.my
•CISCO-VSAN-MIB.my
•ENTITY-MIB.my
If you load the MIBs in this order, you can eliminate most of your load-order definition problems. You
can load most other MIBs (those not listed here) in any order.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Accessing and Downloading Cisco MIB Files
You can access the Cisco MIB files in either of the following ways:
•Using HTTP to Access and Download the MIB Files from CCO, page 9
•Using Passive FTP to Access and Download the MIB Files, page 10
Note You can also access and download Cisco MIB files using the SNMP Object Navigator tool located at the
following site: http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en. You can use this tool
to translate SNMP object identifiers (OIDs) into object names, search object names, and descriptions,
browse OID trees, and download MIB files.
Using HTTP to Access and Download the MIB Files from CCO
To access MIB files using your Web browser, follow these steps:
Step 1 Enter the following URL in the Address field:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Step 2 Select Cisco Storage Networking.
Step 3 Select Cisco MDS 9000 Family.
Step 4 Select and save each MIB you need to download from the Cisco MDS 9000 Family MIB support list.
If you are using Internet Explorer, you might need to enable passive FTP. To enable passive FTP, follow
these steps:
Step 1 Open Internet Explorer, and click Tools > Internet Options.
Step 2 Click the Advanced tab on the top of the window.
Step 3 Scroll down, and check the Use Passive FTP [for firewall and DSL modem compatibility] check box.
Step 4 Click OK to save changes.

Send documentation comments to mdsfeedbac[email protected]
Americas Headquarters:
© <2009> Cisco Systems, Inc. All rights reserved.
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Using Passive FTP to Access and Download the MIB Files
To access MIB files using passive FTP, you must know the names of the MIB files that you want to
download. See “Using HTTP to Access and Download the MIB Files from CCO” section on page 9 to
access the Cisco MDS 9000 Family support list for the names of supported MIBs. These steps assume
that your passive FTP utility has UNIX-like commands.
To download MIB files with passive FTP, follow these steps:
Step 1 Access ftp.cisco.com using passive FTP.
Step 2 Log in with your Cisco.com username and password, or as anonymous, with your e-mail address.
Step 3 Enter cd /pub/mibs/v2/ to change directories.
Step 4 Use the get command to copy the desired files to your local system.
Step 5 Use the quit command to exit passive FTP.
MIBs Supported by Release in the Cisco MDS 9000 Family
The Cisco MDS 9000 Family supports several standard MIBs and Cisco-specific MIBs. For more
information about IETF-standard MIBs in the following tables, refer to http://www.ietf.org. For more
information about Cisco-specific MIBS, see the“Cisco-Specific MIBs Supported in the Cisco MDS 9000
Family” section on page 20.
The Cisco MDS 9000 Family MIB Quick Reference Guide applies to Cisco NX-OS Release 4.1(3) and
earlier Cisco MDS SAN-OS releases.
Note As of NX-OS Release 4.1(1b), SAN-OS has been changed to NX-OS. References to SAN-OS releases
before 4.1(1b) still apply.