# Appendix D

| # SNMP Proxy Monitoring Modules

> This appendix covers the following topics:

- Proxy Monitoring--page 605
- SNMP Sets--page 616

## Proxy Monitoring

> This appendix describes how to build modules that enable Sun Management Center agents to proxy monitor other legacy SNMP agents running on the same host or other hosts or devices on the network.

> These modules allow Sun Management Center agents to manage and determine the status of objects being monitored by legacy agents in the same manner as objects being monitored by typical Sun Management Center modules. This is accomplished by having the Sun Management Center agent query the legacy agent and storing any retrieved data locally. This data can then be processed by the Sun Management Center agent for typical module actions such as alarm limit checking. In addition, traps issued from the legacy agent can be correlated with jobs in the Sun Management Center agent and used to trigger refresh actions that can reacquire data from legacy agents to determine the status in a timely manner.

> The following sections describe the differences in the various module definition files for SNMP proxy monitoring modules. Two new module definition files are also described.

### Module Parameter File

> In addition to the standard module parameters required, SNMP proxy monitoring modules require additional information to be specified in the module parameter file.

> These parameters are:

- `targetHost`--the name of the remote host on which the legacy agent is running.
- `targetPort`--the SNMP port of legacy agent.
- `targetEnterprise`--the symbolic OID corresponding to the branch of interest in the MIB of the legacy agent. This is typically the enterprise specific branch. A symbolic OID is an OID that specifies the node names instead of the numerical values. For example, iso.org.dod is a symbolic OID.
- `context`--the MIB context of the object if any.
- `snmpVersion`--the version of the SNMP protocol used by the legacy agent. This can have one of the following values: SNMPv1, SNMPv2c, or SNMPv2u.
- `securityLevel`--this defines the level of security used in the SNMP communication. The valid values are: priv, auth, or noauth. priv indicates that the SNMP communication will be encrypted (this is not currently implemented). auth indicates that the SNMP communication will be authenticated. This is only valid for SNMPv2u. Finally, noauth indicates that no authentication will be done. This is required for SNMPv2c and SNMPv1 protocols.
- `securityName`--this is the security name (or community for SNMPv1 and SNMPv2c) used to perform SNMP gets from the legacy agent.

> These additional parameters are used to automatically construct the `refreshCommand` for nodes that inherit from the `TARGET-SNMP` primitive (see below). As such, only SNMP gets from legacy agents are permitted using these module parameters. Additional parameters may be specified for SNMP sets (see below).

> These parameters are specified in the module parameter file in the same manner as other parameters and can have optional parameters, such as description, associated with them.

> The following example shows the module parameter file for the MIB2 Proxy Module. This example includes the standard module parameters as well as the four additional parameters and associated optional parameters (description, reqd and access) required for SNMP proxy monitoring modules.

> CODE EXAMPLE D-1 Example: `mib2-proxy-v2-m.x`

>     [load default-m.x]
>     # Tabulation and ordering specifications
>     consoleHint:moduleParams(param) = module i18nModuleName i18nModuleDesc version
>     console enterprise i18nModuleType instance instanceName targetHost targetPort
>     targetEnterprise snmpVersion securityLevel securityName context
>     param:module = mib2-proxy
>     param:moduleName = MIB-II Proxy Monitoring
>     param:version = 2.0
>     param:console = mib2-proxy
>     param:moduleType    = remoteSystem
>     param:i18nModuleName  = base.modules.mib2Proxy:moduleName
>     param:i18nModuleType  = base.modules.mib2Proxy:moduleType
>     param:i18nModuleDesc  = base.modules.mib2Proxy:moduleDesc
>     ?param:i18nModuleName?i18n = yes
>     ?param:i18nModuleType?i18n = yes
>     ?param:i18nModuleDesc?i18n = yes
>     param:enterprise        = sun
>     param:targetEnterprise  = iso.org.dod.internet.mgmt.mib-2
>     param:snmpVersion       = SNMPv1
>     param:instance          =
>     param:instanceName      =
>     param:targetHost        =
>     param:targetPort        =
>     param:context           =
>     param:securityName      = public
>     param:securityLevel     = noauth
>     param:location = .iso.org.dod.internet.private.enterprises.sun.prod.sunsymon.agent.modules.mib2Proxy
>     ?param:targetHost?description       = base.modules.default:targetHost
>     ?param:targetHost?reqd              = yes
>     ?param:targetPort?description       = base.modules.default:targetPort
>     ?param:targetPort?reqd              = yes
>     ?param:targetEnterprise?description = base.modules.default:targetMibEnt
>     ?param:targetEnterprise?reqd        = yes
>     ?param:securityName?description     = base.modules.default:securityName
>     ?param:securityName?reqd            = yes
>     ?param:snmpVersion?description      = base.modules.default:snmpVersion
>     ?param:snmpVersion?reqd             = yes
>     ?param:securityLevel?description    = base.modules.default:securityLevel
>     ?param:securityLevel?reqd           = yes
>     ?param:context?description          = base.modules.default:context
>     ?param:instance?description         = base.modules.default:instanceId
>     ?param:instance?reqd                = yes
>     ?param:instance?format              = instance
>     ?param:instanceName?description     = base.modules.default:instanceName
>     ?param:instanceName?reqd            = yes

### Module Models File

> For SNMP proxy monitoring modules, the module Model file must be used to map out the portion of the MIB in the legacy agent (under the branch specified by the targetEnterprise) that is of interest to the module.

> For example, a fragment of the MIB2 proxy module model file for the system and udp branches of the MIB2 tree is shown in the next section.

> CODE EXAMPLE D-2 Example: mib2-proxy-models-d.x

>     type  = reference
>     consoleHint:mediumDesc = base.modules.mib2Proxy:moduleDetail
>     #
>     # system Managed Object
>     # implements MIB-II system Group
>     #
>     system = { [use MANAGED-OBJECT]
>             mediumDesc = MIB-II System Group
>             consoleHint:mediumDesc = base.modules.mib2Proxy:system
>             sysDescr = { [use STRING MANAGED-PROPERTY]
>                     shortDesc      = sysDescr
>                     mediumDesc     = System Descr
>                     fullDesc       = MIB-II System Description

>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysDescr
>             }
>             sysObjectID = { [use OID MANAGED-PROPERTY]
>                     shortDesc       = sysOID
>                     mediumDesc      = System OID
>                     fullDesc        = Object Identifier of the software system
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysObjectID
>             }
>             sysUpTime = { [use STRING MANAGED-PROPERTY]
>                     shortDesc    = Time since up
>                     mediumDesc   = Time since System is up
>                     fullDesc           = The time in microseconds since the system is up
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysUpTime
>             }
>             sysContact = { [use STRING MANAGED-PROPERTY]
>                     shortDesc       = Contact
>                     mediumDesc      = System Contact
>                     fullDesc        = Contact name for this system
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysContact
>             }
>             sysName = { [use STRING MANAGED-PROPERTY]
>                     mediumDesc        = system name
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysName
>             }
>             sysLocation = { [use STRING MANAGED-PROPERTY]
>                     shortDesc         = Time since up
>                     mediumDesc        = system location
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysLocation
>             }
>             sysServices = { [use INT MANAGED-PROPERTY]
>                     mediumDesc        = system services
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:system.sysServices
>             }
>     }
>     ...
>     ...
>     ...
>     udp = { [use MANAGED-OBJECT]
>             mediumDesc        = MIB-II UDP Group
>             consoleHint:mediumDesc = base.modules.mib2Proxy:udp
>             udpInDatagrams = { [use COUNTER MANAGED-PROPERTY]
>                     mediumDesc         = udpInDatagrams
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpInDatagrams
>             }
>             udpNoPorts = { [use COUNTER MANAGED-PROPERTY]
>                     mediumDesc           = udpNoPorts
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpNoPorts
>             }
>             udpInErrors = { [use COUNTER MANAGED-PROPERTY]
>                     mediumDesc          = udpInErrors
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpInErrors
>             }
>             udpOutDatagrams = { [use COUNTER MANAGED-PROPERTY]
>                     mediumDesc        = udpOutDatagrams
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpOutDatagrams
>             }
>             udpTable = { [ use MANAGED-OBJECT-TABLE ]
>                     shortDesc         = UDP Table
>                     mediumDesc        = UDP Table
>                     fullDesc          = UDP Table in MIB-II
>                     consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpTable
>                     udpEntry = {[ use MANAGED-OBJECT-TABLE-ENTRY ]
>                             shortDesc         = UDP Entry
>                             mediumDesc        = UDP Entry
>                             fullDesc          = UDP Entry in MIB-II
>                             consoleHint:mediumDesc = base.modules.mib2Proxy:udp.udpTable.udpEntry
>                             index = udpLocalAddress udpLocalPort
>                             udpLocalAddress = { [ use STRING MANAGED-PROPERTY ]
>                                     mediumDesc	= udpLocalAddress
>                                     consoleHint:mediumDesc = \
>     base.modules.mib2Proxy:udp.udpTable.udpEntry.udpLocalAddress
>                             }
>                             udpLocalPort = { [ use INT MANAGED-PROPERTY ]
>                                     mediumDesc = udpLocalPort
>                                     consoleHint:mediumDesc = \
>     base.modules.mib2Proxy:udp.udpTable.udpEntry.udpLocalPort
>                             }
>                     }
>             }
>     }

### Legacy MIB OIDs Mapping File

> To allow the Sun Management Center agent to reference the legacy agent using URLs, an additional module definition file must be created and loaded into the agent (see the next section). This file is used to map symbolic object identification names to their numeric OID values. The naming convention for this file is <module><-subspec>-oids-d.dat and can be generated using the script mib2x. This script is located in /opt/SUNWsymon/util/bin/<arch>. The general usage for this script is:

>     mib2x -f <ASN.1 MIB text file> > <module><-subspec>-oids-d.dat

> This script reads an ASN.1 MIB text file and generates, on standard output, text with the following format:

>     <sym1> = <oid1> [<instance>]
>     <sym1>/<sym2> = <oid1>.<oid2> [<instance>]
>     <sym1>/<sym2>/<sym3> = <oid1>.<oid2>.<oid3> [<instance>]
>     ...

> This file maps symbolic names of nodes in the legacy MIB to OIDs. The text created by the mib2x script may need to be edited manually. The first few lines from the MIB2 Proxy module legacy MIB OIDs file (`mib2-proxy-oids-d.dat`) are:

>     iso = 1
>     iso/org = 1.3
>     iso/org/dod = 1.3.6
>     iso/org/dod/internet = 1.3.6.1
>     iso/org/dod/internet/directory = 1.3.6.1.1
>     iso/org/dod/internet/mgmt = 1.3.6.1.2
>     iso/org/dod/internet/mgmt/mib-2 = 1.3.6.1.2.1
>     iso/org/dod/internet/mgmt/mib-2/system = 1.3.6.1.2.1.1
>     iso/org/dod/internet/mgmt/mib-2/system/sysDescr = 1.3.6.1.2.1.1.1
>     ...

### Module Realization File

> To enable the Sun Management Center agent to reference the legacy agent using URLs, OIDs file of the legacy agent must be loaded into the agent. The loading of this file and the qualifiers required to collect data from the legacy agent are described in the following section.

> Loading the Legacy MIB OIDs Mapping File

> The legacy agent's OIDs file must be loaded into the Sun Management Center agent SNMP OID cache. This is done by specifying the following qualifiers in the module realization file:

>     activateActions(post) = <key>
>     activateService(<key>) = .services.snmp
>     activateCommand(<key>) = cache load <module><-subspec>-oids

> Where <key> can be any unique identifier and the <module><-subspec>-oids corresponds to legacy MIB OIDs file. The `activateActions(post)` qualifier is a space separated list of keys that corresponds to actions that will be performed after the current MIB tree has been instantiated. Each <key> must have a `activateService` and `activateCommand` that specifies the command as well as the context in which the command is to be executed.

> In this case, there is only one key and it corresponds to the action of loading the legacy MIB OIDs file into the context of the SNMP service object. For example, for the MIB2 Proxy module the qualifiers used to load the OIDs file are:

>     activateActions(post) = loadcache
>     activateService(loadcache) = .services.snmp
>     activateCommand(loadcache) = cache load pmib2-oids

> Data Acquisition

> For SNMP proxy monitoring modules, data acquisition is accomplished through proxy SNMP operations such as SNMP get, instead of typical module data acquisition mechanisms such as shell scripts or TCL/TOE code. To facilitate data acquisition for proxy SNMP operations, one of the following primitives should be used:

- TARGET-SNMP--to do an snmp get for typical data
- TARGET-SNMP-BINARY--to do an snmp get for binary data

> These primitives automatically set the node type to `active` and constructs the `refreshCommand`. Nodes that inherit from this primitive are typically the nodes that realize the objects from the models file. For example, shown below are the two objects from the MIB2 Proxy module realization file that instantiate the objects from the models file. These objects also inherit from the TARGET-SNMP primitive.`
> `

> CODE EXAMPLE D-3 Example: `mib2-proxy-d.x`

>     [ requires templates mib2-proxy-models-d ]

>     ...

>     system = { [ use templates.mib2-proxy-models-d.system TARGET-SNMP
>     ]
>     ...
>     }

>     ...

>     udp = { [ use templates.mib2-proxy-models-d.udp TARGET-SNMP ]
>         udpTable = { [ use templates.mib2-proxy-models-d.udp.udpTable
>     TARGET-SNMP ]
>          }
>     }

> Nodes that inherit from the TARGET-SNMP primitive must also specify two additional qualifiers. These two qualifiers are used to automatically construct the refreshCommand.

> They are:

- refreshOidPrefix
- refreshOids

> The refreshOidPrefix specifies the symbolic OID in the legacy agent from the enterprise branch (as specified by the targetEnterprise parameter) to the node containing the managed properties of interest. The refreshOids qualifier is a comma separated list of managed properties. Together, the targetEnterprise, refreshOidPrefix, and refreshOids specify the full symbolic OIDs used to access the MIB of the legacy agent. For example, suppose data from the symbolic OID shown below is required.

>     iso.org.dod.internet.mgmt.mib-2.system.sysDescr

> The targetEnterprise is set to iso.org.dod.internet.mgmt.mib-2, the refreshOidPrefix is set to system, and the refreshOids is set to sysDescr#0. The #0 is added to indicate a scalar value. If the managed property was a vector value, then no #0 is required.

> > Note - The number of items in the refreshOids list is the number of data values that will be acquired from the legacy agent and cascaded into passive managed properties below the active node. As a result, the number of items in the refreshOids list must match the number of passive managed properties below the active node.

> Nodes that inherit from the TARGET-SNMP-BINARY primitive must specify a refreshHint qualifier in addition to the refreshOidPrefix and refreshOids qualifiers. refreshHint must specify the conversion from binary to ascii. See Mapping of the DISPLAY-HINT clause in RFC 1903 for more information on the valid contents of refreshHint (Note: octal and binary conversions are not supported for INT nodes and octal conversions are not supported for STRING nodes). The refreshHint specification is typically 1x:, indicating that the value returned from the snmp get is a : delimited string, where each delimited value is a hexadecimal representing a single byte

> Shown below is a section from the MIB2 proxy module realization file illustrating the specification of the refreshOidPrefix and refreshOids qualifiers.

>     system = { [ use templates.mib2-proxy-models-d.sysget TARGET-SNMP
>     ]
>         type = active
>         refreshInterval = 3600
>         refreshOidPrefix = system
>         refreshOids =
>     sysDescr#0,sysObjectID#0,sysUpTime#0,sysContact#0,
>                       sysName#0,sysLocation#0,sysServices#0
>     }
>     udp = { [ use templates.mib2-proxy-models-d.udp TARGET-SNMP ]
>          type = active
>          refreshInterval = 3600
>          refreshOidPrefix = udp
>          refreshOids = udpInDatagrams#0,udpNoPorts#0,udpInErrors#0,

>     udpOutDatagrams#0
>          udpTable = { [ use templates.mib2-proxy-models-d.udp.udpTable
>     TARGET-SNMP ]
>               type = active
>               refreshOp = walk
>               refreshInterval = 0
>               refreshOidPrefix = udp.udpTable.udpEntry
>               refreshOids = udpLocalAddress,udpLocalPort
>          }
>     }

> In the iftableget node, refreshOp is set to walk and the items in the refreshOids list do not have #0 appended to them, as the data values to be retrieved are vectors.

> By default, the TARGET-SNMP primitive sets refreshOp = get to perform a single SNMP get operation for scalar values. However, by setting the refreshOp to walk, the TARGET-SNMP primitive will traverse the MIB tree from the point specified and return all values. As a result, all values from the vector are returned.

> Shown below is the complete module realization file for the MIB2 proxy module.

> CODE EXAMPLE D-4 Module Realization: MIB2 Proxy Module

>     [ use MANAGED-MODULE ]
>     [ load mib2-proxy-m.x ]
>     [ requires template mib2-proxy-models-d ]

>     consoleHint:mediumDesc = base.modules.mib2Proxy:moduleDetail

>     refreshService = .services.snmp

>     activateActions(post) = loadcache
>     activateService(loadcache) = .services.snmp
>     activateCommand(loadcache) = cache load mib2-proxy-oids

>     system = { [ USE TEmplates.mib2-proxy-models-d.system TARGET-SNMP
>     ]
>         type = active
>         initInterval = 1
>         refreshInterval = 3600
>         refreshOidPrefix = system
>         refreshOids = \
>     sysDescr#0,sysObjectID#0,sysUpTime#0,sysContact#0,sysName#0,\
>     sysLocation#0,sysServices#0
>     }
>     ...
>     ...
>     ...
>     udp = { [ use templates.mib2-proxy-models-d.udp TARGET-SNMP ]
>         type = active
>         initInterval = 1
>         refreshInterval = 3600
>         refreshOidPrefix = udp
>         refreshOids =
>     udpInDatagrams#0,udpNoPorts#0,udpInErrors#0,udpOutDatagrams#0
>         udpTable = { [ use templates.mib2-proxy-models-d.udp.udpTable
>     TARGET-SNMP ]
>             type = active
>             initInterval = 1
>             refreshOp = walk
>             refreshInterval = 0
>             refreshOidPrefix = udp.udpTable.udpEntry
>             refreshOids = udpLocalAddress,udpLocalPort
>         }
>     }

## SNMP Sets

> SNMP sets to legacy agents can be made as part of the setActions infrastructure (see Chapter 6). The setService must be set to .services.snmp and the setCommand must be set to:

>     set <ip address> <port> -1 {{<varbind>} [{<varbind>} ... ]} \
>     [-version <snmpVersion>] [-securityLevel <securityLevel>] \
>     [-securityName <securityName>] [-context <context>] [-timeout <timeout>] \
>     [-retries <retries>]

> where:

> <ip address> is the IP address of the host where the legacy agent is running. If this is the same as the targetHost module parameter, then %targetAddress can be used for this value.

> <port> is the port used by the legacy agent. If this value is the same as the targetPort module parameter, then %targetPort can be used for this value.

> <varbind> consists of <url> <asn1 type> <value> [<display hint>].

> <url> can be either one of sym/<symbolic oid>, oid/<numeric oid>, or mod/<module oid>.
> <asn1 type> specifies the type of data being set. This can be OCTET STRING, Integer32, NULL, OBJECT IDENTIFIER, IpAddress, Counter32, Unsigned32, TimeTicks, Counter64, INTEGER, or Gauge32.
> <value> is the value to be set.
> <display hint> is optional and used to convert <value> to the appropriate format for setting. See Mapping of the DISPLAY-HINT clause in RFC 1903 for more information (Note that octal and binary conversions are not supported for INTEGER types and octal conversions are not supported for OCTET STRING types. The <display hint> specification is typically used to set binary data in the legacy agents. In such a case, <display hint> is typically 1x:, indicating that the <value> is a : delimited string, where each delimited value is a hexadecimal representing a single byte.

> <snmpVersion> is optional (default is SNMPv2u) and specifies snmp version used by the legacy agent. If this is the same as the snmpVersion module parameter, %snmpVersion can be used for this value.

> <securityLevel> is optional (default is auth) and specifies the SNMP security level supported by the legacy agent. If this value is the same as the securityLevel module parameter, %securityLevel can be used.

> <securityName> is optional (default is espublic) and specifies the name (or community) with which to perform the SNMP set. If this value is the same as the securityName module parameter, %securityName can be used.

> <context> is optional (default is no context) and specifies the MIB context for the object to be set. If this value is the same as the context module parameter, then %context can be used.

> <timeout> is optional (default is 30 seconds) and specifies the time out for the SNMP request in seconds.

> <retries> is optional (default is 3 times) and specified the number of times the SNMP set is retried.

### SNMP Set Example

> In the code fragment below, setnode is a node that has setActions defined. Whenever an SNMP set is made to this node, it will execute an SNMP set to a legacy agent. The set command specifies <ip address>, <port>, <snmpVersion>, <securityLevel>, and <securityName> to be the same as the module parameters. Note, this would indicate that the read and write security names (or communities) are the same. The SNMP set is setting some fixed binary data to the OID 1.3.6.1.4.1.9999.1.1.0.

>     setnode = { ...
>         setActions = doset
>         setService(doset) = services.snmp
>         setCommand(doset) = set %targetAddress %targetPort -1 {{oid/
>     1.3.6.1.4.1.9999.1.1.0 {OCTET STRING}
>     0:0:4:da:40:cc:e1:f7:99:1f:e1:0 1x:}} -version %snmpVersion -
>     securityLevel %securityLevel -securityName %securityName
>     }

### Module Trap Action Definition File

> In certain cases, the legacy agent may issue traps that the SNMP proxy monitoring module may be interested in. In such a case, the legacy agent must first be configured to send the traps to the Sun Management Center Trap handler.

> Once traps are being sent to the Sun Management Center Trap handler, they will be forwarded to the Sun Management Center agent. The SNMP proxy monitoring module must then add to the agent the actions to be performed for the traps that it is interested in. This is done by loading a new module definition file in to the Sun Management Center agent.

> Naming Conventions

> The naming convention for this file is <module>-<subspec>-traps-d.x and the format is as follows:

>     [ requires class trapaction ]
>     [ inherit classes.trapaction ]

>     <object1> = {
>         [ inherit classes.trapaction ]

>         criteria = enterprise
>         enterprise = <oid corresponding to targetEnterprise>

>         <object2> = {
>             [ inherit classes.trapaction ]

>             criteria = <criteria1> [ <criteria2> <criteria3> ... ]
>             <criteria1> = <value1>
>             ...

>             trapActions = <key1> [ <key2> ... ]
>             trapService(<key1>) = <service>
>             trapMethod(<key1>) = <command>
>         }

>         [ <other objects> ]
>     }

>     <object1> should be a unique identifier indicating the module name.

> Sample Specification

> Specifying the following:

> `criteria` = enterprise

> `enterprise` = <oid corresponding to targetEnterprise>

> allows traps from the specified enterprise (the OID corresponding to the value set in the targetEnterprise module parameter) to be passed down to <object2> (and other objects if specified) for further processing. This allows <object2> to be selective in which traps are processed. Again <object2> is another unique identifier.

> Specifying the following:`
> `

>     criteria = <criteria1> [ <criteria2> <criteria3> ... ] \
>     <criteria1> = <value1>

> allows further trap filtering capabilities. The criteria qualifier is a space separated list of parameters whose values are checked for comparison.

> Valid Parameters

> The list of valid parameters are:

- .agentAddr--address of the agent originating the trap (for example, 192.83.121.224)
- enterprise--the OID up to the enterprise branch from where the trap was issued (e.g. 1.3.6.1.4.1.1242)
- genericTrap--the generic type of the trap (for example, 1)
- specificTrap--the specific type of the trap (for example, 0)
- trapOid --the OID where the trap was issued (not including the enterprise) (for example, 1.1.1.1.1)
- timeStamp--time stamp of the trap (for example, 472d 3:17:27.72)
- receiveTime--time trap was received (for example, Wed Oct 18 12:12:20 EDT 1995)
- version--SNMP version (for example, SNMPv1)
- community--SNMP community (for example, public)
- forwarder--trap forwarder (for example, 192.83.121.224:30001)

> Use trapOid in place of the genericTrap and specificTrap specifications. The trapOid specification will support both SNMPv1 and SNMPv2 traps, whereas genericTrap and specificTrap specifications only support SNMPv1 traps.

> For every parameter specified in the criteria list, there must be a qualifier that corresponds to the parameter and the value to be checked against.

> The following example will check the agentAddr parameter for equivalence to 192.83.121.224. :

>     criteria = agentAddr
>     agentAddr = 192.83.121.224

> If the test fails, no further processing of the trap is done. The `equal to' test can be changed to `not equal to', by specifying not before the value.

> The following exa,mple will test the agentAddr parameter and fail if it equals 1982.83.121.224.

>     criteria = agentAddr
>     agentAddr = not 192.83.121.224

> If no criteria list is specified, all traps passed into <object2> will activate all trap actions. The specification of actions to be performed on traps is made by the following set of qualifiers:

>     trapActions = <key1> [ <key2> ... ]
>     trapService(<key1>) = <service>
>     trapMethod(<key1>) = <command>

> The trapActions qualifier is a space separated list of actions to be performed. For each action in the list, there must be a trapService and trapMethod specified. Typically the action required on a trap is to refresh the data values.

> This is done by specifying:

>     trapActions = <key>
>     trapService(<key>) = .services.snmp
>     trapMethod(<key>) = jobFireByTag %agentAddr:%enterprise

> In this case, the trapMethod qualifier specifies a command to fire all jobs associated with the specific agent and enterprise.

### Example: Trap Action File for HP JetDirect

> Shown below is the trap action file for the HP JetDirect module:

> CODE EXAMPLE D-5 Example: `hp-jetdirect-trapspd.x`

>     [ requires class trapaction ]
>     [ inherit classes.trapaction ]
>     hpjetdirect = {
>         [ inherit classes.trapaction ]
>         criteria                 = enterprise
>         enterprise               = 1.3.6.1.4.1.11.2.3.9.1
>         notauth = {
>            [ inherit classes.trapaction ]
>            #
>            # match traps that are not authentication failures
>            #
>            criteria             = trapOIDRegexp
>            trapOIDRegexp        = not ^1\\.3\\.6\\.1\\.6\\.3\\.1\\.1\\.5\\.5$
>            #
>            # perform trap correlation in job module using trap enterprise
>            #
>            trapActions                 = jobfire
>            trapService(jobfire)        = .services.snmp
>            trapMethod(jobfire)         = jobFireByTag %agentAddr:/%enterprise
>         }
>     }

> To load the trap actions file into the agent, an additional key is required in the activateActions(post) list (see Chapter 6).

> Shown below are the qualifiers required:

>     activateActions(post) = <key1> <key2>

>     activateService(<key2>) = .services.trap

>     activateCommand(<key2>) = loadActions <module><-subspec>-traps

> In this case the activateCommand qualifier will load the file `<module>-<subspec>-traps-d.x` file into the context of the .services.trap object in the Sun Management Center agent.

> Example: Qualifiers for Loading the HP JetDirect Module Trap Actions File

> Shown below are the qualifiers for loading the HP JetDirect module trap actions file.

>     activateActions(post) = loadtraps
>     activateService(loadtraps) = .services.trap
>     activateCommand(loadtraps) = loadActions hp-jetdirect-traps

> Example: Qualifiers for Loading Both the OIDs and Trap Actions Files for the HP JetDirect Module

> Shown below are the qualifiers for loading both the OIDs and trap actions files for the HP JetDirect module:

>     activateActions(post) = loadcache loadtraps

>     activateService(loadcache) = .services.snmp
>     activateCommand(loadcache) = cache load hp-jetdirect-oids

>     activateService(loadtraps) = .services.trap
>     activateCommand(loadtraps) = loadActions hp-jetdirect-traps

Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.