|
|
Network management systems that use the Simple Network Management Protocol (SNMP) work with information stored in a Management Information Base (MIB). The MIB is a collection of variables known as MIB objects. The values of MIB objects help to govern the status and activities of LightStream 2020 multiservice ATM switch (LS2020 switch) software and hardware. The values of MIB objects are written by LS2020 operational software and by network management system (NMS) software, including the CLI. When NMS software displays the activities and status of the LS2020 node, it obtains them by reading the values of MIB objects.
The major branches of the MIB are themselves referred to as MIBs, such as the FDDI MIB, the Bridge MIB, and the SONET MIB. Most of these MIBs are public standards which are described in publicly available RFC documents.
Figure 7-1 shows a high-level diagram of the MIB that is used to manage LS2020 switches. The high-level organization of the MIB is defined in RFC 1155, Structure of Management Information (SMI). (The full title is Structure and Identification of Management Information for TCP/IP-based Internets.) Public MIBs have been defined by various standards bodies to fit in this structure. There is also a place defined in it for private MIBs, such as the LS2020 private MIB.
The MIB has a hierarchical tree structure:
Many of the objects shown in Figure 7-1 (that is, the branches rooted in those objects) are themselves referred to as MIBs. Outside of the private MIB branch, these are all standard MIBs. For information on some of the standard MIBs shown in Figure 7-1, refer to the following public-domain documents:
| MIB | Request for Comment (RFC) Document |
|---|---|
The LS2020 private MIB is in the private subtree (under the private object). This is the MIB that is described in the remainder of this chapter.
There are two ways to access a MIB, including the LS2020 private MIB:
These two methods are discussed in the following subsections. In addition, some network management applications include MIB browsing software that displays the descriptive text that is given in the definition of each MIB object under the heading "DESCRIPTION."
You can use CLI commands to view MIB object names and values.
The browse and walksnmp commands each display the set of objects in a specified branch of the MIB. The default for the browse command is the iso object at the root of the MIB; the walksnmp command has no default and requires an argument.
The getsnmp command displays an individual instance of a leaf object at the bottom of a branch. The MIB address in its argument must include an object identifier. See the subsections entitled "MIB Addresses" and "Object Identifiers."
The browse, walksnmp, getsnmp, getnextsnmp, and setsnmp commands are described in the chapter entitled "MIB Commands."
A MIB address identifies a particular MIB object by giving its location in the MIB.
You can specify the address of a MIB object in a number of ways. For example, the following MIB addresses all refer to the same MIB object:
To identify a single instance of a MIB object at the end of a branch, you specify the object name, followed by a numeric suffix known as an object identifier. The object name is separated by a dot from the object identifier.
If there is only a single instance of the given object, the identifier suffix for that instance is 0. For example, there is only one instance of the sysContact object, so its identifier is sysContact.0. The following command displays the name of the contact person for the target node:
You can determine what object identifier is used to specify a single instance of a given MIB object by examining the definition of that object in the MIB. (Object names are also included in the descriptions of configurable attributes in the LightStream 2020 Configuration Guide.) The following section describes the process by which MIB objects are defined, using examples from the private MIB file. For more information about object identifiers in particular, see the subsections entitled "Object Identifiers in the MIB File," "How the ifIndex Value Specifies a Unique Port ," and "Multiply-Indexed Objects ."
Detailed descriptions of the objects in a MIB are given in the MIB file in which the MIB is defined. The definitions of a standard MIB are elaborated in somewhat greater detail in the RFC document that specifies the MIB (see the subsection entitled "Standard MIBs").
The location of the LS2020 private MIB file depends upon the system on which you are looking.
| If you are connected to ... | Look in this directory ... |
|---|---|
/usr/LightStream-X.x/mib/lightstream.asn, where X.x is the software version number. |
Use a text display program to examine this file. For example, to view the file on an LS2020 switch with the more command, enter the following commands:
To view the file with the vi editor, enter the following commands:
See the LightStream 2020 NP O/S Reference Manual for information about using the more command and the vi editor.
This section uses instances from the LS2020 private MIB to illustrate how MIB objects are defined. The MIB object names and their definitions in the private MIB file are compiled into the operational code on the node. The file is write protected. There are comments in the file which are not compiled into the code; each comment line is marked with two hyphens (--) before the comment text, usually in the left margin.
The beginning of the file includes
The definitions of the lsOther objects in the private MIB file serve here as simple examples of how objects are defined in the MIB:
These definitions have the following elements:
The variables that can be specified in the SYNTAX field are defined in three ways: by importation from a different MIB file, by global definition at the beginning of the given MIB file, or in an ad hoc way for each table defined in the given MIB file.
In the definitions of the lsOther objects, the DisplayString variable was imported from a standard MIB for use in the SYNTAX fields of definitions in the LS2020 private MIB. Table 7-1 lists imported SYNTAX variables:
Table 7-1 SYNTAX Variables That Are Imported from Standard MIBs
| SYNTAX Variable | |||
|---|---|---|---|
Other SYNTAX variables are globally defined at the beginning of the private MIB file as "text conventions" for use in many object definitions. Table 7-2 lists these variables:
Table 7-2 Other Globally Defined SYNTAX Variables
In addition, a SYNTAX variable is defined for the objects that make up each table in the MIB. The definitions of MIB tables are presented in the following subsection.
When a set of MIB objects describe attributes of the same entity (such as a card or a port), they are defined as a table. All the objects in a table use the same object identifier (such as a card number or port number) as an index.
Figure 7-2 represents the outline of a typical MIB table, cardTable in the cardInfo branch of the MIB.
Five different kinds of objects are defined to make a table:
| 1. cardTable | |
| 2. cardEntry | The table entry object. The actual table entries (Item 5) are instances of this object. |
| 3. CardEntry | The table entry structure object. This object is not shown in Figure 7-2 because it is not defined as a branch of any higher-level object; its function is only to provide structure for other objects. It specifies a list of objects (see Item 5). |
| 4. cardIndex | |
| 5. cardName cardBoardType ... cardNumPorts |
The actual table entries. These are the objects enumerated for the table entry structure object (see Item 3). |
The definitions of these five different kinds of objects are interrelated:
1. The table object, that is, the name of the table itself. The syntax of the table object is specified as a sequence of table entry objects (more exactly, table entry structure objects; see Item 3, below).
The cardTable object is defined as follows:
The CardEntry object named here in the SYNTAX field is defined under Item 3 as a set of card attributes. The cardTable object is defined above as a sequence of these CardEntry attribute sets.
2. The table entry object. Each of the actual table entries (Item 5) is an instance of this object, which in turn is defined here as an instance of the table entry structure object (Item 3). In this way, each table entry (Item 5) is structured as an instance of the set of attributes enumerated in the definition of the table entry structure object (Item 3).
The cardEntry object is the first and only object defined under the cardTable object (see the last line of the definition below and the last line of the definition in Item 1). It is defined as follows:
The two names cardEntry and CardEntry are different. The cardEntry object is defined as an instance of the CardEntry object. The CardEntry object named in the SYNTAX field is defined in Item 3 as a set of card attributes. The cardEntry object is thus an instance of that set of card attributes. The INDEX field specifies the object identifier (see Item 4).
3. The table entry structure object. The name of this object is the same as the name of the table entry object (Item 2), except that it begins with an uppercase letter. The syntax for this object is specified as a sequence of object names each with its syntax type. This object defines the structure of the table and appears in the SYNTAX field in definitions in Items 1 and 2.
The sequence defined by the CardEntry object for the cardEntry object (Item 2) and the cardTable object (Item 1) is as follows:
4. The table index object. It is specified as an integer, or sometimes as a dot-separated pair of integers. The value of this object identifies a single instance of an entry in the table.
For example, the cardIndex object, the first instance of the cardEntry object (see Item 3), is defined as follows:
To use the getsnmp command to display the value of one of the objects defined in Item 5, you must supply a valid value of the index object as the object indicator. (Object indicators are described more fully in the next section, entitled "Object Identifiers in the MIB File.") For example, to display the value of the cardName object for Card 3, you can use the getsnmp command as follows:
5. The series of definitions of the objects enumerated in Item 3 (e.g., the CardEntry object). Each of these objects is a leaf under the table entry object, Item 2 (e.g., the cardEntry object).
The second and the last of the 12 leaf objects under the cardEntry object (omitting others for brevity) are defined as follows:
To use a CLI command to address a single instance of an object defined in a MIB table, you must know the object identifier for that instance. (This requirement was discussed earlier, in the section entitled "Displaying MIB Objects with CLI Commands.")
This section describes the different kinds of object identifiers that may be specified in the definitions of tables.
In the MIB file, the object identifier for table entries is identified in the INDEX field of the definition of the table entry object. The entry in this field specifies the structure of table entries. The object identifier is defined as the table index object (Items 2 and 4 in the section entitled "Tables in the MIB File"). For example, under the cardTable object, the definition of cardEntry (the table entry object) includes the following INDEX specification:
In the same example, the cardIndex object is defined as an integer, specified as the card number:
Because of this INDEX specification in the definition of the table entry object, every entry in the table has the same object identifier. In this example, the index is the number of the particular card whose MIB object values are being set or read. For instance, the value of cardName.3 is the name of Card 3.
In working with CLI commands, you may become accustomed to specifying a unique port number (a port on a specified card) in the format c.p, where c is the card (slot) number and p is the number of a port on that card. However, when you use the getsnmp, getnextsnmp, or setsnmp command with a MIB object that is indexed by port number as its argument, you must specify the object identifier in a more complex format. In this format, the card number, the port number, and the port type are all represented by a single integer. This integer is the value of the ifIndex object. (The ifIndex object is defined in the MIB-II MIB, RFC 1213.)
The definition of the portInfoTable object can be used to illustrate how the ifIndex value specifies a unique port. the portInfoTable object organizes information about ports (interfaces) in much the same way as the cardTable object organizes card attributes. The index object in the portInfo table is an ifIndex value, defined as follows:
Where the description text in this definition says "see comments above," it refers to comments at the beginning of the private MIB file. These comments describe the algorithm for defining the ifIndex value for a port. This algorithm can be expressed in the following formula:
The variables in this formula are as follows:
You can abbreviate this formula in the format ctp. For example, the MIB object that stores the alias or name for Port 3 on Card 4 is portInfoName.3104 for an Ethernet port, portInfoName.3204 for an FDDI port, or portInfoName.3004 for a port on any other type of card.
Note The ifIndex value 1255 refers to the control port (port 255) of the NP in Slot 1, and the ifIndex value 2255 refers to the control port of the NP in Slot 2. The control port of an NP is used by software to communicate with the CPU on the NP.
Some objects are indexed by more than one number. For example, a DLCI must be specified not only by a DLCI number but also by an ifIndex value identifying a port, and a multicast group is a list of member ports, each of which must be specified not only by its ifIndex value, but also by a chassis ID and a multicast group ID. The several parts of a complex object identifier are dot-separated integers.
For example, the output of the command getsnmp frCktInfoLclLMI.4002.16 in the following example tells us that the local LMI state of the frame relay circuit on DLCI 16, Port 4, Card 2 is inactive. (In the next section, you will see how to determine that the integer 2 here means that the local LMI state is inactive.)
The double index 4002.16 means that this frCktInfoLclLMI object is indexed first by ifIndex value 4002 (Card 4, Type 0, Port 2) and then by DLCI number 16.
To interpret the value of a MIB object, refer to the definition of the object. In the last example in the preceding section, the value of the frCktInfoLclLMI.4002.16 object was displayed as 2. To interpret this value, examine the private MIB file and read the description text for frCktInfoLclLMI in the private_mib.asn MIB file. The definition of this object is as follows:
The syntax field in this definition specifies that the value 2 means "inactive."
The high-level structure of the LS2020 private MIB is shown in Figure 7-3.
Note The three vertical dots in Figure 7-3 indicate the place where higher levels of the MIB belong. These upper levels are shown in Figure 7-1.
The major branches of the private MIB are described in the following sections:
Three objects shown in Figure 7-3 are not major branches of the MIB:
Figure 7-4 shows the atmSwitch subtree, which comprises most of the LS2020 private MIB.
The branches of the atmSwitch subtree are described in the following sections:
Figure 7-5 shows the chassisInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
Figure 7-6 shows the cardInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
Figure 7-7 shows the portInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
There are two tables in the portInfo branch, portInfoTable, in which each table entry contains information about one port on a card, and lsEtherTable, whose only entry is the lsEtherMediaType object.
Figure 7-8 shows the portTransmission branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
The objects in the portTransmission branch include a number of MIB object tables: one for each card type, one for cell routing information (controlling cell delay variation), and one for virtual path trunking. Each entry of a table for a card type (such as ls1InfoEntry, ms1InfoEntry, or npInfoEntry) contains information about a port on a card.
Figure 7-9 shows the objects in the congestionAvoidance branch of the atmSwitch subtree.
Figure 7-10 shows the mmaInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
The mmaInfo branch contains one table, mmaNumNameTable.
Figure 7-11 shows the collectInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
The collectInfo branch contains two tables:
Each row of each table contains information about a collection that has been defined. The collectInfo branch also contains the collectCommunityName and rmonCommunityName objects (the latter not currently used).
Figure 7-12 shows the lsPortProtocols branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
The lsPortProtocols branch includes a number of tables containing information about the various services available on an LS2020 network.
The lsPrivate branch of the atmSwitch subtree (atmSwitch.10) is reserved for use in later releases. It is currently empty.
Figure 7-13 shows portions of the lsExperimental branch of the atmSwitch subtree.
The lsExperimental branch contains objects that can be used by Cisco Systems to provide advanced support functions and analysis of network performance. This branch is little used. Three tables in this branch contain MIB objects that are used to collect cell statistics and to collect statistics on edge cards for frame relay and frame forwarding. These tables are
To obtain the statistical information associated with these MIB objects, use the getsnmp command.
Note The figure shows only those objects in this branch that are of potential use for statistics. An ellipsis (...) or a vertical line of dots is used to indicate where additional objects exist. See the MIB file for detailed information.
Figure 7-14 shows the internal routing (lsIR) branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
The lsIR branch contains objects pertaining to internal routing.
The lsStatistics branch of the atmSwitch subtree (atmSwitch.13) is currently empty. It will be used for objects (presently in the lsExperimental branch) that the system uses to analyze network performance.
Figure 7-15 shows the tcsInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
The tcsInfo branch contains objects pertaining to the test and control system (TCS).
Figure 7-16 shows the lsGID branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead, an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
The lsGID branch contains objects pertaining to the global information distribution (GID) system.
Figure 7-17 shows the lsPID branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist. See the MIB file for detailed information.
The lsPID branch contains objects that are concerned with operating system processes.
Figure 7-18 shows the lsND branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist.
The lsND branch contains objects that pertain to neighborhood discovery.
Figure 7-19 shows the lwmaInfo branch of the atmSwitch subtree.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) or a vertical line of dots is used to indicate that additional objects exist.
The lwmaInfo branch contains objects that pertain to the lightweight management agent (LWMA), which links application processes to the LS2020 network management system.
Figure 7-20 shows the lightStreamBridge and lightStreamLanPort branches in the lightStreamInternet subtree of the LS2020 private MIB. (The lightStreamInternet object is defined near the beginning of the MIB file.)
Note The figure does not show all of the objects in these branches because there are too many of them. In this figure, no ellipsis (...) is used where objects have been left unspecified.
The lightStreamBridge branch contains objects that pertain to bridging, and the lightStreamLanPort branch contains objects that define port attributes required for LAN ports.
Figure 7-21 shows the lightStreamVli subtree in the LS2020 private MIB. (The lightStreamVli object is defined near the beginning of the MIB file.)
The lightStreamVli subtree contains objects that pertain to virtual LAN internetworking (VLI).
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
Figure 7-22 shows the lightStreamCbr subtree in the LS2020 private MIB. It contains one table, lsNtCfgTable, and a number of other objects relating to constant bit rate traffic.
The lightStreamCbr subtree contains objects that pertain to constant bit rate traffic.
Note The figure does not show all of the objects in this branch because there are too many of them. Instead the first and last objects at each level are shown, and an ellipsis (...) is used to indicate that additional objects exist. See the MIB file for detailed information.
Posted: Wed Jan 22 23:55:24 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.