test

Solstice Enterprise Agents 1.0 User Guide

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-3 shows 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: