test

Solstice Enterprise Agents 1.0 User Guide

Chapter 6 Using SNMP With DMI

6.1 Using SNMP With DMI Overview

Solstice Enterprise Agents (SEA) technology enables management applications that communicate with SNMP to access DMI-enabled components through a DMI mapper called snmpXdmid. SNMP uses protocol data units to send information between management applications and agents distributed in the network. A standard MIB describes all objects that are managed by SNMP management applications. The agent programs supply or change the values of MIB objects, as requested by the management applications.

The DMI mapper snmpXdmid provides a mapping function that dynamically translates DMI information into the SNMP MIB format for communication with SNMP management applications. An SNMP management application may send requests to snmpXdmid, that in turn converts the SNMP requests into DMI requests. The conversion is performed again, in reverse, when the DMI response is returned. This enables the SNMP management application to participate in active management of DMI-enabled components.

This chapter describes how DMI and SNMP work together, and how to map data between SNMP MIB and DMI MIF.

Figure 6-1 illustrates how snmpXdmid works with other parts of the Solstice Enterprise Agents product.

Figure 6-1 snmpXdmid Overview

Graphic

6.2 SNMP Communication With the DMI

The communication path between an SNMP management application and the DMI consists of the SNMP Master Agent and the DMI mapper snmpXdmid, as described in the following sections.

6.2.1 SNMP Master Agent

The SNMP Master Agent handles SNMP requests and responses between management applications and registered subagents in your system. The snmpd executable file installed with Solstice Enterprise Agents replaces any snmpd file that may already be installed in your system.

The SNMP Master Agent communicates with subagents in the system through SNMP PDUs. A process acting as a subagent may register a MIB subtree with the SNMP agent. Any request received by the Master Agent for a registered variable is passed through snmpdXdmid to the subagent, then performs the request and returns a response to the Master Agent.

6.2.2 DMI Mapper

The DMI mapper handles requests from and responses to the SNMP Master Agent in the system. When it receives a request, such as an SNMP Get request for a specific MIB variable, the mapper translates the MIB variable into a corresponding DMI MIF attribute. Indications sent by DMI components in the system are then converted to SNMP traps and sent to the management application. Translation of MIB variables into MIF attributes and indications into traps are performed only for those components that the mapper has registered with the SNMP Master Agent.

6.3 Registering a Component With the SNMP Master Agent

To enable mapping of a component by snmpXdmid, the component's MIF file must correlate with an SNMP object identifier (OID) prefix. The OID prefix is a registration point that identifies the DMI component to the SNMP Master Agent.

The correlation of OID to component is performed by adding an entry for the component to the mapping file. The format of the .MAP file is explained in "6.6.3 MIF-to-MIB Mapping". The .MAP files for the Solaris environment are located in the /var/dmi/map directory.

Note -

For the DMI mapper to perform the mapping properly, make certain that the component name field in the mapping file entry corresponds exactly to the value of the name statement specified for the component in the MIF file. This includes such aspects as spacing and the character case in the string.

If any changes are made to the mapping file, one of the following actions must be taken for the DMI mapper to operate with current mapping information:

Note -

If the same component name is repeated in the mapping file with different enterprise IDs, the DMI Mapper maps the component twice.

6.4 Running the DMI Mapper on Solaris

When running the DMI mapper snmpXdmid in a Solaris environment, the proper flow of SNMP information must be insured by:

The snmp.conf file contains a description of the format for entries and provides instructions for adding entries. The snmp.conf file is located in the /etc directory.

6.5 How the DMI Mapper Works

The subagent registers the DMI components in the system with the SNMP Master Agent. Proper mapping on the part of the mapper requires that the MIF structure of a component be identified in a mapping file used by the subagent when it is processing requests from the SNMP agent. The mapping file contains a unique SNMP OID for the component. The OID is used as a registration point for the Master Agent.

To generate the mapping file, perform one of the following tasks:

The operational process of the subagent has the following states:

These states provide a general operational flow. The mapper snmpXdmid runs as a daemon. Normally, it waits for SNMP requests. On arrival of the request, it processes the request, returns the response, then continues to wait for further SNMP requests. This mapper also receives indications from the DMI SP. These are then forwarded by default as SNMP traps.

6.5.1 Initializing and Reinitializing the Subagent

The mapper normally starts at the system boot time through startup scripts. The mapper startup must be performed in the later stages of system startup. This enables the SNMP Master Agent and DMI (SP) to be initialized. Dynamic registration then takes place between snmpXdmid and both the Master Agent and the DMI SP.

  1. The mapper uses the Management Interface (MI) registration call to register itself with the Service Provider (SP) before any other management activity may be initiated.

    This enables the SP to provide services (such as access to the MIF database). The mapper also adds an entry in the subscription table/filter table on the SP to receive indications.

  2. The mapper builds the translation table.

    The translation table retains a Master Agent registration point for each unique pair of SNMP OID prefix and component names it finds in the .MAP files. When constructing these translation tables, the mapper searches all .MAP files in the /var/dmi/map directory.

    Identifiers for these components, along with group identifiers associated with each component, are retained for translation. Attributes of installed components not found in a .MAP file by the program are inaccessible by the SNMP agent. Whenever a component is installed or uninstalled, the translation tables are appropriately adjusted.

    The mapper re-reads all the map files when a new component is registered with the SP to insure that the translation tables are always current.

  3. The mapper connects to the Master Agent.

    Before the communication may take place for this connection, the mapper must establish a connection and register with the Master Agent.

    Registration is achieved by using the following definitions:

    • Subagent ID

    • Agent status = ACTIVE

    • Timeout value

    • Subagent name

    • Subagent address

  4. At this point, the agent registers the object ID for the MIB for which it is responsible.

    The MIB OID prefixes that have been retrieved from the .MAP files are used for registration. OID prefixes associated with component names for which there are no installed components may also be registered.

    On initialization, if the DMI and its interfaces are functional, and the translation table is correct, a cold-start trap is sent to the agent. Refer to "6.6.1 Exception Reporting"for more information on trapping.

    Reinitialization occurs upon detection of a severe or potentially severe error. This may be an error in communicating with either DMI or the Master Agent. On reinitializing DMI, Master Agent, and table initialization, a warm-start trap is sent to the Master Agent.

6.6 Converting SNMP Requests to DMI

When the SNMP Master Agent receives a request it determines whether the object is within the subtree registered the mapper. If it is, it then sends the mapper an SNMP request. Upon receiving a packet, the mapper parses the packet according to the following types:

Conversion of an SNMP request to DMI is shown in Table 6-1.

Table 6-1 SNMP Request to DMI Conversion

SNMP 

Object 

DMI 

Data 

{verb}

{noun}

{verb}

{noun}

get

OID

MI_cmds

ID and Key

getnext

comp ID/group ID/attr ID

set/commit/undo

Access to the MIF database is enabled through a set of MI commands used to query for lists of components, groups or attributes, and to Get or Set the individual attributes.

When the mapper receives a GET request from the Master Agent, the mapper:

  1. Determines whether the request is for the MIF or MIB, depending on whether it finds an entry in the translation table.

  2. Parses the remainder of the OID, checking for validity.

  3. Searches the translation table for presence of the specified group and component.

  4. Translates the DMI table index (if specified) in the OID into a DMI key format.

  5. Attempts to retrieve the object value from the DMI. The subagent then gives the object value returned to the agent.

In processing GETNEXT requests, the subagent must make certain that lexicographical ordering is maintained. The MIF database may undergo considerable searching before arriving at the attribute returned as an SMI object. If the value of the target attribute is unavailable because of a minor error (for example, specific to that attribute), a genErr prescribed by /RFC1448/ is returned. If the next object is not in the subagent's tree, the same object instance as in the request is returned and the value noSuchName is returned.

DMI attribute identifiers are encoded into unique OIDs. The INDEX clause is used to access DMI table objects and identifies a DMI table row. When DMI table attributes are examined during a GETNEXT, all row identifiers (key values) are examined to insure lexicographic order.

Handling of the SET request by the Master Agent is a bit more involved than the GET request. The normal command sequence is a GET followed by a SET command from the agent. In the event the agent may not successfully complete all the SETs for a given SNMP PDU, it sends the subagent another SET command with oi.d values obtained from the GET command. When it receives the SET command, the subagent makes some basic checks, such as confirming existence of the object and instance, correct value type, valid contents, and availability of memory needed for the operation. At this point, the call to the DMI with a DmiSetAttribute() to RESERVE the attributes is complete. The RESERVE is used to validate a SET without performing the SET. A RESERVE failure results in a genErr being returned to the Master Agent. Otherwise, the subagent performs DmiSetAttribute() with the SET option, to perform the actual set.

If another subagent has informed the SNMP agent it may not perform the SET of that PDU, the agent then gives a SET to this mapper, with older values.

6.6.1 Exception Reporting

The Master Agent enables the mapper to report traps to the agent by building a Master Agent trap PDU and sending it to the agent.

The trap is caused by an unsolicited message known as an INDICATION from the DMI SP. If these indications are from the component, they are called events. The mapper receives all indications after it has subscribed to the SP by adding an entry into its subscription table. The mapper also sets the filter conditions for receiving every type of event. Because the mapper is already waiting for requests from the agent, this routine is a separate thread. The subagent determines what OIDs are sent with the trap. The following list describes the different types of indications.

6.6.2 Terminating the Subagent

Normally, the snmpXdmid daemon runs forever, unless explicitly killed or a disastrous situation is encountered (for example, lack of memory).

6.6.3 MIF-to-MIB Mapping

The mapping of MIF to MIB involves the assignment of an OID from the MIF. A translator (miftomib.EXE) is available to build a file extension of .MAP and a .MIB file from a MIF definition. The translator may be used as a tool to generate the .MIB and the .MAP files. Or, the map file may be generated manually, using a text editor. All .MAP files located in the directory under /var/dmi/map are scanned and included in the subagent translation table.

Figure 6-2 MIF-to-MIB Mapping

Graphic

The map file format is shown in Table 6-2.

Table 6-2 Map File Format

OID Prefix 

Component Name 

"1.3.6.1.4.1.42.2000.2" 

"Client Access/400 Family - Base Product" 

The design approach is to map the DMI component ID, group ID, and attribute ID to MIB object IDs. The managing entity must predetermine the MIB definition to be used by the mapper to map to the MIF definition. Using a miftomib translator to produce the MIB mapping file facilitates the mapping.

The map file is generated externally to the mapper. A mechanism is required to notify the mapper of new or updated files on the system in order to enable the new MIF definitions to be dynamically added. This is accomplished by using the DmiGroupAdded indication, delivered by dmispd, when the mapper rereads all the .MAP files.

See Figure 6-3 for examples of the OID prefix and the completed OID layout. The mapping file is used by the mapper to register the OID with the SNMP agent relay and to correlate the OID with the component name. It contains the component ID and the group keys, in case the group contains tabular data.

The mapper puts no restriction on what the OID prefix may be. That is controlled by the network administrator. Any OID may be entered into a .MAP file, provided the SNMP Master Agent allows the subtree registration. In the case of failure, the .MAP file needs to be changed for the OID correction.

Figure 6-3 MIB OID Layout

Graphic

Parts of the object identifier are shown below:

The example in Table 6-3shows OIDs for client access attributes (no keys).

Table 6-3 OIDs for Client Access Attributes

Object Identifier:  

OID-prefix 

OID for Groups 

Object-type for Table 

Object-type for Row 

Attribute Identifier: Object-type for Column 

Instance Identifier: Indexes 

1.3.6.1.4.1.42.2000.x

.1

.1

.1

.1

.3

Retrieving objects via the GetNext operation must be specially handled, since MIB tables are traversed column-by-column and MIF tables are traversed row-by-row.

6.6.4 Specific Mapping Considerations

The DMI specification has reserved ComponentId=1 for the DMI SP. The specification also defines the MIF file for the SP. The network administrator must take this into consideration when creating the .MAP files or when specifying the OID preference as a command-line parameter to the miftomib utility. Every MIF file must contain a standard group with ID 1.

Table 6-4 ComponentID Group Translated to DMI MIB

MIS Object Identifier and 

SYNTAX 

MIF Data 

Description 

Notes 

DMIcompindex

INTEGER (1...217483647) 

Component ID 

Unique value for component 

Assigned at installation by the SP, it communicates with this component until uninstalled; managing applications record this ID to request attributes later 

DMIcompManufacture

DisplayString (0...64)  

Attribute "Manufacture" 

Value assigned by the component provider 

The name of the organization that produced this component 

DMIcompProduct

DisplayString (0...64) 

Attribute "Product" 

Value assigned by the component provider 

Name of the component 

DMIcompVersion

DisplayString (0...64) 

Attribute "Version" 

Value assigned by the component provider 

Version of the component 

DMIcompSerialnumber

DisplayString (0...64) 

Attribute "Serial Number" 

Value assigned by the component provider 

Serial number of component 

DMIcompInstallation

Date  

Attribute "Installation" 

Value assigned by the SP at installation time 

28-octet displayable string composed of date and time 

DMIcompVerify

Integer (0...7) 

Attribute "Verify" 

Verification level of this component at installation time 

A request for this attribute causes the component to find out if it is still in the system and working properly 

With this mapping, any MIF that is installed with the DMI has at minimum the ComponentID Group visible to management applications. All attributes within this group have read-only access. As MIFs become standard and are translated into MIBs, they become accessible but have additional anchor points in the DmtfGroups tree. For example, if the software MIF were defined, the translation would provide a DMISW MIB and be anchored as follows: 

enterprise.sun.DmtfGroups.DMISW(2)

or

1.3.6.1.4.1.42.2000.3

Managing applications must be prepared for the same component to be visible in two different branches of the DmtfGroups tree.

Additional OID prefixes:

6.7 The DMI Mapper Configuration File

The default configuration file snmpXdmid.conf is located in the directory /etc/dmi/conf. You may alternatively provide another path to this program as a command-line option for the location of the snmpXdmid.conf file.

6.7.1 WARNING_TIMESTAMP

snmpXdmid must subscribe to the DMI SP to receive indications. According to DMI 2.0 specifications, this subscription is valid only up to a particular timestamp. The SP issues a warning subscription notice before it ends the subscription. This timestamp indicates the time a subscription warning was issued.

The default value is:

WARNING_TIMESTAMP = 20101231110000.000000-420

6.7.2 EXPIRATION_TIMESTAMP

This indicates the time that a subscription actually expires. No indications are received after this time, unless they are re-subscribed. By default, a future timestamp is chosen so the subscription practically exists forever. This is done so that snmpXdmid always retains its indication subscription with the SP.

The default value is:

EXPIRATION_TIMESTAMP = 250101231120000.000000-420

6.7.3 FAILURE_THRESHOLD

This indicates the number of attempts by DMI SP in order to deliver the indications to snmpXdmid, in case it encounters errors before it drops the indication and clears the subscription entry.

The default value is:

FAILURE_THRESHOLD = 1

6.7.4 TRAP_FORWARD_TO_MAGENT

A non-zero value results in snmpXdmid generating an SNMP trap following an indication from the DMI SP. A zero value results in no SNMP trap generation following a DMI SP indication.

The default value is:

TRAP_FORWARD_TO_MAGENT = 1

6.8 Generating a MIB File

SNMP management applications typically require a MIB defining managed data. For each MIF file that you want to make accessible to an SNMP manager, you must generate an SNMP MIB that corresponds to the MIF file. The MIB must then be loaded at the management application that uses the definitions in the MIB to communicate with the DMI component. The management application may also make the MIB information available to browsers and other MIB-based applications.

To generate an SNMP MIB from a MIF file, use the miftomib utility at the command prompt. After you create the MIB file, you may transfer it to the SNMP management application.