Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
6.  Using SNMP With DMI 6.5 How the DMI Mapper Works  Previous   Contents   Next 
   
 

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:

  • GET

  • GETNEXT

  • SET

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.

  • DmiDeliverEvent This indication is generated by the component. The SP passes it to all the MI applications having their valid entries in the subscription and filter tables maintained by the SP. The snmpXdmid mapper matches the OID prefix to the component ID, generating the event for building the TrapOID. The groupId and attributes are also part of the event. The snmpXdmid mapper uses all relevant information in the event (apart from the OID prefix itself) to generate the TrapOID. The snmpXdmid generates a SNMP-specific trap, with specific trapID=14.

  • DmiComponentAdded This indication is generated by the SP when a new component is registered. New components may be registered for existing .MAP files or for a totally new .MAP file. When this trap is received by snmpXdmid, it unregisters all the registered OIDs in the Master Agent, rereads all the .MAP files, and then goes through the process of reregistering all of the OIDs with the Master Agent. This helps to keep the subagent translation tables in sync with the .MAP files, especially since the .MAP files are generated external to the mapper. The mapper then generates an SNMP-specific trap with trapID = 7.

  • DmiComponent-Deleted This indication is generated by the SP when an existing component ID is unregistered with the SP. The snmpXdmid mapper modifies the translation tables upon receiving this indication. By default, it generates an SNMP trap with trapID=8.

  • DmiLanguageAdded This indication is generated by SP. It results in an SNMP trap with trapID=9.

  • DmiLanguageDeleted This indication is generated by SP, resulting in an SNMP trap with trapID=10.

  • DmiGroupAdded This indication is generated by SP when a new group is registered with it under a component ID. This results in the updating of translation tables in snmpXdmid. An SNMP trap is generated with trapID=11.

  • DmiGroupDeleted This indication is generated by the SP when a group is unregistered with it. This results in the updating of translation tables, and an SNMP trap is generated with trapID=12.

  • DmiSubscriptionNotice This indication is generated by the SP under two circumstances:

    • When the management application subscription for indication hits the warning timestamp. A flag indicates the warning aspect of the indication. An NMP trap with trapID=15 is generated.

    • When the management application subscription for indication hits the expiration timestamp. An SNMP trap with trapID=16 is generated.

 
 
 
  Previous   Contents   Next