C H A P T E R 5 |
Simple Network Management Protocol |
This chapter describes the Netra CT server Simple Network Management Protocol (SNMP) support, and provides a useful example. This chapter contains the following sections:
The most widespread legacy architecture for network and device management is SNMP, for which the Java DMK provides a complete toolkit. This gives you the advantages of developing both Java Dynamic Management agents and managers that are interoperable with existing management systems.
SNMP network protocol enables devices to be managed remotely by a Network Management Station (NMS). To be managed, a device must have an SNMP agent associated with it. The agent receives requests for data representing the state of the device and provides an appropriate response. The agent can also control the state of the device. Additionally, the agent can generate SNMP traps, which are unsolicited messages sent to selected NMSs to signal significant events relating to the device.
The Sun Netra SNMP Management Agent is an intelligent SNMP v2 agent for continuously monitoring key hardware variables. You can generate and collect value-add reports collected by remote monitoring. Using Sun Netra SNMP Management Agent's generic management interface and comprehensive event mechanisms, you can dynamically build configuration and health status data, thus reducing development costs.
To manage and monitor devices, the characteristics of the devices must be represented using a format known to both the agent and the NMS. These characteristics can represent physical properties such as fan speeds, or services such as routing tables. The data structure defining these characteristics is known as a Management Information Base (MIB). This data model is typically organized into tables, but can also include simple values. An example of the former is routing tables, and an example of the latter is a timestamp indicating the time at which the agent was started.
A MIB is a text file, written in abstract syntax notation one (ASN.1) notation, which describes the variables containing the information that SNMP can access. The variables described in a MIB, which are also called MIB objects, are the items that can be monitored using SNMP. There is one MIB object for each element being monitored. All MIBs are, in fact, part of one large hierarchical structure, with leaf nodes containing unique identifiers, data types, and access rights for each variable and the paths providing classifications. A standard path structure includes branches for private subtrees.
For reference, the structure of the MIBs for SNMPv2 is defined by its Structure of Management Information (SMI) defined in the RFC2578 document. This SMI defines the syntax and basic data types available to MIBs. The Textual Conventions (type definitions) defined in the RFC2579 document define additional data types and enumerations.
Before an NMS can manage a device through its agent, the MIB corresponding to the data presented by the agent must be loaded into the NMS. The mechanism for doing this varies depending on the implementation of the network management software. This gives the NMS the information required to address and correctly interpret the data model presented by the agent. Note that MIBs can reference definitions in other MIBs, so to use a given MIB, it might be necessary to load others.
The MIB defines a virtual datastore accessible by way of the SNMP software, the content being provided either by corresponding data maintained by the agent, or by the agent obtaining the required data on demand from the managed device. For writes of data by the NMS to this virtual data, the agent typically performs some action affecting the state either of itself or the managed device.
To address the content of this virtual datastore, the MIB is defined in terms of object identifiers (OIDs) which uniquely identify each data entry. An OID consists of an hierarchically arranged sequence of integers providing a unique name space. Each assigned integer has a associated text name. For example, the OID 1.3.6.1 corresponds to the OID iso.org.dod.internet and 1.3.6.1.4 corresponds to the OID iso.org.dod.internet.private. The numeric form is used within SNMP protocol transactions, whereas the text form is used in user interfaces to aid readability. Objects represented by such OIDs are commonly referred to by the last component of their name as a shorthand form. To avoid confusion arising from this convention, it is normal to apply a MIB-specific prefix, such as netract, to all object names defined therein.
All addressable objects defined in the MIB have associated maximum access rights (for instance, read-only or read-write), which determine what operations the NMS permits the operator to attempt. The agent can limit access rights as required; that is, it is able to refuse writes to objects that are considered read-write. This refusal can be done on the grounds of applicability of the operation to the object being addressed, or on the basis of security restrictions that can limit certain operations to restricted sets of NMS. The mechanism used to communicate security access rights is community strings. These text strings, such as private and public, are passed with each SNMP data request.
Much of the data content defined by MIBs is of a tabular form, organized as entries consisting of a sequence of objects (each with their own OIDs). For example, a table of fan characteristics could consist of a number of rows, one per fan, with each row containing columns corresponding to the current speed, the expected speed, and the minimum acceptable speed. The addressing of the rows within the table can be a simple single dimensional index (a row number within the table, for example, 6), or a more complex, multidimensional, instance specifier such as an IP address and port number (for example, 127.0.0.1, 1234). In either case, a specific data item within a table is addressed by specifying the OID giving its prefix (for example, myFanTable.myFanEntry.myCurrentFanSpeed) with a suffix instance specifier (for example, 127.0.0.1.1234 from the previous example) to give myFanTable.myFanEntry.myCurrentFanSpeed.127.0.0.1.1234.
Each table definition within the MIB has an INDEX clause that defines which instance specifiers to use to select a given entry. The SMI defining the MIB syntax provides an important capability whereby tables can be extended to add additional entries, effectively adding extra columns to the table. This is achieved by defining a table with an INDEX clause that is a duplicate of that of the table being extended.
The Netra CT software uses these SNMP MIBs to present the network information model:
The ENTITY-MIB is defined by the IETF standard RFC2037. The ENTITY-MIB provides a mechanism for presenting hierarchies of physical entities using SNMP tables.
The Netra CT information model uses the ENTITY-MIB to provide:
This information is presented using SNMP tables:
This table contains one row per hardware resource. These rows are called entries, and a particular row is referred to as an instance. Each entry contains the physical class (entPhysicalClass) and common characteristics of the hardware resource. Each entry has a unique index (entPhysicalIndex) and contains a reference (entPhysicalContainedIn) that points to the row of the hardware resource which acts as the container for this resource.
FIGURE 5-1 and TABLE 5-1 show how an example hierarchy of hardware resources are presented using the ENTITY-MIB.
The Netra CT Management Agent uses values for entPhysicalIndex and ifIndex that might not be contiguous, but are within the range of permitted values.
The IF-MIB is defined by the IETF standard RFC 2863. The IF-MIB provides information about the network interfaces of the server. The information is presented using the ifTable. The ifTable contains a row for each network interface. The ifTable includes columns which describe the interface (ifDescr), indicate the type of interface (ifType), and the indicate the status of the interface (ifOperStatus).
The Host-Resources-MIB is defined in RFC 2790.
The Host Resources Running Software Table (hrSWRunTable) contains information about the software that is running on the network element (for example, NFS, TFTP, and CGTP). When an application or daemon under the monitor is running, the MOH Software Module adds an entry into the hrSWRunTable and will send to the client the netraCtRunningSwCreated trap. When an application or a daemon stops running, the MOH Software Module sends the netraCtRunningSwChanged trap with hrSWRunStatus is invalid. The MOH Software Module only deletes the entry from the hrSWRunTable and sends the netraCtRunningSwDeleted trap when the service is uninstalled from the system.
The Host Resources Installed Software Table (hrSWInstalledTable) contains information about the software installed on the network element (for example, installation packages related to NFS, CGTP, and so on). netraCtInstalledSwCreated, netraCtInstalledSwDeleted and netraCtInstalledSwChanged are traps sent to the client corresponding to the software package installed event, software package uninstalled event, and different version of the existing software package installed event.
This section describes the SUN-SNMP-NETRA-CT-MIB, which is the SNMP version of the Netra CT network element view.
A brief description of each of the groups that comprise the MIB module is provided in the following subsections:
For more information, refer to the MIB file that is available as part of the software package at the default location:
/opt/SUNWnetract/mgmt2.0/mibs/SUN-SNMP-NETRA-CT-MIB.mib
The SUN-SNMP-NETRA-CT-MIB module representation of high-level objects in the Netra CT network element (NE) is composed of the elements in TABLE 5-2:
The Netra CT Physical Path Termination Point Table extends the entPhysicalTable. Each entry of this table represents a Physical Path Termination Point within the Netra CT NE. The SUN-SNMP-NETRA-CT-MIB module representation of a physical path termination point is composed of the elements shown in TABLE 5-3:
The Netra CT Equipment Table extends the entPhysicalTable. Each entry in this table represents a piece of equipment within the Netra CT NE that neither is nor accepts a replaceable plug-in unit. The SUN-SNMP-NETRA-CT-MIB module representation of an equipment is composed of the elements shown in TABLE 5-4:
The Netra CT Equipment Holder table extends the entPhysicalTable. Each entry in this table represents a component within the Netra CT NE that accepts a replaceable plug-in unit. The SUN-SNMP-NETRA-CT-MIB module representation of an equipment holder is composed of the elements shown in TABLE 5-5:
The Plug-In Unit Table extends the entPhysicalTable. Each entry of this table represents a piece of equipment within the Netra CT NE that is inserted into and removed from an Equipment Holder. The SUN-SNMP-NETRA-CT-MIB module representation of a plug-in unit is composed of the elements shown in TABLE 5-6.
The Netra CT Hardware Unit to Running Software Relationship Table describes the software that is running on each hardware unit in the Netra CT NE. Each entry of this table identifies an entry in the entPhysicalTable and one in the hrSWInstalledTable.
The SUN-SNMP-NETRA-CT-MIB hardware unit to running software relationship table is composed of the elements shown in TABLE 5-7.
The Netra CT Hardware Unit to Install Software Relationship Table describes the software that is installed on each hardware unit in the Netra CT NE. Each entry of this table identifies an entry in the entPhysicalTable and one in the hrSWInstalledTable. The SUN-SNMP-NETRA-CT-MIB hardware unit to installed software relationship table is composed of the elements shown in TABLE 5-8.
The SUN-SNMP-NETRA-CT-MIB alarm severity identifier textual conventions consist of the elements shown in TABLE 5-9.
The Netra CT alarm severity profile table specifies which profiles exist. Creating or deleting an entry in this table automatically creates or deletes the corresponding entries in the netraCtAlarmSeverityTable. Each entry of this table represents a group of severities, one for each alarm type in the communications alarm group. The
SUN-SNMP-NETRA-CT-MIB alarm severity profile table consists of the elements shown in TABLE 5-10.
This object is used to create a new row or to delete an existing row in the table. |
The Netra CT alarm severity table associates profile index and trap ID pairs with severities to be used for Netra CT alarm traps that have occurred. (Note that this table does not apply to cleared alarms). An entry in this table associates an alarm severity profile index and trap ID pair with a severity. Deleting a particular profile's row in the alarm severity profile table deletes all rows in this table with the same profile index. Conceptually, rows corresponding to all possible trap IDs are created in this table when a new alarm severity profile is created, but the agent returns a default value except for those few traps for which values have been set. The alarm severity table elements are listed in TABLE 5-11.
The Netra CT Trap forwarding discriminator table specifies which traps will be sent to which management system. Each entry of this table contents information about a group of traps to be sent to a particular IP address. This is used as the value of the object netraCtForwardedTrapObject when traps from all objects are to be forwarded, or when there is only one object of the type that forwards the specified trap type. The elements for this table are shown in TABLE 5-12.
MIB notification types consist of auxiliary definitions for alarms. Except for perceived severity, the objects shown in TABLE 5-13 can be optionally appended to any alarm notification.
The SNMP management software has the ability to send traps, or messages, to an application when one or more conditions have been met. Generally, a trap is an unsolicited network packet sent from an agent that usually reports some unexpected error condition.
TABLE 5-14 describes the SNMP traps found in the Netra CT SNMP MIB.
TABLE 5-15 defines the standard SNMP traps found in the RFC123-MIB.
TABLE 5-16 defines the MIB elements used in MIB module descriptions in the sections of the MIB file. For detailed information about these elements, refer to the RFC2578 document, which can be downloaded from the http://www.ietf.org web site.
Note - Not every MIB element is present for every MIB module. |
For a complete description, see the MIB module in the default location
/opt/SUNWnetract/mgmt2.0/mibs/SUN-SNMP-NETRA-CT-MIB.mib, delivered as part of the Netra CT software package.
This section shows how to change the locationName part of FRU-ID.
The Netra CT midplane stores the locationName, which is the geographical location of the system, for example, chassis6. This value is stored in the alarm card flash and can be set by the customer. The locationName enables system monitoring applications to report specific details.
This example uses a NET-SNMP application to interact with MOH and set the midplane's location to a particular value.
1. Determine the index of the midplane object from the entPhysicalTable.
At the prompt, type the command:
-c community specifies the community string.
-m SUN-SNMP-NETRA-CT-MIB specifies that the Netra CT MIB should be loaded.
hostName is the development system running MOH.
This process and its results are shown in CODE EXAMPLE 5-1
2. Set the midplane location to the new value of chassis6 using the following command:
3. Show the current value of the midplane's location.
At the prompt, type the command:
The result displays the identifying string of the location of any Netra CT equipment locations, as shown in CODE EXAMPLE 5-2.
An alarm in SNMP is defined as a trap with a severity associated with it. When a HIGH_TEMPERATURE alarm (CPU high temperature) occurs, the user's application will receive the SNMP trap netraCtHwHighTempAlarm, and netraCtIfChanged trap for the ifOperStatus of the interface corresponding to the alarm output port. The user's application also will receive alarm clear traps when the condition of alarms are cleared, and an attribute change trap of the ifOperStatus.
The Netra CT alarm card supports three output alarm interfaces. The alarm pins (alarm0, alarm1, alarm2) are statically mapped into severities of critical, major, minor respectively. When an alarm occurs, the corresponding alarm pin is driven high according to the severity of the alarm.
The following example shows how to set the high temperature alarm from the default to major.
|
1. Create an entry in the netraCtAlarmSevProfileTable.
At the prompt, type the command:
-c community specifies the community string.
-m SUN-SNMP-NETRA-CT-MIB specifies that the Netra CT MIB should be loaded.
hostName is the development system running MOH.
This process and its result are shown in CODE EXAMPLE 5-3.
Creating an entry in the netraCtAlarmSevProfileTable also creates an entry in the netraCtAlarmSevTable. The entry in the latter corresponds to the profile entry and translates the high temperature alarm entry into the row of integers shown in CODE EXAMPLE 5-4.
2. Set the severity of netraCtHighTempAlarm for this profile.
At the prompt, type the command:
$ snmpset -c public -m SUN-SNMP-NETRA-CT-MIB localhost:9161\ netraCtAlarmSeverity.1.15.1.3.6.1.4.1.42.2.65.1.1.1.2.0.34 = 2 |
1.3.6.1.4.1.42.2.65.1.1.1.2.0.34 represents the string `netraCtHighTempAlarm'
The entry at = (in this example, 2) establishes a major alarm severity.
The result is shown in CODE EXAMPLE 5-5.
3. Set netraCtEquipAlarmSeverityIndex of the thermistor entry to correspond with the netraCtAlarmSevProfile entry from the netraCtAlarmSevProfileTable.
At the prompt, type the command:
This example uses the netraCtAlarmSevProfileTable entry from CODE EXAMPLE 5-3. The index of that entry was the integer 1 in the statement: netraCtAlarmSevProfileRowStatus.1. The result of this process is shown in CODE EXAMPLE 5-6.
When the CPU temperature returns to normal, the alarms are cleared automatically. For further information, refer to SUN-SNMP-NETRA-CT-MIB.
Copyright © 2004, Sun Microsystems, Inc. All Rights Reserved.