Insight Management MIB README.

TXT This document contains information on how to use the files provided on the Management CD in the \TOOLKIT\MIBS directory. It is intended to give the reader experienced in SNMP management products a summary of the steps required to start using the Insight MIB as soon as possible. For more complete information, please refer to the Integrating Insight Manager with Enterprise Management Platforms Technote or the Integrating Insight Manager with ManageWise Technote. These and other Technotes are available located in the \DOCS\ENG directory and available on the HP World Wide Web server at http://www.hp.com. If you wish to get a bound hardcopy version of any of the Technotes, contact your Authorized HP Reseller. NOTE: The files described in this document and furnished on this CD are provided under a license agreement. They may be used or copied only in accordance with the terms of the agreement. TABLE OF CONTENTS 1.0 Introduction to the Insight Management MIB 2.0 Insight Management Information Base Organization 3.0 Concise MIB format 3.1 Groups 3.2 Data structures 3.2.1 Scalar Data Items 3.2.1.1 Basic Scalar Data Items 3.2.1.2 Defined Scalar Data Items 4.2.1.3 Access of Data Items 3.2.1.4 Status of Data Items 3.2.1.5 Description of Data Items 3.2.1.6 Scalar Item Definition Example 3.2.2 Table Data Items 3.2.2.1 Table Status 3.2.2.2 Table Index 3.2.2.3 Table Definition Example 4.0 Trap definitions

1.0 INTRODUCTION TO THE INSIGHT MANAGEMENT MIB This directory contains all the files necessary for integrating the Insight Management Information Base (MIB) into SNMP network management applications. HP provides these files for inclusion into SNMP network management applications such as SunNet Manager from SunConnect, HP OpenView Network Node Manager from Hewlett Packard, NetView for AIX from IBM and ManageWise from Novell. These files allow the user to integrate server management into an existing work group or enterprise management environment. For an in-depth tool to monitor your ProLiant servers, consider using Insight Manager 7, which provides a comprehensive management interface to the complete Insight MIB. Insight Manager 7 is an easy to use application based on the Microsoft Windows environment.

2.0 INSIGHT MANAGEMENT INFORMATION BASE ORGANIZATION The Insight Management MIB is a modular definition that follows IETF RFC 1212 for manageable objects and RFC 1215 for traps. Each piece of information is an object and related objects represent a group. The information in the MIB represents important device hardware and device software information. For example, the MIB includes server and component device information about the operation, performance, security and configuration of the devices. The Insight MIB is modular. The following table provides information about the different files that compose the Insight Management MIB. MIB File ============ CPQSTDEQ.MIB CPQSINFO.MIB CPQHOST.MIB CPQIDA.MIB CPQIDE.MIB CPQSCSI.MIB CPQSTSYS.MIB CPQHLTH.MIB CPQTHRSH.MIB CPQUPS.MIB CPQRECOV.MIB CPQSRVMN.MIB CPQSM2.MIB CPQCLUS.MIB CPQFCA.MIB CPQSTAT.MIB CPQNIC.MIB CPQAPLI.MIB CPQCR.MIB SRVCLU.MIB SRVNTC.MIB ETHER.MIB Description ===================================================== Standard PC Server Equipment information ProLiant Specific PC Server information Host Server Operating System information Intelligent Drive Array information IDE information SCSI Device information Storage Systems information Server Health information Settable Threshold information Uninterruptible Power Supply (UPS) information Recovery Server information Server Manager/R information Remote Insight and iLO information Cluster information Fibre Array information External Status information Network Interface Card information Server Appliance information CR3500 RAID Controller information Common Cluster Management information Cluster Management MIB version information RFC 1398 Ethernet NIC information

TOKEN.MIB

RFC 1231 Token Ring NIC information

The Insight MIBs represent an extension to the standard MIB information already defined in several standard MIB documents (for example, RFC 1213 or RFC 1271). These extensions offer additional information that will be available to any SNMP management application supporting the Insight MIBs. The Insight MIBs are defined to be modular. A series of MIBs address various aspects of the computer system. A standard equipment MIB provides information about the standard equipment of any Industry Standard PC (ISA or EISA). A ProLiant system specific MIB provides information about ProLiant specific extensions to the standard PC information. Other MIBs provide information about specific sub-systems developed by HP; for example Drive Array or Server Health sub-systems. Using the Insight MIBs in no way affects the standard information already available with SNMP or the access method for obtaining standard information. The Insight MIBs conform to the Concise MIB format (see section 3.0) and are suitable for use by most MIB compilers used to assimilate MIB documents. The main portion of the tree with respect to the HP instrumented management information is: (root) |-CCITT(0) |-ISO(1) | |-Org(3) | | |-DOD(6) | | | |-Internet(1) | | | | |-Directory(1) | | | | |-Mgnt(2) | | | | | |-MIB2(1) | | | | |-Experimental(3) | | | | |-Private(4) | | | | | |-Enterprises(1) | | | | | | |-Compaq(232) | | | | | | | |-cpqStdEquipment(1) | | | | | | | |-cpqSystemInfo(2) | | | | | | | |-cpqDriveArray(3) | | | | | | | |-cpqServerManager(4) | | | | | | | |-cpqScsi(5) | | | | | | | |-cpqHealth(6) | | | | | | | |-RESERVED(7) | | | | | | | |-cpqSsStorageSys(8) | | | | | | | |-cpqSm2(9) | | | | | | | |-cpqThresholdMgmt(10) | | | | | | | |-cpqHostOS(11) | | | | | | | |-cpqUps(12) | | | | | | | |-cpqRecovery(13) | | | | | | | |-cpqIde(14) | | | | | | | |-cpqCluster(15) | | | | | | | |-cpqFibreArray(16) | | | | | | | |-cpqExternalMgmt(17) | | | | | | | |-cpqNic(18) | | | | | | | |-cpqWinOsMgmt(19) | | | | | | | |-cpqApplianceMgmt(21)

|-cpqRackInfo(22)

Every piece of information is referred to by its full name so each piece of information can be unambiguously specified. Full names are commonly given in dotted decimal notation. Dotted decimal notation specifies all the branch numbers, separated by periods, needed to reach the particular item. For example the number 1.3.6.1.4.1.232.1 stands for the Standard Equipment MIB. All information in the Standard Equipment MIB will start with this prefix and then continue on to distinguish different pieces of information within the MIB. The name of each branch is specified in MIB documents. The number series, in parentheses after the name, is what is sent over the network in an SNMP packet when referring to a specific item in the tree. Sending a series of numbers specifying a tree location in a packet rather than a text description of the item as a name lessens network traffic. However, this protocol requires that both ends involved in the protocol understand the meanings of these code numbers and the structure of the information. This scheme requires a precise grammar to document the MIB structure to avoid confusion between the agent and the management station. The grammar typically used is called the Concise MIB format and is defined in RFC 1212. Further detail about the groups and objects provided by the HP Insight Management Agents is available in the comments within each MIB file. 3.0 CONCISE MIB FORMAT A few notes about the Concise MIB format should allow a reader to understand a MIB document without learning the full grammar. A comment is started by two consecutive dashes. All characters until the end of the line are ignored by a program processing the MIB. Comments are used to provide information to a reader. A MIB starts with a line that states the name of the MIB being defined. This is typically followed by an import statement. An import statement allows the MIB writer to specify information from other well known MIBs that are referred to in this MIB. The term END is used to signify the end of the MIB data definitions. For example: CPQSTDEQ-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises DisplayString OBJECT-TYPE ----END FROM RFC1155-SMI FROM RFC1213-MIB FROM RFC-1212;

This is a comment. Typically, structures for organizing managed items are defined here, followed by the definitions and descriptions of the managed items.

This example starts a MIB by the name of CPQSTDEQ-MIB. This MIB will use the term: enterprises as it is defined in RFC 1155, DisplayString as it is defined in RFC 1213, and OBJECT-TYPE as it is defined in RFC 1212. Three comment lines follow to show where managed items would be defined in a real MIB. Then the END statement terminates the MIB definition. 3.1 GROUPS A group definition specifies a name for a branch of the tree that contains sub-groups or specific pieces of information. Groups are used to organize related pieces of information. A group is defined by stating a name for the group and showing how it fits into the tree. To show how it fits into the tree the branch it will be placed under is named and the unique sub-branch number for this group is given. Typically, all group definitions are placed immediately following the IMPORTS statement. Some examples of group definitions are shown below. compaq cpqStdEquipment cpqSeMibRev cpqSeComponent cpqSeInterface cpqSeProcessor cpqSeMemory cpqSeIsaCmos cpqSeEisaNvram cpqSeRom cpqSeKeyboard cpqSeVideo cpqSeSerialPort cpqSeParallelPort cpqSeFloppyDisk cpqSeFixedDisk OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= { { { { { { { { { { { { { { { { enterprises 232 } compaq 1 } cpqStdEquipment 1 } cpqStdEquipment 2 } cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent cpqSeComponent 1 } 2 } 3 } 4 } 5 } 6 } 7 } 8 } 9 } 10 } 11 } 12 }

The group definitions above can be visualized as the following tree structure: (Enterprises) |-Compaq(232) | |-cpqStdEquipment(1) | | |-cpqSeMibRev(1) | | |-cpqSeComponent(2) | | |-cpqSeInterface(1) | | |-cpqSeProcessor(2) | | |-cpqSeMemory(3) | | |-cpqSeIsaCmos(4) | | |-cpqSeEisaNvram(5) | | |-cpqSeRom(6) | | |-cpqSeKeyboard(7) | | |-cpqSeVideo(8) | | |-cpqSeSerialPort(9) | | |-cpqSeParrallelPort(10) | | |-cpqSeFloppyDiskette(11) | | |-cpqSeFixedDisk(12)

A definition for enterprises is not needed here since enterprises has been defined elsewhere and imported. Anyone wishing to see its definition can refer to RFC 1155. Group numbers do not need to be consecutive. A particular Agent implementation may not support some of the groups. Some groups (such as cpqSeComponent) are intended for better organization. These groups have sub-groups below them, and do not directly reference any data (the data is in the sub-groups). These organizational groups will typically be given only a brief description since their role should be easily understood by the description of the sub-groups. When a group contains information immediately below it, all the items in the group will be described and defined. 3.2 DATA STRUCTURES There are two basic types of data: scalar items and tables. A scalar item is a single piece of information that is in a group. An example of a scalar is the total memory in a server. This offers unambiguous information without further qualifications. A table is a structure for organizing data that requires more information to uniquely identify a single data item within a group of similar items. An example of an item that is best organized in a table is an EISA board ID. The EISA board information is organized in the cpqSeEisaSlotTable, in the CPQSTDEQ.MIB file. The Board ID is only one piece of information in that table. Each item defined in the MIB (scalar or part of a table) has a description which explains what the item means and can help interpret the value of the item. 3.2.1 SCALAR DATA ITEMS The name of a data item, by convention, starts with a lower case letter. A SYNTAX clause specifies the type of information the item contains. There are two types, basic and defined types. 3.2.1.1 BASIC SCALAR DATA ITEMS Basic types are defined as part of the SNMP grammar and are represented in all capital letters. Examples include INTEGER and OCTET STRING. The INTEGER type specifies that the value of the item should be interpreted as a number. In some cases the word INTEGER will be followed by a range qualifier that restricts the possible values. In other cases the word INTEGER will be followed by an enumeration list that explicitly names the possible values and the meaning of each possible value. The OCTET STRING type specifies that the value of the item should be interpreted as a string of octets (bytes). The value of any particular octet (byte) within the string may be any value from zero to 255. A size qualifier may be given after the term OCTET STRING to limit the possible size (in bytes) of the value.

3.2.1.2 DEFINED SCALAR DATA ITEMS Defined types are defined by macros that refer to the basic types and start with a capital letter. Examples include Counter and DisplayString. A Counter is an INTEGER that has an implied range of zero to 4,294,967,295 (a hexadecimal value of FFFFFFFF). When a Counter equals the maximum value and is incremented again it will return to zero. A DisplayString is an OCTET STRING where each octet is restricted to be a printable ASCII character. Like the OCTET STRING from which this is derived, it may have a size qualifier. 3.2.1.3 ACCESS OF DATA ITEMS The ACCESS clause specifies the ways this item may be used. The ACCESS may be read-only, read-write, or not-accessible. Read-only means that the value of this item may be retrieved by a management application, but may not be altered. Read-write means this item may be read and/or altered by a management application. Not-accessible is given as the access for organizational constructs that do not represent data items. Not-accessible is only used for table features and should not be used for a scalar item. The ACCESS clause shows the actions the agent may support for the item. In practice this may be limited further by features or limitations of a particular agent implementation. 3.2.1.4 STATUS OF DATA ITEMS The STATUS clause specifies whether an agent is required to support this item if the agent supports this group. A status of mandatory means that this item will always be present if this group is supported. A status of optional means that a particular agent implementation has the option to support this item. A status of deprecated indicates that this item will not be supported by future agents. Deprecated objects stay in the MIB to maintain backward compatibility. 3.2.1.5 DESCRIPTION OF DATA ITEMS The DESCRIPTION clause contains a double quote delimited text description of the item. This description should give enough information for a reader to understand the significance of the information this item provides. 3.2.1.6 SCALAR ITEM DEFINITION EXAMPLE The item definition ends by specifying how the item fits into the MIB tree. The group the item belongs to is given followed by the unique branch number within the group for this item. Scalar item example: cpqSeMibRevMajor OBJECT-TYPE SYNTAX INTEGER (1..65535)

ACCESS read-only STATUS mandatory DESCRIPTION "The Major Revision level of the MIB. A change in the major revision level represents a major change in the architecture of the MIB. A change in the major revision level may indicate a significant change in the information supported and/or the meaning of the supported information, correct interpretation of data may require a MIB document with the same major revision level." ::= { cpqSeMibRev 1 } This example defines a scalar item named cpqSeMibRevMajor. This item is an INTEGER that may be read, but may not be changed by a management station. The cpqSeMibRevMajor item must be present if the group it belongs to (the cpqSeMibRev group) is supported. The cpqSeMibRevMajor item has a description to help a reader interpret the meaning of the value assigned to this item. The cpqSeMibRevMajor item is the member of the cpqSeMibRev group assigned the unique number one within the group. 3.2.2 TABLE DATA ITEMS Tables introduce the concept of constructed types. There are two operators that allow for organization of the standard types, the SEQUENCE operator and the SEQUENCE OF operator. A table uses both of these operators. The SEQUENCE operator allows the definition of a new type that consists of several standard types in a specific order. This is very similar to the concept of a structure or a record found in most programming languages. The SEQUENCE OF operator allows the definition of a list of zero or more of the same type of elements. The number of elements is not specified, but a means of uniquely identifying each element is given by providing an indexing scheme. This is very similar to the concept of a dynamic array found in most programming languages. A table entry is defined a SEQUENCE. A table is defined as a SEQUENCE OF the table entry type. Table entry variables are defined after they are referenced in a table definition. The Concise MIB format is case sensitive and there are several conventions on the use of upper and lower case letters. The name used for the entry type and the variable of that type differ only by the case of the first letter. It is conventional to start types with an upper case letter and items (the variables) with a lower case letter. 3.2.2.1 TABLE STATUS The STATUS of the table and the table entry is not-accessible. There is no data that is uniquely referred to by the name of the table or entry so the concept of reading (or writing) the value of a table or entry is meaningless. Tables and entries are useful for organizing and defining a MIB, but SNMP commands only allow the manipulation of simple items

(scalars and the items that are part of the SEQUENCE in a table entry). 3.2.2.2 TABLE INDEX The INDEX clause specifies the items that are used to uniquely identify an element in the table. An index may simply be a unique number assigned to an entry that has no specific meaning except to the agent or it may have some intrinsic meaning. 3.2.2.3 TABLE DEFINITION EXAMPLE Here is an example of a table definition. It defines the table as a SEQUENCE OF the CpqSeCpuEntry type that will be defined below. cpqSeCpuTable OBJECT-TYPE SYNTAX SEQUENCE OF CpqSeCpuEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of the CPUs (processors) in the system. The main processor (if such a concept is valid for this machine) should be the first entry in the table." ::= { cpqSeProcessor 1 } Here is an example of an entry definition. It defines an item of the cpqSeCpuEntry type. It also describes the field used to uniquely identify entries in the table. No two table entries will have the same values for the cpqSeCpuUnitIndex field. cpqSeCpuEntry OBJECT-TYPE SYNTAX CpqSeCpuEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A description of a CPU (processor) in the system." INDEX { cpqSeCpuUnitIndex } ::= { cpqSeCpuTable 1 } CpqSeCpuEntry ::= SEQUENCE { cpqSeCpuUnitIndex INTEGER, cpqSeCpuSlot INTEGER, cpqSeCpuName DisplayString, cpqSeCpuSpeed INTEGER, cpqSeCpuStep INTEGER, cpqSeCpuStatus INTEGER } The following four definitions are the four scalar items that form the fields of the CpqSeCpuEntry type. cpqSeCpuUnitIndex OBJECT-TYPE SYNTAX INTEGER (0..65535)

ACCESS read-only STATUS mandatory DESCRIPTION "This is a number that uniquely specifies a processor unit. A processing unit may be a set of processing chips that are on the same board or for other reasons work together as a unit. The main processor unit (if such a concept is valid for this machine) will always have the lowest (first) index." ::= { cpqSeCpuEntry 1 } cpqSeCpuSlot OBJECT-TYPE SYNTAX INTEGER (0..255) ACCESS read-only STATUS mandatory DESCRIPTION "This value represents this processor's slot. If the slot cannot be determined the value of zero (0) will be returned." ::= { cpqSeCpuEntry 2 } cpqSeCpuName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "The name of this processor. For example: 80386" ::= { cpqSeCpuEntry 3 } cpqSeCpuSpeed OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The clock speed (in megahertz) of this processor. Zero will be returned if this value is not available." ::= { cpqSeCpuEntry 4 } cpqSeCpuStep OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The step of the processor. This will be zero (0) if the step cannot be determined." ::= { cpqSeCpuEntry 5 } cpqSeCpuStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), ok(2), degraded(3), failed(4) }

ACCESS read-only STATUS mandatory DESCRIPTION "The status of the processor." ::= { cpqSeCpuEntry 6 }

The previous definitions describe a tree structure as follows: (cpqSeProcessor) |-cpqSeCpuTable(1) |-cpqSeCpuEntry1 |-cpqSeCpuEntry2 |. |. |-cpqSeCpuEntryN Each processor entry is organized as follows: cpqSeCpuEntryN |-cpqSeCpuUnitIndex(1) |-cpqSeCpuSlot(2) |-cpqSeCpuName(3) |-cpqSeCpuSpeed(4) |-cpqSeCpuStep(5) |-cpqSeCpuStatus(6) As an example, to get the clock speed of a Server's second processor, a management application would request the object with an ASN.1 notation of 1.3.6.1.4.1.232.1.2.2.1.4.2. The final 2 is the cpqSeCpuUnitIndex value for the second processor. 4.0 TRAP DEFINITIONS A MIB may also contain trap definitions. A trap is a notification sent by the SNMP agent to a management station. The trap is sent to inform the management station about an event that has occurred on the managed system. Traps may also be referred to as alerts or alarms. The trap definition begins with the name of the trap followed by the term TRAP-TYPE. An ENTERPRISE clause follows to indicate the MIB in which this trap is defined. An optional VARIABLES clause may be included to specify additional information that will be sent in the trap. The additional information will be items defined in the MIB shown in the ENTERPRISE clause. When a variable is included in a trap, both its name and its value are sent with the trap. If a variable is a data item within a table, the name will contain the index field(s). This saves the trouble of sending along the index fields explicitly as additional variables. A DESCRIPTION clause will follow explaining the significance of the trap and the conditions that would cause it to be sent. Finally, the trap is given a number to identify it. This number will be

unique within the scope of the ENTERPRISE. Both the enterprise name and the trap number are used by the management station to uniquely identify the trap received. Trap example: cpqDa2PhyDrvStatusChange TRAP-TYPE ENTERPRISE compaq VARIABLES { cpqDaPhyDrvStatus, cpqDaPhyDrvBusNumber } DESCRIPTION "Physical Drive Status Change. This trap signifies that the Insight Agent has detected a change in the status of a Drive Array physical drive. The variable cpaDaPhyDrvStatus indicates the current physical drive status. The variable cpqDaPhyDrvBusNumber indicates the SCSI bus number associated with this drive." --#TYPE "Physical Drive Status Change" --#SUMMARY "Status is now %d for a physical drive on bus %d." --#ARGUMENTS {0,1} --#TIMEINDEX 99 ::= 3003 This example defines a trap named cpqDa2PhyDrvStatusChange. This is trap number 3003 in the Compaq enterprise. This trap is sent by the agent responsible for the CPQIDA MIB. The current value of the cpqDaPhyDrvStatus and the cpqDaPhyDrvBusNumber items is also included in the trap packet. The comment section within the trap defines additional information, used by Novell's NetWare Management Services console, to display upon receiving a Compaq enterprise trap. In this example, the comments describe the trap type (--#TYPE "Physical Drive Status Change"), a summary (--#SUMMARY "Status is now %d for a physical drive on bus %d."), the arguments to display within the summary statement (--#ARGUMENTS {0,1}), and an indication about the time parameter to use (--#TIMEINDEX 99). Note: The additional comments in the trap section specific for NetWare Management Services does not impact the functionality of how any SNMP compliant management console, such as SunConnect's SunNet Manager or HP's OpenView, interacts with traps generated by the Insight Agents. Traps are defined in the last section of the MIBs. Refer to the actual trap definitions for more information about the traps generated by the Insight Management Agents. ______________________________________________________________________ Copyright 1992,2005 Hewlett-Packard Development Company, L.P. Hewlett-Packard Company shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for HP products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.

Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. NetWare is a trademarked product of Novell, Inc. Windows is a trademark of Microsoft Corporation.