Table of Contents

LightStream 2020 MIB Reference

MIB Overview
Standard MIBs
LS2020 Private MIB
Accessing MIBs on Line
Displaying MIB Objects with CLI Commands
MIB Addresses
Object Identifiers
Reading a MIB File
How MIB Objects Are Defined
Variables Used in the SYNTAX Field
Tables in the MIB File
Object Identifiers in the MIB File
How Object Identifiers Are Specified
How the ifIndex Value Specifies a Unique Port
Multiply-Indexed Objects
Interpreting Integer Values of MIB Objects
Major Branches of the Private MIB
atmSwitch
chassisInfo
cardInfo
portInfo
portTransmission
congestionAvoidance
mmaInfo
collectInfo
lsPortProtocols
lsPrivate
lsExperimental
lsIR
lsStatistics
tcsInfo
lsGID
lsPID
lsND
lwmaInfo
lightStreamInternet
lightStreamVLI
lightStreamCbr

LightStream 2020 MIB Reference

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.

This chapter

• Describes the organization of the MIB used to manage LS2020 enterprise ATM switches.
  

• Identifies the RFCs that describe some of the most important standard MIBs.
  

• Describes where to find the LS2020 private MIB file on line.
  

• Presents the structure of each branch of the LS2020 private MIB.
  

• Describes how to determine the addresses of MIB objects. (The SNMP commands getsnmp, getnextsnmp, setsnmp, and walksnmp require MIB addresses as arguments. These commands are described in the chapter entitled "MIB Commands.")
  

• Tells you how to read and interpret the information in the LS2020 private MIB file.
  

MIB Overview

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.

Figure 7-1 : Overall MIB Structure

The MIB has a hierarchical tree structure:

• The root of the tree, at the top, is the iso MIB object. (The ISO is the International Standards Organization.)
  

• There can be one or more branches under any given object.
  

• The number in parentheses after each object indicates which branch the object is in (of the branches descending from the object above it).
  

• Not all branches are shown here. For example, only branches 2, 3, and 4 are shown under the internet(1) object:
  

  • Branch 2 is rooted in the mgmt object.
    

  • Branch 3 is rooted in the experimental object.
    

  • Branch 4 is rooted in the private object.
    

• The lowest-level objects in any given branch (not shown here) are sometimes referred to as "leaves" of the tree structure. These are the only MIB objects of which there may be individual instances (an individual port, for example). The higher-level objects define classes of MIB objects.
  

Standard MIBs

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
MIB-II	RFC 1213
Dot-3 Ethernet MIB	RFC 1398
FDDI MIB	RFC 1512
DS1 MIB	RFC 1406
DS3 MIB	RFC 1233
Dot-1 Bridge MIB	RFC 1493
SONET MIB	RFC 1595

LS2020 Private MIB

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.

Accessing MIBs on Line

There are two ways to access a MIB, including the LS2020 private MIB:

• Use SNMP commands in the CLI to display MIB object names and values.
  

• Use NP O/S display commands to examine the object names, definitions, and descriptions in the MIB file itself.
  

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

Displaying MIB Objects with CLI Commands

You can use CLI commands to view MIB object names and values.

walksnmp	To learn the names of MIB variables in a subtree, specify the name of the object at the head of the subtree as the argument of the walksnmp command. This command displays all the branches and leaves below the specified point in the MIB. cli> walksnmp fddi
browse	To step through the branches of the MIB tree one at a time, specify a branch as the argument of the browse command. (The default is the iso object.) When you reach the end of a branch, this command displays the values of leaves one at a time. cli> browse mib-2
getsnmp	To display the value of a single MIB object at the end of a branch, specify an individual instance of a "leaf" as the argument of the getsnmp command. cli> getsnmp sysContact.0

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

MIB Addresses

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:

• An object name:
  

sysContact.0


• A path of dot-separated numbers (the numbers in parentheses in Figure 7-1 and Figure 7-3), beginning with the iso object at the root of the MIB:
  

1.3.6.1.2.1.1.4


• A combination, where the first element is the name of a branch and the numbers specify successive branches in the subtree under it:
  

iso.3.6.1.2.1.1.4
org.6.1.2.1.1.4
dod.1.2.1.1.4
internet.2.1.1.4
mgmt.1.1.4
mib.1.4
system.4


Object Identifiers

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:

cli> getsnmp sysContact.0

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. (They 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."

Reading a MIB File

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 ...
an LS2020 node	/usr/app/base/etc/private_mib.asn
a Workstation running HP OpenView StreamView	/usr/OV/snmp_mibs/lightstream
a Workstation not running HP OpenView StreamView	/LightStream-2.1/mib/lightstream.asn

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:

LSnode:2# cd /usr/app/base/etc

LSnode:2# more private_mib.asn

To view the file with the vi editor, enter the following commands:

LSnode:2# cd /usr/app/base/etc

LSnode:2# vi private_mib.asn

See the LightStream 2020 NP O/S Reference Manual for information about using the more command and the vi editor.

How MIB Objects Are Defined

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

• A section in which some object definitions are imported from standard MIBs
  

• Comments describing the format for port numbers (see the subsection entitled "How the ifIndex Value Specifies a Unique Port," below)
  

• Some global definitions, described in the MIB file as "textual conventions"
  

The definitions of the lsOther objects in the private MIB file serve here as simple examples of how objects are defined in the MIB:

--   lsOther is used to define varbinds in trap message    



    lsOther              OBJECT IDENTIFIER ::= { lightStreamOIDs 2 }



    lsTrapText  OBJECT-TYPE

    SYNTAX  DisplayString

    ACCESS  not-accessible

    STATUS  mandatory

    DESCRIPTION

       "This is the OID of the free formatted string used in

       enterprise specific traps to describe the event."

         ::= { lsOther 2 }


    LsTrapName  OBJECT-TYPE

    SYNTAX  DisplayString

    ACCESS  not-accessible

    STATUS  mandatory

    DESCRIPTION

       "The first object in an enterprise specific

       trap that contains the trap level, trap name and time

       the trap occurred."  
         ::= { lsOther 3 }

These definitions have the following elements:

• The first line is a comment that describes the purpose of the lsOther objects. The comment is marked by two hyphens in the left margin.
  

• The lsOther object itself is defined as an object identifier, specified as the second branch under the lightStreamOIDs object.
  

• The variable in the SYNTAX field specifies what kind of value the object can have. Both lsOther objects are defined as DisplayString objects. The definition of DisplayString was imported from MIB-II at the beginning of the MIB file. (MIB-II is referred to there as RFC1213-MIB.) See the subsection entitled "Variables Used in the SYNTAX Field" for a list of values that may be specified in the SYNTAX field.
  

• In the ACCESS field, both lsOther objects are defined as not accessible. This means they are only used internally by the software. In most of the object definitions in the private MIB, the ACCESS field has the value read-only or read-write.
  

• The DESCRIPTION field contains text describing the MIB object. The description text is within quotation marks. Some NMS software can display this text.
  

• The last line of the definition specifies the object as an ordinally numbered branch of a higher-level object. (It is these numbers that appear in parentheses in Figure 7-1.)
  

  • The object identifier lsOther is defined as the second branch of the lightStreamOIDs object.
    

  • The lsTrapText object is branch number 2 under lsOther. The lsTrapName object is branch number 3 under lsOther. (The definition of branch 1 is not shown in the example, because it is commented out in the file.)
    

Variables Used in the SYNTAX Field

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	Source	Object Type	Values
IpAddress	RFC 1155 (SMI)	Octet string	32-bit IP address
Counter	RFC 1155 (SMI)	Integer	0 -- 4,294,967,295; Wraps to 0 when max is reached
Gauge	RFC 1155 (SMI)	Integer	0 -- 4,294,967,295; Latches at max attained value
TimeTicks	RFC 1155 (SMI)	Integer	Hundredths of a second
ifIndex	RFC 1213 (mib-2)	Integer	An interface ID
DisplayString	RFC 1213 (mib-2)	Octet string	A string of printable characters

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

SYNTAX Variable	Object Type	Values
LightStreamStatus	Integer	1 = enabled 2 = disabled
LightStreamValidation	Integer	1 = valid 2 = invalid
LightStreamFilterAction	Integer	1 = forward 2 = block
LightStreamUpToMaxAge	Integer	Range: 1 -- 3600
LightStreamDLCI	Integer	A DLCI number
VCI	Integer	A VCI number

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.

Tables in the MIB File

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.

Figure 7-2 : An Example of a MIB Table

Five different kinds of objects are defined to make a table:

cardTable	The table object, that is, the name of the table itself.
cardEntry	The table entry object. The actual table entries (Item 5) are instances of this object.
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).
cardIndex	The table index object, an integer.
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:

cardTable OBJECT-TYPE
SYNTAX  SEQUENCE OF CardEntry

ACCESS  not-accessible

STATUS  mandatory

DESCRIPTION

"Card specific information"

::= { cardInfo 1 }

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.

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

cardEntry OBJECT-TYPE

SYNTAX   CardEntry

ACCESS   not-accessible

STATUS   mandatory

DESCRIPTION

"An entry in the chassis card table. (1-n)"

INDEX   { cardIndex }

::= { cardTable 1 }

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

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

CardEntry ::=

SEQUENCE {

cardIndex

INTEGER,

cardName

DisplayString (SIZE (0..255)),

cardBoardType

DisplayString (SIZE (0..255)),

cardLcSoftwareVersion

DisplayString (SIZE (0..255)),

cardLccSoftwareVersion

DisplayString (SIZE (0..255)),

cardPID

INTEGER,

cardMaxVCs

INTEGER,

cardOperStatus

INTEGER,

cardAdminStatus

INTEGER,

cardStatusWord

INTEGER,

cardConfigRegister

INTEGER,

cardNumPorts

INTEGER

}

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

cardIndex OBJECT-TYPE

SYNTAX  INTEGER

ACCESS  read-only

STATUS  mandatory

DESCRIPTION

"Unique Index consisting of card number."

::= { cardEntry 1 }

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:

cli> getsnmp cardName.3


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

cardName OBJECT-TYPE

SYNTAX  DisplayString (SIZE (0..255))

ACCESS  read-write

STATUS  mandatory

DESCRIPTION

"Name of Card

::= { cardEntry 2 }

.
.
.

cardNumPorts OBJECT-TYPE

SYNTAX  INTEGER

ACCESS  read-only

STATUS  mandatory

DESCRIPTION

"Number of Ports available on this card."

::= { cardEntry 12 }

Object Identifiers in the MIB File

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

• If a given object is one of a kind, the object identifier is 0 (zero). Examples include sysContact.0 (the name of the administrative contact person for the node), chassisId.0 (the chassis ID), and mmaSetLock.0 (the variable that controls writes from the CLI to the configuration database).
  

• For some MIB objects, the object identifier is a card number.
  

• For many MIB objects, the object identifier is the ifIndex value, which identifies an interface by its port number, card number, and card type (see the subsection entitled "How the ifIndex Value Specifies a Unique Port").
  

• If a given object is one of a set of objects that describe different attributes of the same entity (such as a card or a port), the object identifier is specified in the definition of the table (Item 4 in the preceding section).
  

This section describes the different kinds of object identifiers that may be specified in the definitions of tables.

How Object Identifiers Are Specified

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:

INDEX   { cardIndex }

In the same example, the cardIndex object is defined as an integer, specified as the card number:

cardIndex OBJECT-TYPE

SYNTAX  INTEGER

ACCESS  read-only

STATUS  mandatory

DESCRIPTION

"Unique Index consisting of card number."

::= { cardEntry 1 }

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.

How the ifIndex Value Specifies a Unique Port

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:

       portInfoIndex OBJECT-TYPE

              SYNTAX  INTEGER

              ACCESS  read-only

              STATUS  mandatory

              DESCRIPTION

                  "This is the ifIndex value of the corresponding

                  ifEntry.  See comments above."

              ::= { portInfoEntry 1 }

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:

((c * 1000) + p + t)

The variables in this formula are as follows:

c	The card number, an integer in the range 1 -- 11. A number in the range 1 -- 10 is the number of the physical slot in which the card resides. The number 11 represents the logical interface for the LS2020 ATM network.
p	The port number on the card, an integer in the range 0 -- 7. If c is 11 (the logical interface for the LS2020 ATM network), p must be 4.
t	An offset indicating the card type. This is an arbitrary numeric value assigned to each type of card. The values of t are as follows:
	100 200 0	Ethernet or Fiber Ethernet FDDI Other

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.

cli> getsnmp frCktInfoLclLMI.4002.16

Name: frCktInfoLclLMI.4002.16

Value: 2

cli>

frCktInfoLclLMI OBJECT-TYPE

SYNTAX   INTEGER {

active(1),

inactive(2)

}

ACCESS   read-only

STATUS   mandatory

DESCRIPTION

"This variable indicates the local LMI

state of the circuit."

::= { frCktInfo