Solstice Enterprise Manager 4.1 Customizing Guide | ![]() ![]() ![]() ![]() ![]() |
Mapping SNMP Traps to CMIP Event Notifications
Simple Network Management Protocol (SNMP) agents have the ability to generate event notifications on their own initiative when certain conditions are detected; these notifications are called traps. A Solstice Enterprise Manager (Solstice EM) daemon--em_snmp-trap--listens for incoming SNMP traps for forwarding to management stations. The em_snmp-trap daemon can be distributed to multiple machines in the network.
Solstice EM supports both SNMPv1 and SNMPv2c. For more information, see Section 11.1 SNMP Support.
This chapter describes the following topics:
- Section 11.1 SNMP Support
- Section 11.2 Trap Daemon Operation
- Section 11.3 The Structure of SNMP Traps
- Section 11.4 Default Trap Mapping
- Section 11.5 Trap Daemon Behavior When No Mapping is Provided
- Section 11.6 Format of trap_maps File
- Section 11.7 Customizing the Mapping of SNMP Traps
- Section 11.8 Distributed Trap Handling
11.1 SNMP Support
Solstice EM supports both SNMP version 1 (SNMPv1) and SNMP version 2c (SNMPv2c). The SNMPv2c standard is based on the community string model. Solstice EM does not support SNMPv2 InformRequest (confirmed traps).
Supporting both SNMPv1 and SNMPv2c protocol offers you the flexibility to interact with SNMPv1 and SNMPv2c agents on your network. Configuration and operation of the SNMP versions differ in some areas, and they are explained in detail in the remaining sections of this chapter.
11.2 Trap Daemon Operation
The Solstice EM trap daemon (em_snmp-trap) supports both SNMPv1 and SNMPv2c.
The trap daemon for SNMPv1 and SNMPv2c does the following with incoming SNMP traps:
- SNMP traps are converted to Common Management Information Protocol (CMIP) event notifications and sent to the MIS. Like other Solstice EM applications, em_snmp-trap uses the Portable Management Interface (PMI) to communicate with the MIS. The trap daemon's mapping of SNMP traps into CMIP notifications can be customized via entries in the daemon's trap mapping file (trap_maps). Procedures for customizing the trap daemon are described in Section 11.7 Customizing the Mapping of SNMP Traps.
- SNMP traps are also translated into SunNet Manager traps for use by SunNet Manager (SNM) applications. Any SNM application (such as the SNM Console) that registers with the SNM Event Dispatcher (na.event) on a manager system receives the incoming SNM traps forwarded by the trap daemon. The trap daemon uses a SunNet Manager SNMP trap file (snmp.traps), which contains information for interpretation of enterprise-specific traps. To configure the SNMP trap daemon for use with SunNet Manager, follow the Solstice Site/SunNet/Domain Manager Administration Guide guidelines for the SNM trap daemon (na.snmp-trap). (The SNM trap conversion functionality of na.snmp-trap is a subset of the functionality of the Solstice EM SNMP trap daemon.)
- You can also filter raw SNMP traps to be forwarded to other managers or discarded. Configuring this capability is described in Section11.8.1 Filtering SNMP Traps for Other Managers." The SNMP manager(s) is configured when you install the Solstice EM trap daemon. The installation script prompts you for the host name and port number of the manager that is to receive the forwarded SNMP traps. If you want to discard raw SNMP traps for other managers, add DISCARD to the trap-filtering-record in the trap_forward file.
Note It is unnecessary to run both the Solstice EM SNMP trap daemon and the SunNet Manager SNMP trap daemon (na.snmp-trap) on the same system because they listen at the same port (port 162) and the SNM trap-daemon handling is a subset of the functionality of em_snmp-trap.
SNMP trap daemon operation is illustrated in the following figure.
For information on how to install em_snmp-trap, refer to Chapter 6 in Installation Guide.
Note In the current release, em_snmp-trap is supported only on Sun workstations running Solaris 2.6 through 2.8 software.
![]()
FIGURE 11-1 em_snmp-trap OperationThere are two ways the SNMP trap daemon can be started or stopped:
- The em_services command is used to start and stop all of the Solstice EM daemons at once, including the trap daemon and the MIS. (For information on the em_services command, refer to Chapter 2 in Management Information Server Guide.)
- If you want to start or stop the trap daemon by itself, you can use the em_trapd script.
11.2.1 Starting the Trap Daemon
![]()
To Start the Trap daemon
Type the following:
# em_trapd start [<port_number>]Port number is optional. You can use this option to start em_snmp-trap on a non-default port. By default, em_snmp-trap listens for incoming traps on port 162. For example, to start the trap daemon on port 412, enter the following command:
# em_trapd start 41211.2.2 Stopping the Trap Daemon
The following command stops the trap daemon:
![]()
To Stop the Trap Daemon
- You should use these commands if you want to stop the trap daemon on an MIS machine without starting or stopping the MIS.
At startup the SNMP trap daemon spawns at least two child processes. One process is responsible for translation of traps to SunNet Manager format and forwarding to the SunNet Manager event dispatcher (na.event). In addition, one additional child process is spawned for each of the MIS hosts the trap daemon connects to. (You specify the target MIS machines during installation of the trap daemon.) Each of these processes sets up a CMIP over TCP/IP connection to the MIS on a particular host, and is responsible for conversion of SNMP traps to CMIP event notifications.
The trap daemon's mapping of incoming SNMP traps into CMIP event notifications is determined by user-configurable mapping records in the trap daemon's trap_maps file. The trap_maps file is an ASCII text file that resides in the
/etc/opt/SUNWconn/em/conf directory; the trap daemon reads this file whenever it starts.11.3 The Structure of SNMP Traps
Throughout this chapter we will be making reference to the various fields that comprise the SNMP trap Protocol Data Unit (PDU). The structure of the SNMP traps for SNMPv1 and SNMPv2c differ. See the following sections for information specific to each SNMP version.
11.3.1 SNMPv1
The SNMP trap PDU for SNMPv1 has the fields indicated in the following figure.
FIGURE 11-2 SNMPv1 Trap PDU StructureThe fields are as follows:
TABLE 11-1 SNMPV1 Field Descriptions <type> Indicates the type of SNMP message. (In this case, it indicates that this is a trap PDU.) <enterprise> Indicates the subsystem that generated the trap, as indicated by the sysObjectID attribute. <agent-addr> This is the IP address of the source of the trap. <generic-trap> This is an integer value in the range of 0 to 6 indicating the standard trap type. The standard trap types are listed in TABLE 11-2. <specific-trap> A device-specific value providing more information concerning to the nature of the event. <timestamp> Time between the last reinitialization of the agent system and the time when the trap was generated. <variable-bindings> Information that varies depending upon the particular implementation by the product vendor. The format consists of attribute/value pairs. Each attribute name is followed by its value.
The <generic-trap> and <specific-trap> fields contain values that indicate the nature of the trap. The possible values for <generic-trap> are described in the following table.
11.3.2 SNMPv2c
The SNMPv2c trap PDU differs substantially from the SNMPv1. The SNMPv2c PDU does not contain the following information:
- <enterprise>
- <agent-addr>
- <generic-trap>
- <specific-trap>
- <timestamp>
For SNMPv2c traps, some of this information is contained in the variable bindings. The <error-status> and the <error-index> fields are always set to 0 for SNMPv2c, as shown in the following figure.
FIGURE 11-3 SNMPv2c Trap PDU StructureThe fields are as follows:
- SNMPv2c requires the first two variable bindings to be sysUpTime and TrapOid. If present, the enterprise Oid must be the last variable binding.
11.4 Default Trap Mapping
A default trap-mapping is configured automatically when you install the Solstice EM trap daemon. When an SNMP trap arrives, Solstice EM uses this default mapping for converting the SNMP trap into a CMIP event notification. For information on customizing the Solstice EM trap daemon, see Section 11.7 Customizing the Mapping of SNMP Traps. The default method for specifying the source of the alarm is different for SNMPv1 and SNMPv2c. See the following sections for information specific to each version. The following default information is the same for both SNMPv1 and SNMPv2c:
- default perceivedSeverity values
- default probableCause values
- default additionalText information
- default event notification type
11.4.1 Default Method for Specifying the Source of an Alarm
11.4.1.1 SNMPv1
- When an SNMP trap arrives, em_snmp-trap extracts the IP address from the <agent-addr> field in the SNMP trap and uses this information to determine if there is an object configured in the MIS to represent that agent system. By default, a cmipsnmpProxyAgent object instance in the MIS is used to represent SNMP agent systems. The following methods specify the alarm source for SNMPv1.
- If there is a cmipsnmpProxyAgent object in the MIS corresponding to the IP address in <agent-addr>, em_snmp-trap's default method of operation is to set the originating system's cmipsnmpProxyAgent as the source object instance for this alarm.
- If there is no managed object instance in the MIS corresponding to the IP address of the SNMP trap, the trap daemon attempts to retrieve the hostname of the source agent, but if this is not possible, the trap daemon sets the value of cmipsnmpProxyAgentId to "<IP-address>".
- If there are multiple objects in the MIS that have network addresses that match the IP address of the trap, em_snmp-trap seeks a match on the SNMP Community String values included in the trap header. For example, an SNMP agent may be a proxy for legacy devices, and the Community String provides information that is used to identify the source device for the alarm.
11.4.1.2 SNMPv2c
- When an SNMPv2c trap arrives, em_snmp-trap extracts the source IP address from the UDP header information in the SNMP trap and uses this information to determine if there is an object configured in the MIS to represent that agent system. By default, a cmipsnmpProxyAgent object instance in the MIS is used to represent SNMP agent systems. The following methods specify the alarm source for SNMPv2c.
- If there is a cmipsnmpProxyAgent object in the MIS corresponding to the source IP address in UDP header information, em_snmp-trap daemon's default operation is to set the originating system's cmipsnmpProxyAgent as the source object instance for this alarm.
- If there is no managed object instance in the MIS corresponding to the IP address of the SNMP trap, the trap daemon attempts to retrieve the hostname of the source agent, but if this is not possible, the trap daemon sets the value of cmipsnmpProxyAgentId to "<IP-address>".
- If there are multiple objects in the MIS that have network addresses that match the IP address of the trap, em_snmp-trap seeks a match on the SNMP Community String values included in the trap header. For example, an SNMP agent may be a proxy for legacy devices, and the Community String provides information that is used to identify the source device for the alarm.
11.4.2 Default perceivedSeverity Values
Severity is the presumed importance or impact of an event. Following the ITU X.721 standard, Solstice EM uses an attribute in event notifications called perceivedSeverity to represent severity of events. The Alarm Service, which monitors the alarm log, uses the perceivedSeverity value in event notifications to determine the fault status indication for devices. The Alarm Service sets the fault status of a device to the highest perceivedSeverity of outstanding (uncleared) alarms for that device. The fault status of a device, as determined by the Alarm Service, is represented in the Network Views by icon color. The default mapping of severities to colors is described in the following figure. If event notifications are to affect fault status indication, they need to have a perceivedSeverity value.
TABLE 11-4 Default Color-Coding of Severities 1 Critical Red 2 Major Orange 3 Minor Cyan 4 Warning Yellow 5 Cleared No color 0 Indeterminate Blue
SNMP, however, lacks a systematic concept of the severity of a trap. A function of the trap-mapping is to assign a severity to event notifications based on information in the SNMP trap.
For SNMPv1, the default trap-mapping uses the <generic-trap> value to make severity assignments as follows:
- coldStart traps--warning
- warmStart traps--major
- linkDown traps--major
- linkUp traps--cleared
- authenticationFailure traps--major
- egpNeighborLoss traps--warning
- enterpriseSpecific traps--indeterminate
Note LinkUp traps automatically clears previous linkDown traps from the same router.
For SNMPv2c, the default severity is indeterminate.
You can easily change these severity assignments if you wish. For example, the mapping record for linkDown traps in the default trap_maps file contains the following line:
perceivedSeverity=major;If you want linkDown traps to have a severity of critical, simply edit the trap_maps file to replace "major" with "critical". This change takes effect when the trap daemon is restarted. Customizing the trap mapping is discussed in detail in Section 11.7 Customizing the Mapping of SNMP Traps. For information on the Alarm Service, see Chapter 4.
11.4.3 Default probableCause Values
For SNMPv1, the default trap-mapping assigns integer values to the probableCause attribute in event notifications as follows:
- coldStart traps--100
- warmStart traps--200
- linkDown traps--The value from the first variable binding attribute/value pair. By convention, this is the ifIndex, indicating the number of the interface.
- linkUp traps--The value from the first variable binding attribute/value pair.
- authenticationFailure traps--500
- egpNeighborLoss traps--600
- enterpriseSpecific traps--Set to the specific trap type, in localForm (integer).
- For example, if an enterpriseSpecific trap has a trap specific type of 99, this will be the value of probableCause for the enterpriseSpecificTrap notification generated by the trap daemon.
- For SNMPv2c, the default probablyCause value is set to TrapOid.
11.4.4 Default additionalText Information
For SNMPv1 and SNMPv2c, the default trap-mapping uses the additionalText field in the event notification to contain the following information:
- The enterprise identifier from the trap <enterprise> field
- The <specific-trap> value (typically 0 for traps other than enterpriseSpecific traps) - This is used for SNMPv1 only
- The <trapoid> value - This is used for SNMPv2c only
- The attribute/value pairs from the trap variable bindings
For an SNMPv2c trap, the trap mapping mechanism tries to derive the enterprise and specific trap field values by using methods defined in RFC 2089.
- An SNMPv2c trap may also contain the TrapOid value.
11.4.5 Default Event Notification Type
By default, the trap daemon converts SNMP traps into Solstice EM-specific event notifications as indicated in the following table.
The default trap-mapping options ensures that every incoming SNMP trap matches some trap-mapping record in the trap_maps file. This is done by including in the trap_maps file a mapping block that specifies a mapping for each <generic-trap> type. The default mapping block is of the following form:
enterprise 1.3.6.1.4.1{<mapping-record-1>...<mapping-record-N>}The identifier "1.3.6.1.4.1" acts like a wildcard in that it matches the <identifier> field of every trap.
Mapping blocks can also be added to the trap_maps file that use other enterprise identifiers to map SNMP traps generated by agents supplied by particular venders. How to do this is discussed below in Section 11.7 Customizing the Mapping of SNMP Traps.
11.4.6 Default Location of Information from Trap Variable Bindings
The default mapping scheme loads the attribute/value pairs from the trap variable bindings into the additionalText field of the event notification. This behavior is the same for both SNMPv1 and SNMPv2c.
11.5 Trap Daemon Behavior When No Mapping is Provided
This section describes how the trap daemon handles incoming SNMP traps in any situation where no explicit mapping is provided by the trap_maps file. This situation could happen, for example, if you delete the default mapping block, or if some of the records within it are deleted.
Solstice EM handles SNMPv1 and SNMPv2c traps that have no explicit mapping in the same manner.
If an incoming SNMP trap fails to match any entry in the trap_maps file, the trap daemon converts the SNMP trap into an internetAlarm, in accordance with the ISO-Internet Management Co-existence (IIMC) standard. The IIMC standard defines the use of the ISO/ITU Common Management Information Protocol (CMIP) for integrated management of TCP/IP networks that are managed using SNMP. The IIMC standard prescribes the following:
- Event notification type is internetAlarm.
- The perceivedSeverity value of internetAlarms is set to indeterminate.
- The alarm is posted against the cmipsnmpProxyAgent that represents the agent system.
- The attribute/value pairs that comprise the trap variable bindings are loaded into the additionalText field of the internetAlarm.
The user-configurable trap-mapping capability of the Solstice EM trap daemon is designed to address these limitations of SNMP and the IIMC standard. This capability allows you to configure the trap daemon to extract information from SNMP traps to create more meaningful alarms, tailored to your particular network management needs.
11.6 Format of trap_maps File
The trap_maps file is a daemon that listens for incoming SNMP traps for forwarding to management stations. This file contains different parts including:
- Enterprise mapping blocks
- Mapping records
- <attr-value> definitions
11.6.1 Enterprise Mapping Blocks
The trap mapping file consists of blocks of records, with each block identified by the keyword enterprise. The form of these blocks of records is different for SNMPv1 and SNMPV2c. See the following sections for SNMPv1 and SNMPV2c enterprise mapping block information.
11.6.1.1 SNMPv1
Each block is in the following form:
enterprise <enterprise-object-identifier>{<trap-mapping-record1>....<trap-mapping-recordN>}The mapping records (one or more) for a given enterprise are grouped within a pair of curly braces. Enterprise object identifiers are specified in dot-dot notation.
Enterprise blocks in the trap_maps file select incoming traps for mapping if the <enterprise-object-identifier> in the block heading matches the <enterprise> field in the trap. Three important aspects of the enterprise heading:
- enterprise block <enterprise-object-identifier> does not need to be identical with the <enterprise> field of the trap. For example, if the trap <enterprise> identifier is "1.3.6.1.4.1.42.1.2", this will match an enterprise block with "1.3.6.1.4.1" in the heading. So long as the enterprise block identifier is contained in the <enterprise> field, starting at the left, a match will occur.
- A trap is mapped by the enterprise block in the trap_maps file whose enterprise heading is most specific to the trap.
- Traps are checked against the enterprise blocks in the trap_maps file. The more specific enterprise values are matched first.
11.6.1.2 SNMPv2c
Each block is in the following form:
enterprise <enterprise-oid> | NO-ENTERPRISE{<trap-mapping-record1>....<trap-mapping-recordN>}The mapping records (one or more) for a given enterprise are grouped within a pair of curly braces. Enterprise object identifiers are specified in dot-dot notation.
Enterprise blocks in the trap_maps file select incoming traps for mapping if the <enterprise-object-identifier> in the block heading matches the <enterprise> field in the trap. Three important aspects of the enterprise heading:
- enterprise block <enterprise-object-identifier> does not need to be identical with the <enterprise> field of the trap. For example, if the trap <enterprise> identifier is "1.3.6.1.4.1.42.1.2" this will match an enterprise block with "1.3.6.1.4.1" in the heading. So long as the enterprise block identifier is contained in the <enterprise> field, starting at the left, a match will occur.
- NO-ENTERPRISE - If no enterprise information is found in the trap variable binding for an SNMPv2c trap, the block specified with NO-ENTERPRISE will be mapped.
- A trap is mapped by the enterprise block in the trap_maps file whose enterprise heading is most specific to the trap.
- Traps are checked against the enterprise blocks in the trap_maps file. The more specific enterprise values are matched first.
11.6.2 Mapping Records
The trap-mapping records are defined by the event notification. You can use either standard notifications (see TABLE 11-6) or create your own custom event types. For more information, refer to the Management Information Server (MIS) Guide
.The trap-mapping records are different for SNMPv1 and SNMPV2c. Both versions of SNMP use:
- <attr-value> Definitions
- CMIP notification managedObjectClass
- Attribute value types
- Wild cards for trap_mapping
- FDN templates
When selecting an event type for trap mapping, you will also want to ensure that the selected event type is logged to the alarm log. Logging the event type to the alarm log will ensure that the incoming traps cause appropriate changes in Network Views icon color. By default, only the following event types are excluded from the AlarmLog:
- objectCreation
- objectDeletion
- attributeValueChange
- stateChange
See the following sections for SNMPv1 and SNMPV2c enterprise mapping block information.
11.6.2.1 SNMPv1
If the trap daemon determines that an incoming trap matches a mapping block on its <enterprise> identifier, the trap daemon then uses the first mapping record within the selected block that matches the trap on the following two fields:
- <generic-trap>
- <specific-trap>
If the trap fails to match any record in the enterprise mapping block on trap type, the trap daemon checks the following enterprise blocks in the file for a possible match. If the trap matches no mapping record in any matching enterprise block, it is mapped into an internetAlarm, in the manner described in Section 11.5 Trap Daemon Behavior When No Mapping is Provided.
Mapping blocks can be used to provide a mapping for enterprise-specific traps--for example, if the agent software provided with a server generates an enterprise-specific trap (indicated by a <generic-trap> value of 6) with a <specific-trap> value of 5 when the machine's internal temperature exceeds an acceptable threshold, this could be mapped to a CMIP environmentalAlarm with probableCause and perceivedSeverity set to appropriate values. The type of value appropriate to an alarm attribute depends upon the GDMO definition of that event type.
SNMP traps can be mapped to any type of CMIP event notification the MIS knows about.
Each SNMPv1 record in an enterprise block in the trap_maps file has the format shown below:
FIGURE 11-4 SNMPv1 Trap Mapping Record Format
- <generic-trap> is an integer in the range of 0-6.
- <specific-trap> is an optional entry. Typically, <specific-trap> will be specified only when <generic-trap> is 6, indicating an enterprise-specific trap.
- <alarm-type> is any defined notification in the platform; a keyword DISCARD can be used to discard this trap.
- <attr-name> is a form [CONVERT] attribute=value;
See Section 11.6.3 <attr-value> Definitions for more information.SNMP traps are selected for mapping to specified CMIP event notifications only if they match a mapping record on enterprise object identifier and generic and specific trap type. If there is a match on these three values, the trap is converted to the CMIP event notification type indicated by the keyword NOTIFICATION. For example, you might choose to map an SNMP linkDown trap to a CMIP communicationsAlarm, as in the following example.
The type of event notification specified by NOTIFICATION in a mapping record can be any CMIP event notification which the MIS knows about. Alternatively, you can use the keyword DISCARD to indicate that a matching trap is to be discarded by the trap daemon.
A mapping for one or more event attributes can be entered after the keyword ATTRIBUTE-MAP. <attr-name> must be a valid attribute for the event type specified by <alarm-type>.
11.6.2.2 SNMPv2c
The SNMMPv2c trap map record is similar to SNMPv1, except that trapOid is matched instead of generic and specific trap values. Once the match is found, that mapping record is applied.
Each SNMPv2c record in an enterprise block in the trap_maps file has the format shown in the following example.
TRAPOID <trapoid_list>NOTIFICATION <alarm-type> | DISCARD[ ATTRIBUTE-MAP <attr-name>=<attr-value>; ][ <attr-nameN>=<attr-valueN>; ]FDN-MAP[ <FDN-template> ];;
- <trapoid_list> is a list of object identifiers, expressed in dot notation, which should match the snmpTrapOID.0 varbind in SNMPv2c traps. A list of comma-separated trapoids can be used, and each trapoid can contain wildcards. See Section 11.7.5 Wild Cards for trap_mapping for more information.
- notification is any defined notification in the platform; a keyword DISCARD can be used to discard this trap.
- attribute-map is a form [CONVERT] attribute=value;
See Section 11.6.3 <attr-value> Definitions for more information. This field is optional.- managed_object_class is optional. See Section 11.7.3 Configuring CMIP notification managedObjectClass for more information.
For example:
11.6.3 <attr-value> Definitions
The <attr-value> definitions are used by both SNMPv1 and SNMPv2c.
<attr-value> can be defined as one of the following:
- a constant
- a trap variable binding value
- the keyword $ALLVARS
<attr-value> definitions are the same for SNMPv1 and SNMPv2c.
11.6.3.1 Constant
In the following example, the severity of the alarm is set to critical and a string constant is passed as additionalText.
ATTRIBUTE-MAPperceivedSeverity=critical;probableCause=localValue : 100;additionalText="Network memory usage greater than 80%";If a constant is used for <attr-value>, it must be of a type appropriate for the particular event notification attribute in proper ASN.1 string format. 11.6.3.2 Trap Variable Binding Value
In the following example, varbindvalue2 indicates the value of the second variable binding name/value pair in the SNMP trap.
probableCause=varbindvalue2;11.6.3.3 Trap Variable Binding Name
Varbind names can be referenced in the trap_maps file using a varbindNameN variable analogous to a varbindValueN variable, where N is the varbind number. In the following example, varbindname2 indicates the value of the second variable binding name/value pair in the SNMP trap.
GENERIC-TRAP 6SPECIFIC-TRAP 13-25, 27, 29, 31-40NOTIFICATION enterpriseSpecificTrapATTRIBUTE-MAPprobableCause=varbindName2;perceivedSeverity=indeterminate;additionalText=$ALLVARS;FDN-MAP;;11.6.3.4 Trap Variable Binding Index
Varbind names can be referenced in the trap_maps file using a varbindIndexN using variable analogous to a varbind varbindValueN variable. In the following example, varbindindex2 indicates the value of the second variable binding name/value pair in the SNMP trap.
GENERIC-TRAP 6SPECIFIC-TRAP 13-25, 27, 29, 31-40NOTIFICATION enterpriseSpecificTrapATTRIBUTE-MAPprobableCause=varbindIndex2;perceivedSeverity=indeterminate;additionalText=$ALLVARS;FDN-MAP;;11.6.3.5 Embedding Strings in varbind Expressions
Solstice EM supports mapping of notification attributes to strings embedded in SNMP trap varbind variables (for example, $varbindNameN, $varbindValueN, and $varbindIndexN). Solstice EM also allow you to embed simple arithmetic expressions in varbind variables. These simple arithmetic expressions contain basic arithmetic operations on integer varbind values and integer constants. The arithmetic expressions are embedded by enclosing them between backquotes ('). The following operations are supported in the arithmetic expressions.
- Addition, for example, " ...'$varbindValue1 + 10'..."
- Subtraction, for example,
"...'$varbindValue2 - $varbindValue1'..."- Multiplication, for example, "...'$varbindValue3 * 16'..."
- Division, for example, "...'$varbindValue2 / $varbindValue1'..."
- Unary minus, for example, "...'-$varbindValue1'..."
The following is an example of an embedded arithmetic expression.
11.6.3.6 Defining and Using varbind-to-substring Tables
Tables that map integer SNMP trap varbind values to substrings can be defined by a table construct in the trap_maps configuration file. Such substrings can be embedded in strings that map CMIP notification attributes (in an enterprise ATTRIBUTE-MAP clause) by indexing the corresponding varbind-to-substring table with an integer varbind value or an integer constant. The syntax of the table construct is as follows:
table <table-id> {<index1>: <substring1>
[<indexN>: <substringN>]}
- <table-id> is the table identifier comprised of a case-sensitive sequence of alphanumeric characters beginning with a letter (for example, ProblemDescription, NetworkCardType, contacts). The table identifiers must be unique in the scope of its trap_maps file. All subsequent duplicate identifier tables found are discarded. A proper message is logged to indicate this parsing error.
- <indexN> is the table entry index, a 32-bit signed integer constant in decimal notation, e.g., 0, 64, -900. This table entry index must be unique within the scope of the table where it is defined.
- <substringN> is the table entry substring, a sequence of printable characters enclosed by a pair of double quotes ("), which cannot be part of the string.
- After being defined, a table can then be indexed by integer varbind values--for example, $varbinValueN, or integer constants (32-bit signed integer constants in decimal notation) from within a CMIP notification attribute mapping entry (in the enterprise ATTRIBUTE-MAP clause). Such table references have the following syntax:
ATTRIBUTE-MAP...
<attr-name> = " ...$<table-id>[<index>]...";
...- where <index> is one of the following:
- An integer varbind value (for example, $varbindValueN whose type is SNMP INTEGER, Counter, Gauge, or TimeTicks, converted to 32-bit signed integer)
- A 32-bit signed integer constant in decimal notation (for example, 0, 16, -120)
11.7 Customizing the Mapping of SNMP Traps
The Solstice EM trap-mapping capability is designed to enable you to customize the mapping of SNMP traps to CMIP event notifications.
11.7.1 Overview
SNMP lacks a systematic notion of the severity of an alarm. Also, the IIMC standard lacks a systematic method for determining the source component for a trap within the agent system. The user-configurable trap-mapping capability of the Solstice EM trap daemon is designed to address these limitations of SNMP. This capability allows you to configure the trap daemon to extract information from SNMP traps to create more meaningful alarms, tailored to your particular network management needs.
The trap-mapping activity of the SNMP trap daemon can be customized by editing the trap_maps file. Your modifications take effect after the trap daemon is restarted.
11.7.2 How to Customize SNMP Trap Mapping
This section provides the steps to configure em_snmp-trap for SNMPv1 and SNMPv2c trap mapping.
![]()
To Customize SNMP Trap Mapping
1. Collect information on enterprise-specific traps.
- If you want to add mapping blocks to map enterprise-specific traps, consult the vendor documentation for SNMP devices deployed in your network to determine which variable bindings and specific trap values to use for mapping into event notification attributes and to identify components that are sources of events.
2. Devise your mapping scheme.
- There are four aspects to the mapping:
- Creating enterprise blocks, if desired.
- These should be entered above the default enterprise block in the trap_maps file.
- Creating records within a block that map traps to event notification type based on generic and specific trap value for SNMPv1 and trapoid for SNMPv2c.
- This is discussed in Section 11.5 Trap Daemon Behavior When No Mapping is Provided. You can also create mapping records that instruct the trap daemon to discard matching traps.
- Creating a mapping for event notification attribute values within mapping records.
- This is discussed below in Section 11.7 Customizing the Mapping of SNMP Traps.
- Adding an FDN map to mapping records, if desired.
- An FDN map is a template that is used by the trap daemon to identify the component element that is the source of the event. This is discussed below in Section 11.7.6 Using FDN Templates to Specify the Source of a Trap.
3. Verify that the event types selected for mapping are logged to the alarm log.
- Use the Event Logs to check the discriminator that selects events for logging to the alarm log. If your selected event type is excluded, you may want to change the log discriminator.
4. Edit the trap_maps file.
- Using your favorite text editor (such as vi), add your mapping elements to the file, with each record conforming to the format shown in the above example.
5. Save the file.
- /etc/opt/SUNWconn/em/conf/trap_maps is the file location.
6. Restart the trap daemon.7. Verify that there are no error messages at startup.
- When em_snmp-trap reads the trap_maps file at startup, it prints error messages if it encounters any parsing errors in the trap mapping table. Verify that no errors occur when em_snmp-trap is restarted.
Note Startup of em_snmp-trap is terminated if errors are detected in the trap_maps file.
11.7.3 Configuring CMIP notification managedObjectClass
The managedObjectclass of a notification of an SNMP trap-to-CMIP notification mapping defaults to one of the following:
- If the FDN is defined in the FDN-MAP clause of the trap mapping entry, it defaults to actualClass, for example, globalForm:{2 9 3 4 3 42}
- If the FDN is not defined in the FDN-Map clause, it defaults to "iimcManagementProxyMIB":cmipsnmpProxyAgent class
You can override the managedObjectclass default if the FDN is defined in the FDN-MAP clause of the trap mapping entry. To override the default value (actualClass), specify the managed object class of the notification from within a trap mapping entry in the trap_maps file. The syntax of the CLASS-MAP clause is:
enterprise <enterprise-object-id> {...
[CLASS-MAP <managed-object-class>]
FDN-MAP <FDN-template> ;;}
- where
- <managed-object-class> is the GDMO managed object class to be mapped to the notification managedObjectClass, for example, "IIMCCISCO-MIB":lsystem, or circuit
- In case CLASS-MAP clause is present, a FDN is expected in the <FDN-template> of the corresponding FDN-MAP clause
- The following illustrates the usage of CLASS-MAP clause:
11.7.3.1 The Keyword $ALLVARS
This keyword is used only with a text field. The $ALLVARS keyword specifies that the text field is to receive the following information:
- The <enterprise> identifier of the trap
- The <specific-trap> value for SNMPv1 or <trapoid> for SNMPv2c
- All of the attribute/value pairs comprising the trap variable bindings
Note The SNMPv2c trap does not usually have the enterprise and specific trap fields. When $ALLVARS is used for an SNMPv2c trap, the trap mapping mechanism tries to derive these values by using methods defined in RFC 2089. If the snmpTrapEnterprise.0 variable binding is in the list of variable bindings, it is ignored because it would be a duplicate of the enterprise field.
In this example,
additionalText = $ALLVARS;Sample output from this mapping would be an additionalText field that looks like the following:
enterprise = 1.3.6.1.4.1.42 , specificTrap = 1 , ifNumber = 5 , ifType = other , ifIndex = 3 , ifDescr = THIS IS A STRINGEach mapping of an attribute to a value must end in a semicolon.
The Solstice EM Alarm Service requires that an alarm have a perceivedSeverity value (an integer value in the range of 0 to 5) in order to map to Network Views icon colors that represent the importance of a network event. The valid severities and their default associated icon colors are listed in TABLE 11-4.
The mapping of severity to displayed color is controlled by the Solstice EM Nerve Center; this mapping is user-configurable via the Design Advanced Requests application. See Chapter 18 for more information.
The interpretation of <specific-trap> values for enterprise-specific traps depends upon the particular implementation by the product vendor. You will need to consult the product documentation for SNMP devices in your network to determine an appropriate mapping to CMIP event notifications.
SNMP traps that do not match any record in the mapping file on <enterprise>, <generic-trap>, and <specific-trap> are mapped to default IIMC internetAlarms as described in Section 11.5 Trap Daemon Behavior When No Mapping is Provided.
Some useful considerations in customizing the trap_maps file:
- ATTRIBUTE-MAP is an optional entry. However, you will want to include a mapping for at least the attributes defined as REQUIRED attributes in the GDMO definition of the alarm type specified as NOTIFICATION.
- Two semicolons are required to mark the end of each record.
- Case is ignored for all keywords in the trap_maps file.
- Comments can be interspersed in the file. Any line that begins with a pound sign (#) as the first character in the line at the left is treated as a comment.
Note If you specify a mapping of attributes for internetAlarms, the only attributes that will be included in the alarm are the required attributes and any optional attributes whose mapping you have specified.
11.7.3.2 The Keyword $NORFC2089
This keyword is used only with a text field and used only for SNMPv2c. The $NORFC2089 keyword is similar to the $ALLVARS keyword in that it specifies that the text field is to receive the attribute/value pairs comprising the trap variable bindings. When the $NORFC2089 keyword is used, the varbinds are printed out in the order received instead of printing out in a format similar to that of SNMPv1.
In this example,
additionalText = $NORFC2089;Sample output from this mapping would be an additionalText field that looks like the following
additionalText = sysUpTime = 142100, snmpTrapOID = {1 3 6 1 6 3 1 1 5 3 }, ifIndex = 1Consider the example in case of $ALLVARS,
additionalText = $ALLVARS;Sample output from this mapping would be an additionalText field that looks like the following:
additionalText = "enterprise = 1.3.6.1.6.3.1.1.5,specificTrap = 0, sysUpTime = 128100, snmpTrapOID = {1 3 6 1 6 3 1 1 5 3}, ifIndex = 1"Each mapping of an attribute to a value must end in a semicolon.
11.7.4 Attribute Type Mapping
Attribute type mapping specifies how attribute types in a trap are mapped to attribute types in a notification. The permitted mapping between types is provided in the following table.
Note If you want to convert an OCTET STRING to an INTEGER, the OCTET STRING must not contain text.
To specify the attribute type mappings use the following:
[CONVERT] <attribute> = <value>
- <attribute> is any valid attribute type for the corresponding notification
- <value> is one of the following:
- a varbind variable, which can be one of the following:
- varbindvalue - yields the value of a varbind
- varbindindex - yields the index of the SNMP object the varbind refers to
- varbindname - is the OID of the object the varbind refers to
- ASN.1 string format constant. If value is an ASN.1 string format constant, the value must be the same as the attribute.
Specify the CONVERT keyword only if:
- <value> is a varbind
- the <value> and <attribute> types are different
If you want value and attribute types to be the same, you must omit the CONVERT keyword. Otherwise, the translation will fail.
The following illustrates the usage of attribute type conversion:
GENERIC-TRAP 6SPECIFIC-TRAP 101NOTIFICATION internetTrapINTEGERV1AlarmATTRIBUTE-MAPprobableCause = localValue : 101;CONVERTobjINTEGERV1 = varbindvalue1;FDN-MAP ;;}11.7.5 Wild Cards for trap_mapping
The trap_mapping wild cards are similar for SNMPv1 and SNMPv2c. See the following table for version specific information.
11.7.6 Using FDN Templates to Specify the Source of a Trap
For SNMPv1, when SNMP traps, em_snmp-trap extracts the IP address from the <agent-addr> field in the SNMP trap and uses this information to determine if there is an object configured in the MIS to represent that agent system. For SNMPV2c, when SNMP traps arrive, em_snmp_trap extracts the source IP address from the UPD header information in the SNMP trap and uses this information to determine if there is an object configured in the MIS to present the agent system.
By default, a cmipsnmpProxyAgent object instance in the MIS is used to represent the agent system. If there is a cmipsnmpProxyAgent object in the MIS corresponding to the IP address, em_snmp-trap's default method of operation is to convert the trap to an internetAlarm and set the originating system's cmipsnmpProxyAgent as the source object instance for this alarm. For example, if a linkDown trap arrives from router bigguy with IP address 129.144.55.67, em_snmp-trap sets the following as the fully distinguished name (FDN) for the alarm:
/systemId=name:"gatoloco"/internetClassId={1 3 6 1 4 1 42 2 2 2 9 2 4 1 0}/ cmipsnmpProxyAgentId="bigguy"This might not be the object instance that represents the specific component on which the event occurred. To point the event notification at the particular component object, you can specify a template to build an FDN that points to the specific component that is the source of the event, such as an interface on a router or a circuit in a switch. This template is indicated in the trap mapping record by the FDN-MAP keyword.
11.7.6.1 Understanding FDNs and RDNs
An FDN specifies an absolute path through the Management Information Tree (MIT) to an object instance. The FDN specifies the path to an object instance by indicating its "containment" relationships. Just as an object instance is a software entity that represents a particular network resource, the containment relationship between objects is used to model physical containment relationships, such as that between a router and its interface cards.
The format of an FDN is as follows:
/<naming-attribute1>=<value1>/<naming-attribute2>=<value2>/<naming-attribute3>=<value3>You can think of an FDN as analogous to an absolute path to a file in a UNIX file system. Each <naming-attribute>=<value> pair is a relative distinguished name (RDN) that specifies an object instance relative to the object specified by the portion of the FDN to its left.
An FDN consists of a concatenation of RDNs, with a slash (/) separating the RDNs. An RDN specifies an object instance only relative to the object which contains it. For example, the following RDN specifies the internetSystem group within our cmipsnmpProxyAgent for bigguy:
internetSystemId=NULLThus, if this RDN is appended to the FDN for bigguy's cmipsnmpProxyAgent in FIGURE 11-5, the result is an FDN that points to the internetSystem object instance for this SNMP agent:
FIGURE 11-5 Sample FDN for internetSystem Group Object Instance
![]()
In this example the particular MIS system where this cmipsnmpProxyAgent object instance resides is indicated by systemId=name:"gatoloco".
systemId, cmipsnmpProxyAgentId, and internetSystemId are examples of naming attributes. A naming attribute is an attribute whose value is an identification that is unique within the object that contains it (for example, a unique interface index within a router or a unique hostname within a subnet).
FIGURE 11-6 Sample ifTable FDNThe value of a naming attribute depends on whether the object is a scalar object or a columnar object. (i.e., whether the object can have only one instance or multiple instances in an SNMP agent). For scalar objects, the value of the naming attribute is NULL. For columnar objects, the value is a sequence of the values of the indices for that entry. For example, there can be only one ifTable in an SNMP agent, hence ifTableId=NULL, but ifEntryId={ifIndex2}, ifIndex being the index for ifTable.
11.7.6.2 Building FDN Templates
The function of an FDN template is to enable em_snmp-trap to compose an FDN that represents the target component within the agent system.
The FDN template is preceded by the keyword FDN-MAP. FDN templates can follow one of two formats:
Standard Format:
<naming-attribute>=NULL/<naming-attribute>=NULL/<naming-attribute>={<instance-indices>}where <value> is either a constant or specifies a variable binding value. A variable binding value is specified by expressions of the form varbindvalue1, varbindvalue2, and so on.
- The standard RDN template lacks an initial slash at the far left. This indicates that the FDN built from the template is to be appended to the FDN that specifies the cmipsnmpProxyAgent object instance FDN. The object instance representing the target component is thus contained under the cmipsnmpProxyAgent object. The standard format enables em_snmp-trap to more finely specify the component within the agent system represented by the default cmipsnmpProxyAgent object. The example in FIGURE 11-7 shows an FDN template with the standard format. Instance indices are used in specifying attribute values.
- The absolute format FDN template specifies the full FDN path to the target component from root. The absolute format FDN template is distinguished by the presence of an initial slash at the left. The initial slash indicates to em_snmp-trap that it is not to append the FDN built from the template to the default cmipsnmpProxyAgent FDN. Class names cannot be used in specifying attribute values. Constants or variable binding values are used to indicate attribute values. For example:
/systemId=name:"bigguy"/myClassId=varbindvalue3The example in Table 10-4 has the following FDN template:
FIGURE 11-7 Sample FDN TemplateAn SNMP trap variable binding field used in a template is specified in the following form:
where N is the number of the variable binding you want to use.
11.8 Distributed Trap Handling
The SNMP trap daemon can be distributed to machines in your network other than workstations running the MIS. The names of MIS machines for forwarding of event notifications are specified when the trap daemon is installed.
However, if the trap daemon is to connect to the MIS on another machine, you will need to do the following.
![]()
To Connect the Trap daemon to the MIS
1. Edit the /var/opt/SUNWconn/em/conf/EM-config file on the MIS machine.
2. Restart the MIS, if necessary.
- If the MIS is already running on the target MIS machine, use the em_services command to restart the MIS.
11.8.1 Filtering SNMP Traps for Other Managers
The Solstice EM SNMP trap daemon has the ability to filter raw (unprocessed) SNMP traps to other managers. The trap daemon can forward or exclude/discard the raw SNMP traps (both SNMPv1 and SNMPv2c). When you install the SNMP trap daemon, you are prompted for the hostname and port for each SNMP manager that is to receive forwarded SNMP trap PDUs. This information is stored in the trap_forward file in the /etc/opt/SUNWconn/em/conf directory; an ASCII text file that the em_snmp-trap daemon reads whenever it starts.
The trap_forward file has the following format. The keyword is different for SNMPv1 and SNMPv2c.
MIS_HOSTS: <MIS-host1>,<MIS-host2>SNMP_HOSTS: <mgr_hostname1>:<port1>, <mgr_hostname2>:<port2>orSNMPV2_HOSTS: <mgr_Host>:<port1>,<mbr_hostname2>:<port2>The MIS_HOSTS line contains the names of the machines where an MIS is running that the trap daemon is to connect to. Each MIS machine name is separated by commas.
The SNMP_HOSTS/SNMPV2_HOSTS line contains the hostname and port number for each SNMP manager that is to receive the raw SNMPv1/SNMPV2c traps. Entries for multiple managers are separated by commas.
To exclude/discard the filtered raw SNMP traps, enter DISCARD in the trap-filtering-record in the trap_forward file. The trap-filtering-record for SNMPv1 has the following format:
GENERIC-TRAP gen_trap_rangeSPECIFIC-TRAP spec_trap_range OPTIONALDISCARD: <mgr_hostname1>:<port1>, <mgr_hostname2>:<port2>The trap-filtering-record for SNMPv2c has the following format:
TRAPOID trapoid_listDISCARD
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |