This document describes the Cisco Systems private, or local, Management Information Base (MIB) for Cisco Internetwork Operating System (Cisco IOS) Release 11.2. The Cisco MIB is provided with all Cisco software releases and with CiscoWorks router management software. The MIB file contains variables that can be set or read to provide information on network devices and interfaces.
This document is intended for network information system (NMS) managers.
The Cisco MIB is a set of variables that are private extensions to the Internet standard MIB II and many other Internet standard MIBs. MIB II is documented in RFC 1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II.
The Cisco MIB is described by a number of MIB files, which can be obtained by File Transfer Protocol (FTP) from the Cisco server. The listing of Cisco MIB variables in those files is identical to the listing in this document.
Understanding MIBs
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 routers or intelligent repeaters.
To promote interoperability, cooperating systems must adhere to a common framework and a common language, called a protocol. In the Internet Network 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 CiscoWorks or CiscoView, 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 in and out of the device, or the number of broadcast messages sent and received. In the Internet Network Management Framework, 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 Management Information Base (MIB), a database of the managed objects.
An NMS can control a managed device by sending a message 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 commands such as set or get commands. The set commands are used by the NMS to control the device. The get commands are used by the NMS to monitor the device.
The Cisco Management Information Base (MIB) User Quick Reference lists the MIB variables that are proprietary to Cisco devices. However, many other Internet-standard MIBs are supported by Cisco agents. These standard MIBs are defined in documents called Requests for Comments (RFCs). (For information on the RFC MIBs supported by Cisco, refer to the section "Cisco-Supported RFC MIBs" later in this chapter.) To find specific MIB information, you must examine the Cisco proprietary MIB structure and the standard RFC MIBs supported by Cisco.
If your NMS is unable to get requested information from a managed device such as a Cisco router, 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 by means of a MIB compiler. For example, you might need to load the Cisco 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 Cisco IOS or system software you are running. Different MIBs are supported in different software releases.
Use this document to determine whether your version of software supports the specified MIB variable. (See the appendix "List of MIBs Supported by Cisco Software Releases.") Or, you might want to use this document to see what variables are available for a given software release. As you use this document, read the descriptions of the variables to learn what they are and what they do. Check the Access or Max-Access type to learn what operations, such as reading gets or writing sets, can be performed on a particular MIB variable. Check the Syntax type to determine the data type for the MIB variable. Some variables provide textual information (for example, syntax of DisplayString), while others provide numeric information (for example, syntax of Integers or Counters). Once you identify a needed MIB variable, you can easily load the MIB file into your NMS. To learn how to access a Cisco MIB file, refer to "Accessing Cisco MIB Files" later in this chapter.
Cisco Systems also supports many MIB variables developed by other vendors. Refer to "Accessing Other-Vendor MIB Variables Supported by Cisco" for more information.
You can obtain the files that describe the MIBs supported by Cisco products using anonymous FTP or the World Wide Web (WWW) to access Cisco Connection Online (CCO), formerly Cisco Information Online (CIO).
Via FTP, use the ftp ftp.cisco.com command. Log in with the username anonymous, and enter your e-mail name when prompted for the password. Use the cd pub/mibs command to go to the directory that contains the MIB files, and then issue the get README command to obtain the README file containing a description of the Cisco Systems public MIB area. To determine the MIBs supported for each Cisco product, go to the supportlists subdirectory where you will find directories for all Cisco products. Refer to the supportlist.txt file in each directory, as necessary, to determine the MIBs supported on that platform, by Cisco IOS release, and the location of the desired MIB file. Cisco IOS MIB files are in the v1 and v2 subdirectories. You can then use the FTP command get mib-filename to retrieve the MIB file.
A description of issues you might encounter when loading Cisco MIBs into your NMS is located at ftp://www.cisco.com/pub/mibs/app_notes/mib-compliers.
To access CCO via the WWW, use the URL: http://www.cisco.com/public/mibs or ftp://www.cisco.com/pub/mibs.
Other-vendor MIBs supported on Cisco products can be retrieved from CCO or via anonymous FTP as described in the section "Accessing Cisco MIB Files" earlier in this chapter.
Cisco supports Novell's IPX (2.5), NLSP, and RIPSAP (22.0) MIBs, among others.
The Cisco MIB variables are accessible via the Simple Network Management Protocol (SNMP), which is an application-layer protocol designed to facilitate the exchange of management information between network devices. The SNMP system consists of three parts: SNMP manager, SNMP agent, and MIB.
Instead of defining a large set of commands, SNMP places all operations in a get-request, get-next-request, get-bulk-request, and set-request format. For example, an SNMP manager can get a value from an SNMP agent or store a value in that SNMP agent. The SNMP manager can be part of a network management system (NMS), and the SNMP agent can reside on a networking device such as a router. You can compile the Cisco MIB with your network management software. If SNMP is configured on a router, the SNMP agent can respond to MIB-related queries being sent by the NMS.
An example of an NMS is the CiscoWorks network management software. CiscoWorks uses the Cisco MIB variables to set device variables and to poll devices on the internetwork for specific information. The results of a poll can be graphed and analyzed to help you troubleshoot internetwork problems, increase network performance, verify the configuration of devices, monitor traffic loads, and more.
As shown in Figure 1-1, the SNMP agent gathers data from the MIB, which is the repository for information about device parameters and network data. The agent also can send traps, or notifications of certain events, to the manager. The Cisco trap file, mib.traps, which documents the format of the Cisco traps, is available on the Cisco host ftp.cisco.com.
Figure 1-1: SNMP Network
The SNMP manager uses information in the MIB to perform the operations described in Table 1-1.
Table 1-1: SNMP Manager Operations
| Operation
| Description
|
|---|
| get-request
| Retrieve a value from a specific variable.
|
| get-next-request
| Retrieve the value following the named variable. Often used to retrieve variables from within a table1.
|
| get-response
| The reply to a get-request, get-next-request, get-bulk-request, and set-request sent by an NMS.
|
| get-bulk-request
| Similar to get-next-request, but fill the get-response with up to max-repetition number of get-next interactions.
|
| set-request
| Store a value in a specific variable.
|
| trap
| An unsolicited message sent by an SNMP agent to an SNMP manager indicating that some event has occurred.
|
1
With this operation, an SNMP manager does not need to know the exact variable name. A sequential search is performed to find the needed variable from within the MIB.
The MIB structure is logically represented by a tree hierarchy. (See Figure 1-2.) 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. For example, the Cisco MIB variable authAddr is an object name and is denoted by number 5, which is listed at the end of its object identifier number 1.3.6.1.4.1.9.2.1.5.
The object identifier in the Internet MIB hierarchy is the sequence of numeric labels on the nodes along a path from the root to the object. The Internet standard MIB is represented by the object identifier 1.3.6.1.2.1. It also can be expressed as iso.org.dod.internet.mgmt.mib. (See Figure 1-2.)
Figure 1-2:
Internet MIB Hierarchy
Cisco MIB
The private Cisco MIB is represented by the object identifier 1.3.6.1.4.1.9, or iso.org.dod.internet.private.enterprise.cisco. The Cisco MIB includes the following subtrees: local (2), temporary (3), and, ciscoMgmt (9).
The local subtree contains MIB objects defined prior to Cisco Internetwork Operating System (Cisco IOS) Release 10.2. These MIB objects implemented the SNMPv1 Structure of Management Information (SMI). Beginning with Cisco IOS Release 10.2, however, Cisco MIBs are defined according to the SNMPv2 SMI. MIBs defined with SNMPv2 are placed in the ciscoMgmt subtree. (See Figure 1-3.) MIBs currently defined in the local subtree are being gradually deprecated by Cisco and replaced with new objects defined in the ciscoMgmt subtree. For example, the TCP group that was formerly in the local group has been deprecated and replaced with a new Cisco TCP group in the ciscoMgmt tree.
Figure 1-3: Cisco Private MIB Hierarchy
In Figure 1-3, the Local Variables group is identified by 2; the system subgroup, called lsystem, is identified by 1; and the first variable is romId with a value of 1. Therefore, the variable romId has a value of 1.3.6.1.4.1.9.2.1.1.0. The appended instance identifier 0 indicates that 1.3.6.1.4.1.9.2.1.1.0 is the one and only instance of romId.
In this document, each group of Cisco MIB variables is accompanied by an illustration that indicates the specific object identifier for each variable.
For example, in Figure 1-4 the object identifier 1.3.6.1.4.1.9.2.1 at the top of the illustration indicates the labeled nodes. The last value is the number of the Cisco MIB variable. For example, the MIB variable hostConfigAddr is indicated by the number 51. The object identifier for hostConfigAddr is iso.org.dod.internet.private.enterprise.cisco.local variables.system group.hostConfigAddr or 1.3.6.1.4.1.9.2.1.51.
Figure 1-4:
Object Identifier Example for a Cisco MIB Variable
Tables
When network management protocols use names of MIB variables in messages, each name has a suffix appended. This suffix is called an instance identifier. For simple variables, the instance identifier 0 refers to the instance of the variable with that name. A MIB also can contain tables of related variables.
Following is an excerpt of the information on the IP Routing table (known as lipRoutingTable) from the associated MIB file:
lipRoutingTable OBJECT-TYPE
SYNTAX SEQUENCE OF LIpRouteEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A list of IP routing entries."
::= { lip 2 }
lipRouteEntry OBJECT-TYPE
SYNTAX LIpRouteEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A collection of additional objects in the
cisco IP routing implementation."
INDEX { ipRouteDest }
::= { lipRoutingTable 1 }
LIpRouteEntry ::=
SEQUENCE {
locRtMask
IpAddress,
locRtCount
INTEGER,
}
The local IP Routing table, lipRoutingTable, is described in Table 1-2. The lipRoutingTable contains two variables: locRtMask and locRtCount. The index for this table is the destination address of the IP route, or ipRouteDest. If there are n number of routes available to a device, there will be n rows in the IP Routing table.
In Table 1-2, the route with the destination IP address of 131.104.111.1 has an IP Routing table network mask of 255.255.255.0. The number of parallel routes within the routing table is 3.
Table 1-2: IP Routing
| ipRouteDest
| locRtMask
| locRtCount
|
|---|
| 131.104.111.1
| 255.255.255.0
| 3
|
| 133.45.244.245
| 255.255.255.0
| 1
|
Typically, an instance identifier might be a unique interface number or a 0, as described earlier with the romId example. An instance identifier can also be an IP address. For example, to find the network mask for the route with a destination address of 131.104.211.243, use the variable locRtMask with an instance identifier of 131.104.211.243. The format is locRtMask.131.104.211.243.
In this document, when variables belong to a table, they are listed in the section describing the table. The following tag is used to indicate the end of a table:
End of Table
All variables before this tag are part of the table.
Local Variables
The Local Variables section pertains to all Cisco devices and contains the following groups, which are presented in alphabetical order. (See Figure 1-3.)
- Pertains to the Flash memory used to store, boot, and write system software images. Includes information such as Flash memory size and contents. You can invoke operations by setting MIB variables to perform such tasks as erasing Flash memory and transferring a Flash memory file to a Trivial File Transfer Protocol (TFTP) server. The Flash group supports the Cisco 7000 series and Cisco 7500 series. The Flash group in Local Variables has been deprecated and replaced by the Cisco Flash group found in CiscoMgmt.
- Provides information on Cisco device interfaces, such as traffic statistics, line status, average speed of input and output packets, and error checking. This group includes Fast Serial Interface Processor (FSIP) variables.
- Internet Protocol (IP) group
- Provides information about devices running IP. Includes information such as how and from whom an interface obtained its address, Internet Control Message Protocol (ICMP) messages, and number of packets lost.
- IP Accounting group
- IP Checkpoint Accounting group
- System group
- Provides information on system-wide parameters for Cisco devices, such as software version, host name, domain name, buffer size, configuration files, and environmental statistics.
- Provides information about terminal services, such as number of physical lines, line status, line type, line speed, type of flow control, and type of modem.
- Transmission Control Protocol (TCP) group
- Provides statistics on the number of input and output bytes and packets for TCP connections. The local TCP group has been deprecated and replaced with a new TCP group in ciscoMgmt, which provides more functionality.
ciscoMgmt Variables
The ciscoMgmt subtree consists of the following variables:
- Binary Synchronous Communication (BSC) group
- Provides configuration and operational information for Cisco's Binary Synchronous Communications (BSC) implementation. The following two entities are managed: BSC ports (serial interfaces), and BSC control units (stations on a port).
- Blocked Serial Tunnel (BSTUN) group
- Provides configuration and operational information about Cisco's blocked serial tunnel (BSTUN) implementation. Four entities are managed: BSTUN global entry, BSTUN group table, BSTUN port table, and BSTUN route table.
- Channel Interface Processor (CIP) group
- Specifies the MIB module for objects used to manage the Cisco CIP card.
- Cisco CIP Channel Systems Network Architecture (CSNA) group
- Provides information on the configuration of the Channel Interface Processor (CIP) Channel Systems Network Architecture (CSNA) feature. In eight tables, three pieces of information are provided: configuration of I/O device addresses of communication controllers, information regarding connections between the virtual telecommunications access method (VTAM) software and internal adapters, and the number of sessions allowed between the VTAM and internal adapter.
- Provides configuration information on the internal (virtual) LAN and internal (virtual) adapter components of the CIP CSNA feature.Within the LAN configuration are entries for the type of LAN and the bridging protocol. Within the adapter configuration are entries for the media access control (MAC) address and the Systems Network Architecture (SNA) name used for alerts.
- Manages the TCP/IP protocol stack running on the Channel Interface Processor (CIP) card. Only the TCP/IP offload feature makes use of this MIB. The read-only values allow statistics and status for every instance of IP, TCP, User Datagram Protocol (UDP), and ICMP protocol stacks to be viewed.
- Cisco Configuration Management group
- Represents a model of configuration data that exists in the router's running configuration, the terminal configuration, the local configuration, and the remote configuration.
- Cisco Data Link Switching (DLSw) group
- Manages the DLSw, adjacent DLSw partners, interfaces on which DLSw is active, local and remote resources, and established circuits.
- Cisco Discovery Protocol (CDP) group
- Provides the MIB module for management of the Cisco Discovery Protocol (CDP) in Cisco devices.
- Cisco DownStream Physical Unit (DSPU) group
- Contains the information necessary for the definition and management of DSPU objects: global DSPU node information, LU pool class information, pooled LU information, upstream and downstream PU node information, upstream and downstream LU information, and local SAP information.
- Cisco Environmental Monitor group
- Provides the status of the Environmental Monitor on those devices that support one.
- Provides support for the Dual Flash Bank feature introduced in Cisco IOS Release 10.3(4). The Cisco Flash group is also supported in Release 10.2.
- Cisco Integrated Channel Service Unit/Data Service Unit (CSU/DSU) Group
- The integrated CSU/DSU group is used with the Cisco 2524 and Cisco 2525 products, and is for T1 and switched 56-kbps interfaces. It enables network managers to retrieve line statistics and CSU/DSU configuration data.
- Cisco Integrated Services Digital Network (ISDN) group
- Provides the status of the ISDN Interfaces on the routers. The ISDN MIB was introduced in Release 10.3(3).
- Cisco Interface Queue group
- Provides detailed access to custom and priority queuing information. This information was previously available only via the show queue EXEC command.
- Cisco IP Encryption group
- Used to manage IP encryption.
- Cisco LAN Emulation (LANE) Broadcast-and-Unknown Server group
- Manages LANE broadcast-and-unknown servers.
- Cisco LANE Configuration group
- Manages LANE configuration servers in Cisco devices.
- Manages LANE service in Cisco devices.
- Cisco Modem Management group
- Used to manage modems in the Cisco AS5200 universal access server.
- Provides users with the ability to initiate a ping --an Internet Control Message Protocol (ICMP) echo request--from the Cisco device to a specified destination address.
- Cisco Remote Source-Route Bridging (RSRB) group
- Provides information about the attributes of the local-remote RSRB peer relationship. The following three entities are managed: virtual rings, remote peers, and associated Token Rings.
- Cisco Repeater (ciscoRptr) group
- Provides standard repeater (hub) features that are not in RFC 1516. The objects in this MIB support features such as link-test, auto-polarity, and source-address control, and the MDI/MDI-X switch status. The Cisco Repeater MIB was introduced in Release 10.3(3).
- Cisco Round Trip Time (RTT) Monitoring group
- Provides configuration and operational information for Round Trip Time (RTT) monitoring of a list of targets, using a variety of protocols.
- Cisco SDLLC Conversion group
- Provides read-only configuration and operational information on Cisco's implementation of SDLC-to-Logical Link Control, type 2 (LLC2) media translation. The SDLLC MIB provides a table entry for each serial interface and SDLC address pair, and includes information such as front-end processor (FEP) MAC addresses, SDLC station addresses, and Token Ring numbers on LLC2 stations.
- Cisco Serial Tunnel (STUN) group
- Provides configuration and operational information on Cisco's serial tunnel (STUN) implementation. The following four entities are managed: global STUN information, STUN groups, STUN ports, and STUN routes
- Cisco Systems Network Architecture (SNA) Logical Link Control (LLC) group
- Manages the LLC2 stack that runs on a Channel Interface Processor (CIP) card. The CIP card provides the SNA gateway to an IBM mainframe via a channel connection from the router.
- Cisco Snapshot Routing group
- Provides access to the Cisco snapshot routing support and is present in all router-based products.
- Snapshot routing provides easy solutions to two common problems:
- Need to configure static routes for dial-on-demand routing (DDR) interfaces
- Overhead of periodic updates for routing protocols to remote branch offices over dedicated serial lines
- When snapshot routing is configured on an interface, normal routing updates can be sent across the interface for a short time (determined by the user). When this user-configured period of activity has elapsed, the routing updates are suspended, and the routes known to the snapshot interface are locked, putting the interface into a "frozen period." The duration of this period is also user configurable. During this time, changes in network topology are typically not transmitted across the snapshot interface, although some network protocols provide the capability to transmit changes.
- Cisco SYSLOG Message group
- Used to gather system log (SYSLOG) messages generated by Cisco IOS software, which generates a variety of textual messages. The Cisco IOS software can be configured to send messages to a SYSLOG server. With the Cisco SYSLOG Message MIB, these same messages can also be retrieved via the SNMP.
- Cisco Transmission Control Protocol (ciscoTCP) group
- Provides statistics on the number of input and output bytes and packets for TCP connections; ciscoTCP, however, provides more functionality over its counterpart in the Local Variables subtree.
- Manages configuration of the TCP offload feature. This group is made up of one table entry that shows configuration information such as path, device, host name, router name, application programming interface (API) host application, and API router application.
- Cisco TN3270 Server group
- Used to manage TN3270 servers.
- Cisco Virtual Integrated Network Service (VINES) group
- Pertains to devices running the VINES protocol. Includes information such as total number of input and output packets, number of packets with errors, and number of packets with ARP and Routing Table Protocol (RTP) requests and replies. Also includes tables of routes and neighbors. This MIB incorporates objects from the Cisco VINES command line interface, and was influenced by the Banyan VINES MIB. The ciscoVINES MIB provides VINES routing information with enhanced functionality compared to its predecessor located in the Temporary Variables subtree.
- Qualified Logical Link Control (QLLC) group
- The QLLC is a data link protocol defined by IBM that allows SNA data to be transported across X.25 networks. The QLLC MIB includes a managed entity, called a link station. The link station includes objects to configure and monitor logical connections.
- QLLC SNA Conversion group
- Provides data link layer support for SNA communication.
Temporary Variables
This section is equivalent to the experimental space defined by the Structure of Management Information (SMI). These variables are subject to change for each Cisco IOS software release.
Temporary variables consists of the following groups, which are presented in alphabetical order. (See Figure 1-3.)
- Pertains to devices running the AppleTalk protocol. Includes information such as total number of input and output packets, number of packets with errors, and number of packets with Address Resolution Protocol (ARP) requests and replies.
- Pertains to hardware information about Cisco devices. Includes information such as the types of cards used by the device, the hardware version of the cards, and the number of slots in the chassis. The cardTableIfIndex table, introduced in Cisco IOS Release 10.3, provides logical mapping between the device interface and a card's presence in the chassis. The variables in this table support only the Cisco 4000, Cisco 4500, Cisco 7000, Cisco 7010, Cisco 7200, Cisco 7505, Cisco 7507, and Cisco 7513. By implementing the new MIB table in supported configurations, you can discover statistics about the card. The new MIB table provides significant solutions for CiscoWorks and CiscoView users.
- Pertains to devices running the DECnet protocol. Includes information such as hop count, host name, total packets received and sent, and number of packets with header errors.
- Pertains to devices running the Novell protocol. Includes information such as total number of input and output packets, number of packets with errors, and number of packets with service access point (SAP) requests and replies.
- Virtual Integrated Network System (VINES) group
- Pertains to devices running the Banyan VINES protocol. Includes information such as total number of input and output packets, number of packets with errors, and number of packets with Internet Control Message Protocol (ICMP) requests and replies. The variables in this group have been deprecated and replaced with the Cisco VINES (cv) group, found in the ciscoMgmt tree.
- Xerox Network Systems (XNS) group
- Pertains to devices running the XNS protocol. Includes information such as number of packets forwarded, total number of input packets, and total number of packets with errors.
Terminology
This section explains the syntax and access type categories used to describe each variable. For details on SNMPv1 syntax, refer to RFC 1155; refer to RCF 1442 for SNMPv2 syntax.
Syntax
The syntax describes the format of the information, or value, that is returned when you monitor or set information in a device with a MIB variable.
Note Some MIBs are defined with the
SNMPv1 SMI, while others are defined with the SNMPv2 SMI. The two versions have slightly different syntaxes. For example, an SNMPv1 "Counter" is a "Counter32" in SNMPv2.
The syntax can be any one of the following categories:
- Syntax: Octet string (SIZE (0-20)). A 20-octet binary string, containing a standard ATM Forum address, or the zero-length string, which indicates the absence of an address. For LAN emulation (LANE) purposes, the 8-octet address format is not used.
- Syntax: Octet string (SIZE (0-2)). The 2-octet hexadecimal (hex) device address for the device the Systems Network Architecture (SNA) host will use to communicate with the Channel Systems Network Architecture (CSNA) feature on the Channel Interface Processor (CIP).
- The first octet will always be zero for consistency with other CIP MIBs.
- For example, for device address 1C (decimal 28) the 2-octet value is 00:1C.
- Syntax: Integer (0-65535). An integer large enough to hold a virtual channel identifier (VCI).
- Syntax: Integer (0-255). An integer large enough to hold a virtual path identifier (VPI).
- A nonnegative integer that increases until it reaches some maximum value. After reaching the maximum value, it rolls back to zero. For example, the variable locIfipInPkts counts the number of IP protocol input packets on an interface.
- The type of queuing algorithm used on the interface.
- Syntax: Integer. 1 = fifo (first-in, first-out), 2 = priority (priority queuing), 3 = custom (custom queuing), 4 = weightedFair (weighted fair queuing).
- A printable ASCII string. It is typically a name or description. For example, the variable netConfigName provides the name of the network configuration file for a device.
- Syntax: Octet string (SIZE (0-2)). This channel path is a 2-octet value made up of the following values:
|
Path 01-FF
| For a directly attached Enterprise Systems Connection (ESCON) channel or any parallel channel, this value is 01 unless the system administrator has configured another value.
For a channel attached through an ESCON director switch, this value will be the path that, from the router point of view, exits the switch and attaches to the host.
|
| Channel logical address 0-F
| For a directly attached ESCON channel or any parallel channel, this value is 0. If the host is running in logical partition (LPAR) mode, this is the channel logical address associated with the channel and defined in the I/O Configuration Program (IOCP) configuration file used by VTAM. The default for this part of the path argument is 0.
Otherwise, the channel logical address associated with the channel is defined in the IOCP configuration file used by VTAM.
|
| Control unit logical address 0-F
| For a directly attached ESCON channel or any parallel channel, this value defaults to 0. If this value is specified in the IOCP file used by VTAM, then match that value here.
Otherwise, the control unit logical address is specified in the IOCP configuration file's CNTLUNIT statement for the host channel in the CUADD parameter.
|
- For example, for path C7, channel logical address 9, control unit logical address 4, the 2-octet value is C7:94.
Note The ability to create and use IOCP configuration files for VTAM is a prerequisite for using variables that call for a ChannelPath.
- Syntax: Integer. 1 = other (not assigned yet), 2 = na (not applicable), 3 = llc (802.2 Logical Link Control), 4 = sdlc (SDLC), 5 = qllc (QLLC). Represents the type of DLC of an end station, if applicable.
- Syntax: TimeTicks. The value of ciscoDlswUpTime when the event of interest occurred.
- Syntax: Integer. 1 = disabled and 2 = enabled. Represents status information for a particular row in the table.
- Syntax: Integer. 1 = other, 2 = internal (local virtual MAC address), 3 = remote (via DLSw partner), 4 = local (locally attached). Represents the location of an end station related to the managed DLSw node.
- Syntax: Integer of 1, 2, 3, 4, 5, 6, or 7. Represents the source or destination of a configuration change, save, or copy:
|
1 = erase
| Erasing destination (source only).
|
| 2 = running
| Live operational data.
|
| 3 = commandSource
| The command source itself.
|
| 4 = startup
| What the system will use at the next reboot.
|
| 5 = local
| Local nonvolatile RAM (NVRAM) or Flash memory.
|
| 6 = networkTftp
| Network host via Trivial File Transfer.
|
| 7 = networkRcp
| Network host via Remote Copy.
|
- A numeric value. It can be an actual number--for example, the number of lost IP packets on an interface. It also can be a number that represents a nonnumeric value. For example, the variable tsLineType returns the type of terminal services line to the SNMP manager. A 2 indicates a console line; a 3 indicates a terminal line; and so on.
- An integer from -232 to 232-1.
- The variable hostConfigAddr indicates the IP address of the host that provided the host configuration file for a device.
- Syntax: Integer. lfs516(516), lfs635(635), lfs754(754), lfs873(873), lfs993(993), lfs1112(1112), lfs1231(1231), lfs1350(1350), lfs1470(1470), lfs1542(1542), lfs1615(1615), lfs1688(1688), lfs1761(1761), lfs1833(1833), lfs1906(1906), lfs1979(1979), lfs2052(2052), lfs2345(2345), lfs2638(2638), lfs2932(2932), lfs3225(3225), lfs3518(3518), lfs3812(3812), lfs4105(4105), lfs4399(4399), lfs4865(4865), lfs5331(5331), lfs5798(5798), lfs6264(6264), lfs6730(6730), lfs7197(7197), lfs7663(7663), lfs8130(8130), lfs8539(8539), lfs8949(8949), lfs9358(9358), lfs9768(9768), lfs10178(10178), lfs10587(10587), lfs10997(10997), lfs11407(11407), lfs12199(12199), lfs12992(12992), lfs13785(13785), lfs14578(14578), lfs15370(15370), lfs16163(16163), lfs16956(16956), lfs17749(17749), lfs20730(20730), lfs23711(23711), lfs26693(26693), lfs29674(29674), lfs32655(32655), lfs38618(38618), lfs41600(41600), lfs44591(44591), lfs47583(47583), lfs50575(50575), lfs53567(53567), lfs56559(56559), lfs59551(59551), lfs65535(65535).
- The largest size of the INFO field (including the DLC header, but not including any MAC-level or framing octets). The 64 valid values defined by the IEEE 802.1D Addendum are acceptable.
- Syntax: Octet String (SIZE (0 | 6)) for DLSw. Represents an 802 MAC address represented in noncanonical format--that is, the most significant bit will be transmitted first.
- Syntax: Octet String (SIZE (0-16)). Represents a single qualified NetBIOS name, which can include "don't care" and wildcard characters to represent a number of real NetBIOS names. If an individual character position in the qualified name contains a question mark (?), the corresponding character position in a real NetBIOS name is a "don't care." If the qualified name ends in an asterisk (*), the remainder of a real NetBIOS name is a "don't care." An asterisk is considered a wildcard only if it appears at the end of a name.
- Specifies the protocol to be used to perform the timed echo request or response operation.
- Syntax: Integer. Represents the following protocols:
Note All protocols that end in Appl support the Asymmetric Request/Response (ARR) protocol. See the "Cisco RTT Monitoring Group" section in the CiscoMgmt Variables chapter for a complete description of the ARR protocol.
| 1 = notApplicable
| No protocol is defined
|
| 2 = ipIcmpEcho
| Uses echo request or response as defined in RFC 792 for IP networks.
|
| 3 = ipUdpEchoAppl
| Uses the UDP-based echo server.
|
| 4 = snaRUEcho
| Uses the REQECHO and ECHOTEST request/response units (RUs) to a system services control point (SSCP) over an SNA logical unit (LU)-SSCP session.
|
| 5 = snaLU0EchoAppl
| Uses test RUs sent to the echo server over an SNA LU-LU session type 0.
|
| 6 = snaLU2EchoAppl
| Uses test RUs sent to the echo server over an SNA LU-LU session type 2.
|
| 7 = snaLU62Echo
| Uses the native Advanced Peer-to-Peer Networking (APPN) ping known as aping.
|
| 8 = snaLU62EchoAppl
| Uses test RUs sent to the ARR echo server over an SNA LU-LU session type 6.2.
|
| 9 = appleTalkEcho
| Uses echo request or response as defined for AppleTalk networks.
|
| 10 = appleTalkEchoAppl
| Uses the AppleTalk-based echo server.
|
| 11 = decNetEcho
| Uses echo request or response as defined for DECnet networks.
|
| 12 = decNetEchoAppl
| Uses the DECnet-based echo server.
|
| 13 = ipxEcho
| Uses echo request or response as defined for Novell IPX networks.
|
| 14 = ipxEchoAppl
| Uses the Novel IPX-based echo server.
|
| 15 = isoClnsEcho
| Uses echo request or response as defined for ISO Connectionless Network Service (CLNS) networks.
|
| 16 = isoClnsEchoAppl
| Uses the ISO CLNS-based echo server.
|
| 17 = vinesEcho
| Uses echo request or response as defined for VINES networks.
|
| 18 = vinesEchoAppl
| Uses the VINES-based echo server.
|
| 19 = xnsEcho
| Uses echo request or response as defined for XNS networks.
|
| 20 = xnsEchoAppl
| Uses the XNS-based echo server.
|
| 21 = apolloEcho
| Uses echo request or response as defined for Apollo networks.
|
| 22 = apolloEchoAppl
| Uses the Apollo-based echo server.
|
| 23 = netbiosEchoAppl
| Uses the NetBIOS-based echo server.
|
- A string that specifies the address of the target for the RTT operation; a value of RttMonTargetAddress that corresponds to a broadcast address is disallowed.
- The interpretation of this string depends on the type of RTT operation selected, as specified by RttMonProtocol; consequently, this object cannot be created until RttMonProtocol has been created, or must be in the same protocol data unit (PDU).
- Because some addresses might not be unique, this object cannot be used as an index.
- SNA addresses are provided in ASCII, but are converted to EBCDIC.
- Syntax: Octet String. Interpreted as follows, for the specified values of RttMonProtocol:
|
ipIcmpEcho
ipUdpEchoAppl
| 4 octets.
|
| snaRUEcho
| Unused. (The SSCP address is implied.)
|
snaLU0EchoAppl
snaLU2EchoAppl
| N octets. The format is x.y.z. The first x octets are the HOSTNAME. (Alternatively, this could be a PU name defined to transport to the desired HOST). The second y octets are the APPLID, and the last z octets are the MODENAME of the echo server (blank for a MODENAME default). The address will be encoded with a size byte preceding each of the x, y, and z octets, called s. For example, sxsysz as in 0x06CWBC060x07NSPECHO0x00 where HOSTNAME = CWBC06, APPLID = NSPECHO, and MODENAME is defaulted to 8 blanks. MODENAME is either size 0 or 8.
|
snaLU62Echo
snaLU62EchoAppl
| N octets. The format is x.y.z. The first x octets are the LU-NAME, the second y octets are the transaction program name (TP-NAME), and the last z octets are the MODENAME of the echo server. The address will be encoded with a size byte preceding each of the x, y, and z octets, called s. For example, sxsysz (zero size before z for a MODENAME default). The LU-NAME is composed of: 8 bytes "." 8 bytes. The TP-NAME is 1 to 64 bytes. The MODENAME is 8 bytes.
|
appleTalkEcho
appleTalkEchoAppl
| 3 octets. The first 2 octets are the network number, and the last octet is the host number.
|
decNetEcho
decNetEchoAppl
| 2 octets.
|
ipxEcho
ipxEchoAppl
| 10 octets. The first 4 octets are the network number, and the last 6 octets are the host number.
|
isoClnsEcho
isoClnsEchoAppl
| Network service access point (NSAP) address in octets. See "Configuring ISO CLNS" in the Network Protocols Configuration Guide, Part 3.
|
vinesEcho
vinesEchoAppl
| 6 octets. The first 4 octets are the network number, and the last 2 octets are the host number.
|
xnsEcho
xnsEchoAppl
| 10 octets. The first 4 octets are the network number, and the last 6 octets are the host number.
|
apolloEcho
apolloEchoAppl
| 10 octets. The first 4 octets are the network number, and the last 6 octets are the host number.
|
| netbiosEchoAppl
| N octets. The first octet is an ASCII alphabet character, and the last 15 are ASCII alphanumeric characters. The maximum value of N is 16.
|
- Specifies the type of RTT operation to be performed.
- The value echo causes the RTT application to perform a timed echo request/response operation directed at the RttMonTargetAddress.
- The value pathEcho causes the RTT application to perform path discovery to the RttMonTargetAddress; then it performs a timed echo request/response operation directed at each hop along the path. This operation provides two types of information: the path and the time delay along the path.
Note The pathEcho time delay operation is a heuristic measurement because an intermediate hop can forward the different echo request or responses at different rates. Thus the time delay difference between two hops along a path might contain very little true statistical meaning.
- The value fileIO causes the RTT application to write, read, or write and read a file to a preconfigured file server.
- The value script causes the RTT application to execute a preconfigured script.
- Syntax: Integer. 1 = echo, 2 = pathEcho, 3 = fileIO, 4 = script.
- Represents the reset control object.
- When this object is set to reset, the defined reset operation takes place.
- When this object is read (with a get operation), during the reset operation the value reset is returned. At all other times the value ready is returned.
- Syntax: Integer. 1 = ready, 2 = reset.
- The defined values for a completion status of a RTT operation.
|
1 = ok
| A valid completion occurred and timed successfully.
|
| 2 = disconnected
| The operation did not occur because the connection to the target was lost.
|
| 3 = overThreshold
| A valid completion was received, but the completion time exceeded a threshold value.
|
| 4 = timeout
| An operation timed out; no completion time was recorded.
|
| 5 = busy
| The operation did not occur because a previous operation is still outstanding.
|
| 6 = notConnected
| The operation did not occur because no connection (session) exists with the target.
|
| 7 = dropped
| The operation did not occur due to lack of internal resources.
|
| 8 = sequenceError
| A completed operation did not contain the correct sequence ID; no completion time was recorded.
|
| 9 = verifyError
| A completed operation was received, but the data it contained did not match the expected data; no completion time was recorded.
|
| 10 = applicationSpecific
| The application generating the operation had a specific error.
|
- Syntax: Integer.
- The severity of a SYSLOG message. The enumeration values are equal to the values that SYSLOG uses, plus 1. For example, with SYSLOG, emergency = 0.
- Syntax: Integer. 1 = emergency, 2 = alert, 3 = critical, 4 = error, 5 = warning, 6 = notice, 7 = info, 8 = debug.
- Syntax: Octet String. Denotes a transport service address. For ciscoDlswTCPDomain, a TAddress is 4 octets long, containing the IP address in network-byte order.
- Defined in RFC 1443 as the value of the MIB-II sysUpTime object at which a specific event occurred.
- 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.
- Syntax: DisplayString (SIZE (10-16)). The identity of the card running the server. The values are as follows:
- Route Processor
- CIP slot slotNumber
- The slotNumber variable is a positive integer indicating the slot number in which the CIP is installed.
- Syntax: Tn3270sUnsigned32. The address range for a LU.
- Syntax: Tn3270sUnsigned32. The address range for a PU.
- Syntax: Integer (0-65535). A range for TN3270 port addresses.
- Syntax: Integer (0-4294967295). Unsigned32 definition. To be replaced by Unsigned32 from SNMPv2-Structure of Management Information (SMI) when it is implemented.
- Syntax: Integer. 1 = true and 2 = false. Defined in Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2), RFC 1443.
- Syntax: Integer (0-65536). Used to denote the virtual channel identifier (VCI) of a virtual circuit. If the VCI is undefined (that is, it does not exist), then the value of the object is -1.
- Syntax: Integer (0-255). Used to denote the virtual path identifier (VPI) of a virtual circuit. If the VPI is undefined (that is, it does not exist), then the value of the object is -1.
Access
The access type, which applies to SNMPv1, describes whether a MIB variable can be used under one of the following circumstances:
- This variable can be used to monitor information only. For example, the locIPUnreach variable, whose access is read-only, indicates whether Internet Control Message Protocol (ICMP) packets concerning an unreachable address will be sent.
- This variable can be used to monitor information and to set a new value for the variable. For example, the tsMsgSend variable, whose access is read-write, determines what action to take after a message has been sent.
- The possible integer values for this variable follow:
- 1 = nothing
2 = reload
3 = message done
4 = abort
- This variable can be used to set a new value for the variable only. For example, the writeMem variable, whose access is write-only, writes the current (running) router configuration into nonvolatile memory where it can be stored and retained even if the router is reloaded. If the value is set to 0, the writeMem variable erases the configuration memory.
Max-Access
This variable, which applies to SNMPv2, can represent one of the following four states: read-create, read-write, read-only, and not-accessible.
- You cannot read or write to this variable. Entry statements are typically among those variables that are not accessible.
- This specifies a tabular object that can be read, modified, or created as a new row in a table.
- This variable can be used only to monitor information.
- You can read or modify this variable.
Internetwork Management
The International Organization for Standards (ISO) Network Management Forum defines five areas of network management: fault, configuration, security, performance, and accounting. Cisco MIB variables can be mapped to each of these areas (as described in this section) and used to manage your internetwork.
Although a variable might have a primary use for one aspect of network management, variables often overlap multiple areas. For example, locIPhow and locIPwho, discussed next under "Configuration Management," can also be used for fault management if a system is not loading properly.
- Fault management involves running diagnostic tests on the internetwork, analyzing the results, and isolating and resolving problems.
- Examples:
- Several of the variables described in the "Local Variables" chapter in the section "Basic" provide resources for troubleshooting. For example, the variables freeMem, and whyReload provide information on why a router was reloaded, and indicate how much memory is currently available in a device.
- The variables described in the "CiscoMgmt Variables" chapter in the section "Cisco Environmental Monitor Group" provide feedback on the physical status of the Cisco 7000 router.
- Statistics from variables in the "Local Variables" chapter in the section "Interface Table" record the number of packets dropped on particular interfaces so that they can be identified as potential trouble spots.
- Configuration management involves monitoring and controlling the configuration of devices on the internetwork.
- Examples:
- The locIPhow and locIPwho variables described in the "Local Variables" chapter in the section "Internet Protocol (IP) Group" provide information on how a device received its IP address and the device that provided it with its address.
- The variables described in the "Local Variables" chapter in the sections "Host Configuration File" and "Network Configuration File" provide configuration file names and addresses of hosts supplying network configuration files.
- The variables described in the "Local Variables" chapter in the section "System Configuration" provide information such as the name of the host that supplied the system boot image for a device and the name of the boot image.
- Security management deals with controlling access to network resources through the use of authentication techniques and authorization policies.
- Example:
- The variable authAddr contains the address of the last SNMP manager that failed the authorization check. The locIPSecurity variable provides the IP security level assigned to an interface.
- Performance management measures traffic flow across the internetwork, calculates the number of packets that are successfully transmitted against those that are dropped, and so on, to optimize efficiency.
- Example:
- The variables described in the "Local Variables" chapter in the section "CPU Utilization" provide feedback on CPU performance. The variables described in the same chapter in the section "Interface Group" provide statistics on time between packets sent, number of packets transmitted successfully, and so on.
- Accounting management involves collecting and processing data related to resource consumption on the Internet.
- Example:
- The variables described in the section "IP Checkpoint Accounting Table" in the "Local Variables" chapter, provide numerous statistics such as packets and bytes sent successfully or dropped.
Cisco supports many of the MIBs described in the following Requests for Comments (RFCs). Also listed are RFCs describing the Internet standards that Cisco Systems follows with regard to its MIB format and the SNMP protocol.
To obtain copies of RFCs, use the ftp nic.ddn.mil command. Log in as anonymous and enter your e-mail name when prompted for the password. Enter the cd rfc command to change to the correct directory. Use the get rfc-index.txt command to retrieve a list of all available RFCs. To obtain a copy of any specific RFC, enter get rfcnnnn.txt, where nnnn is the RFC number.
- RFC 1155, Structure and Identification of Management Information for TCP/IP-based Internets, May 1990
- Describes the common structures and identification scheme for the definition of management information for use with TCP/IP-based Internets. Formal descriptions of the structure are given using Abstract Syntax Notation One (ASN.1).
- RFC 1156, Management Information Base for Network Management of TCP/IP-based Internets, May 1990
- Describes the initial version of the standard Internet Management Information Base, MIB I. MIB I is superseded by MIB II, as described in RFC 1213.
- RFC 1157, A Simple Network Management Protocol (SNMP), May 1990
- Describes the SNMP architecture and supported operations.
- RFC 1212, Concise MIB Definitions, March 1991
- Describes the format for producing concise, yet descriptive, MIB modules.
- RFC 1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, March 1991
- Describes the Internet standard MIB II for use with network management protocols in TCP/IP-based internetworks.
- RFC 1213 obsoletes RFC 1158.
- RFC 1215, A Convention for Defining Traps for use with the SNMP, March 1991
- Describes the SNMP standardized traps and provides a means for defining enterprise-specific traps.
- RFC 1231, IEEE 802.5 Token Ring MIB, May 1991
- Describes the managed objects for managing subnetworks that use the IEEE 802.5 Token Ring technology.
- Cisco implements the mandatory tables (Interface table and Statistics table), but not the optional table (Timer table) of this MIB.
- RFC 1239 contains information that updates RFC 1231.
- RFC 1243, AppleTalk MIB, July 1991
- Describes the managed objects for AppleTalk that use the SNMP protocol.
- Cisco Systems provides support for the AppleTalk Resolution Protocol (ARP), AppleTalk Port Group, AppleTalk Datagram Delivery Protocol (DDP), AppleTalk Routing Table Maintenance Protocol (RTMP), AppleTalk Zone Information Protocol (ZIP), AppleTalk Name Binding Protocol (NBP), and AppleTalk Echo Group.
- RFC 1253, Open Shortest Path First (OSPF) Version 2 MIB, August 1991
- The OSPF MIB defines an IP routing protocol that provides management information related OSPF and is supported by Cisco routers.
- RFC 1269, Management Information Base for Border Gateway Protocol (BGP), October 1991
- Provides some support for RFC 1269 and replacement draft IETF-BGP-MIBC4-OS.Txt. Cisco supports the following tables in this MIB.
- BGP Version
- BGP LocalAs
- BGP Identifier
- BGP PeerTable
- RFC 1285, FDDI Management Information Base, January 1992
- Describes the managed objects for Fiber Distributed Data Interface (FDDI) devices that are accessible via the Simple Network Management Protocol (SNMP).
- Cisco Systems supports only some of the variables in the Station Management (SMT) and Media Access Control (MAC) groups of this MIB. See "Variables Supported in RFC 1285" in the "Temporary Variables" chapter or refer to the Cisco publication FDDI MIB Variables in 9.0 Product Update Bulletin No. 181. RFC 1285 corresponds to the ANSI FDDI SMT 6.2 draft standard.
- RFC 1315, Management Information Base for Frame Relay DTEs, April 1992
- Cisco supports the following tables in this MIB:
- Data Link Connection Management Interface
- Circuit
- Frame Relay Globals
- Data Link Connection Management Interface Related Traps
- The Error Table is not supported in this MIB.
- RFC 1381, SNMP MIB Extension for X.25 LAPB, November 1992
- Cisco supports the following tables in this MIB:
- LAPB Admn (read-only)
- LAPB Operating Parameters
- LAPB Flow
- The LAPB XID table is not supported in this MIB.
- RFC 1382, SNMP MIB Extension for the X.25 Packet Layer, November 1992
- The X.25 packet layer MIB is available under the ifType node
rfc887-x25 (5) registered under the MIB-II transmission Object Identifier. This condition applies to all X.25 interfaces, including any Defense Data Network (DDN) X.25 encapsulation interfaces. Cisco supports the following tables in this MIB:
- X.25 Administration (read-only)
- X.25 Operational
- X.25 Statistics
- X.25 Channel (read-only)
- X.25 Circuits Information (read-only)
- X.25 Traps (both must be configured)
- The following tables are not supported in this MIB:
- X.25 Cleared Circuit Table
- X.25 Call Parameter Table
- RFC 1398, Ethernet-like Interface Types, January 1993
- Specifies an Internet Activities Board (IAB) standards track protocol for the Internet community and defines objects for managing Ethernet-like objects.
- RFC 1406, Definitions of Managed Objects for DS1 and E1 Interface Types, January 1993
- RFC 1406 obsoletes RFC 1232.
- RFC 1442, Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993
- This document outlines the subset of OSI's Abstract Syntax Notation One (ASN.1) used to define the Management Information Base (MIB) for version 2 of the Simple Network Management Protocol (SNMPv2).
- RFC 1443, Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2), April 1993
- Defines the initial set of extensions (textual conventions) to the basic types defined in the SMI (RFC 1442), which are available to all MIB modules.
- RFC 1447, SNMPv2 Party MIB, April 1993
- Describes the managed objects that correspond to the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies, as defined by the SNMPv2 Administrative Model.
- Cisco supports the MIB variables as required by the Conformance clauses specified in these MIBs.
- RFC 1450, SNMPv2 MIB, April 1993
- Describes the managed objects that cause the behavior of an SNMPv2 implementation.
- Cisco supports the MIB variables as required by the Conformance clauses specified in these MIBs.
- RFC 1493, Definitions of Managed Objects for Bridges, July 1993
- RFC 1493 obsoletes half of RFC 1286.
- RFC 1512, FDDI Management Information Base, September 1993
- RFC 1512 updates, but does not obsolete, RFC 1285.The changes from RFC 1285, based on changes from ANSI SMT 6.2 to SMT 7.3, were so numerous that the objects in this MIB module are located on a different branch of the MIB tree. No assumptions should be made about compatibility with RFC 1285.
- RFC 1516, Standard Repeater MIB, September 1993
- Defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this RFC defines objects for managing IEEE 802.3 10-Mbps baseband repeaters, sometimes referred to as hubs.
- RFC 1525, Definitions of Managed Objects for Source Routing Bridges, September 1993
- RFC 1525 obsoletes half of RFC 1286.
- Cisco supports all of the groups described in this MIB, including the following groups: dotldBase, dotldSr, dot1dStp, and dotIdTp.
- RFC 1593, SNA APPN Node MIB, March 1994
- Cisco supports most, but not all, objects in RFC 1593, an informational RFC containing managed objects that describe the Advanced Peer-to-Peer Networking (APPN) node, the connections of the node to other SNA nodes, and the APPN network topology.
- RFC 1659, Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2, July 1994
- The RS-232-like Hardware Device MIB applies to interface ports that might logically support the Interface MIB, a Transmission MIB, or the Character MIB. The most common example is an RS-232 port with modem signals.
- The RS-232-like Hardware Device MIB is mandatory for all systems that have such a hardware port supporting services managed through some other MIB.
- The MIB includes many similar types of hardware, and as a result contains objects not applicable to all of those hardware types. The compliance definitions have a general group for all implementations, and separate groups for the different types of ports, such as asynchronous and synchronous.
- The RS-232-like Hardware Port MIB includes RS-232, RS-422, RS-423, V.35, and serial physical links (other asynchronous or synchronous) with a similar set of control signals.
- The MIB contains objects that relate to physical layer connections. Such connections may provide hardware signals (other than for basic data transfer), such as RNG and DCD. Hardware ports also have such attributes as speed and bits per character.
- RFC 1695, Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2, August 1994
- Cisco supports most, but not all, objects in RFC 1695. RFC 1695 defines ATM management objects used to manage ATM interfaces; ATM virtual links; ATM cross-connects; ATM Adaptation Layer 5 (AAL5) entities; and AAL5 connections supported by ATM hosts, ATM switches, and ATM networks. The objects defined in this RFC are used primarily to manage ATM permanent virtual circuits (PVCs). Some ATM switched virtual circuits (SVCs) are also represented in this MIB.
- RFC 1747, Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2, January 1995
- This specification defines objects for managing the configuration, monitoring, and control of data link controls in an SNA environment.
- RFC 1757, Remote Network Monitoring MIB, February 1995
- The Remote Network Monitoring (RMON) MIB provides visibility of individual nodal activities and allows all nodes and their interaction on a LAN segment to be monitored. Used specifically as an agent in the router, RMON allows you to view both traffic that flows through the router as well as segment traffic not necessarily destined for the router. RMON alarms and events can be coupled with other Cisco MIBs to provide specific proactive monitoring. RFC 1757 obsoletes RFC 1271.
Note All Cisco IOS Release 11.2 feature sets contain RMON alarm and events group support. Additional RMON groups (statistics, history, hosts, hostTopN, matrix, filter, and capture) are supported in certain feature sets. Refer to the Cisco IOS Release 11.2 Release Notes for feature set descriptions.
For detailed information on configuration and troubleshooting commands, refer to the Cisco IOS configuration guides and command references.
Users of the CiscoWorks router management software can refer to the CiscoWorks Installation and Reference Guide and CiscoWorks online help for information on CiscoWorks router management software features and its use of MIB variables for the purposes of graphing and analyzing network performance, ensuring configuration consistency, troubleshooting, and more.
Following are suggested reading materials:
- Leinwand, A. and K. Fang. Network Management: A Practical Perspective. Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1993.
- Rose, M. T. The Simple Book: An Introduction to Management of TCP/IP-based Internets. Englewood Cliffs, New Jersey: Prentice-Hall; 1991.
- Rose, M. T. The Simple Book: An Introduction to Internet Management, 2nd edition. Englewood Cliffs, New Jersey: Prentice-Hall; 1993.
- Rose, M. T. and Keith McCloghrie. How to Manage Your Network Using SNMP, The Network Management Practicum. Englewood Cliffs, New Jersey: Prentice-Hall; 1995.
- Stallings, W. SNMP, SNMPv2, and CMIP: The Practical Guide to Network Management Standards. Reading, Massachusetts: Addison-Wesley Publishing Company, Inc.; 1993.
Object Identifier Numbers for Variables
The figures in this section provide a visual overview of the Cisco MIB variables along with the object identifier numbers for each MIB variable. The MIB variables are arranged within each figure in the same order in which they appear in the sections of this document.
Notifications (traps) are not generally included in the figures in this section.
Figure 1-5:
Local Variables: Flash File Table and Flash Group
Figure 1-6:
Local Variables: Interface Group Table
Figure 1-7:
Local Variables: FSIP Group Variables
Figure 1-8: Local Variables: Interface Group--ARP, AppleTalk, Apollo, Bridging, CLNS, DECnet, HP Probe, IP, LNM, and MOP
Figure 1-9: Local Variables: Interface Group--Novell, Other Protocols, STUN, Spanning Tree
Figure 1-10:
Local Variables: Interface Group--VINES
Figure 1-11:
Local Variables: Interface Group--XNS
Figure 1-12:
Local Variables: IP Group
Figure 1-13:
Local Variables: IP Accounting Table
Figure 1-14:
Local Variables: IP Checkpoint Accounting Table
Figure 1-15:
Local Variables: System Group--Buffers
Figure 1-16: Local Variables: System Group--CPU Utilization and Environmental Monitor Card
Figure 1-17:
Local Variables: Terminal Services Group
Figure 1-18: Local Variables: TCP Connection Table
Figure 1-19: ciscoMgmt Variables: BSC Group
Figure 1-20: ciscoMgmt Variables: BSTUN Group
Figure 1-21: ciscoMgmt Variables: CIP Group
Figure 1-22: ciscoMgmt Variables: Cisco CIP CSNA Group
Figure 1-23: ciscoMgmt Variables: Cisco CIP CSNA Group (cont.)
Figure 1-24: ciscoMgmt Variables: Cisco CIP LAN Group
Figure 1-25: ciscoMgmt Variables: Cisco CIP TCP/IP Group
Figure 1-26: ciscoMgmt Variables: Cisco CIP TCP/IP Group (cont.)
Figure 1-27: ciscoMgmt Variables: Cisco Configuration Management Group
Figure 1-28: ciscoMgmt Variables: Cisco DLSw Group
Figure 1-29: ciscoMgmt Variables: Cisco DLSw Group (cont.)
Figure 1-30: ciscoMgmt Variables: Cisco Discovery Protocol (CDP) Group
Figure 1-31: ciscoMgmt Variables: Cisco DSPU Group
Figure 1-32: ciscoMgmt Variables: Cisco Environmental Monitor Group
Figure 1-33: ciscoMgmt Variables: Cisco Flash Group
Figure 1-34: ciscoMgmt Variables: Cisco Integrated CSU/DSU Group
Figure 1-35: ciscoMgmt Variables: Cisco ISDN Group
Figure 1-36: ciscoMgmt Variables: Cisco Interface Queue Group
Figure 1-37: ciscoMgmt Variables: Cisco IP Encryption Group
Figure 1-38: ciscoMgmt Variables: Cisco LANE Broadcast-and-Unknown Server Group
Figure 1-39: ciscoMgmt Variables: Cisco LANE Configuration Group
Figure 1-40: ciscoMgmt Variables: Cisco LANE Service Group
Figure 1-41: ciscoMgmt Variables: Cisco Modem Management Group
Figure 1-42: ciscoMgmt Variables: Cisco Ping Group
Figure 1-43: ciscoMgmt Variables: Cisco RSRB Group
Figure 1-44:
ciscoMgmt Variables: Cisco Repeater (ciscoRptr) Group
Figure 1-45: ciscoMgmt Variables: Cisco RTT Monitoring Group
Figure 1-46: ciscoMgmt Variables: Cisco RTT Monitoring Group (cont.)
Figure 1-47: ciscoMgmt Variables: Cisco SDLLC Conversion Group
Figure 1-48: ciscoMgmt Variables: Cisco STUN Group
Figure 1-49: ciscoMgmt Variables: Cisco SNA LLC Group
Figure 1-50: ciscoMgmt Variables: Cisco SNA LLC Group (cont.)
Figure 1-51: ciscoMgmt Variables: Cisco Snapshot Routing Group
Figure 1-52: ciscoMgmt Variables: Cisco SYSLOG Message Group
Figure 1-53: ciscoMgmt Variables: Cisco TCP Group Connection Table
Figure 1-54: ciscoMgmt Variables: Cisco TCP Offload Group
Figure 1-55: ciscoMgmt Variables: Cisco TN3270 Server Group
Figure 1-56: ciscoMgmt Variables: Cisco VINES Group
Figure 1-57: ciscoMgmt Variables: Cisco VINES Group (cont.)
Figure 1-58: ciscoMgmt Variables: QLLC and QLLC SNA Conversion Groups
Figure 1-59:
Temporary Variables: AppleTalk Group
Figure 1-60: Temporary Variables: Chassis Group
Figure 1-61:
Temporary Variables: DECnet Group
Figure 1-62:
Temporary Variables: DECnet Tables
Figure 1-63: Temporary Variables: Novell Group
Figure 1-64:
Temporary Variables: IPX Accounting Table
Figure 1-65:
Temporary Variables: IPX Checkpoint Accounting Table
Figure 1-66: Temporary Variables: VINES Group
Figure 1-67: Temporary Variables: VINES Interface Table
Figure 1-68: Temporary Variables: XNS Group
