Solstice Enterprise Manager 4.1 Customizing Guide Doc SetContentsPreviousNextIndex

Chapter 11

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:

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 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 Operation

There are two ways the SNMP trap daemon can be started or stopped:

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 412

11.2.2 Stopping the Trap Daemon

 

To Stop the Trap Daemon 

# em_trapd stop

The following command stops 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 Structure

The fields are as follows:

TABLE 11-1   SNMPV1 Field Descriptions
Field Description
<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.

TABLE 11-2   Standard SNMP Trap Types
Value of <generic-trap> Trap Type Description
0
 coldStart
 The originating SNMP device is reinitializing itself, typically due to unexpected reboot.
1
 warmStart
 The originating SNMP device is reinitializing itself, typically due to normal restart.
2
 linkDown
 One of the agent's communication links is down. The first name/value pair in the variable bindings is the ifIndex for the interface.
3
 linkUp
 One of the agent's communication links has come up. The first name/value pair in the variable bindings is the ifIndex for the interface.
4
 authenticationFailure
 The originating system has received a protocol message that has failed authentication.
5
 egpNeighborLoss
 An External Gateway Protocol peer has been marked down.
6
 enterpriseSpecific
 Further information about the event is indicated in the <specific-trap> field.


11.3.2 SNMPv2c

The SNMPv2c trap PDU differs substantially from the SNMPv1. The SNMPv2c PDU does not contain the following information:

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 Structure

The fields are as follows:

TABLE 11-3   SNMPV2c Field Descriptions
Field Description
<type>
 Indicates the type of SNMP message. (In this case, it indicates that this is a trap PDU.)
<request_id>
 The sequential number of the trap.
<error_status>
 This field is always set to 0 for SNMPv2c traps.
<error-index>
 This field is always set to 0 for SNMPv2c traps.
<variable-bindings>
 Information that varies depending upon the particular implementation by the product vender. The format consists of attribute/value pairs. Each attribute name is followed by its value.


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:

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.

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.

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
Integer Value Severity Default Color
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:

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:

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:

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.

TABLE 11-5   Default IP Management Trap Event Types  
Generic Trap Type Event Notification
coldStart
 coldStartTrap
warmStart
 warmStartTrap
linkDown
 linkDownTrap
linkUp
 linkUpTrap
authentication Failure
 authenticationFailureTrap
EGP Neighbor Loss
 egpNeighborLossTrap
Enterprise specific
 enterpriseSpecificTrap


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:

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:

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:

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:

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

TABLE 11-6   Standard Event Notifications 
Standard Event Notification
ISO X.722
 objectCreation


objectDeletion


attributeValueChange


relationshipChange


stateChange


communicationsAlarm


environmentalAlarm


equipmentAlarm


integrityViolation


operationalViolation


physicalViolation


processingErrorAlarm


qualityofServiceAlarm


securityServiceOrMechanismViolation


timeDomainViolation
IIMC
 internetAlarm
Solstice EM-specific
 snmAlarmEvent


snmAlarmTrap


nerveCenterAlarm


coldStartTrap


warmStartTrap


linkDownTrap


linkUpTrap


authenticationFailureTrap


egpNeighborLossTrap


enterpriseSpecificTrap


.

The trap-mapping records are different for SNMPv1 and SNMPV2c. Both versions of SNMP use:

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:

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:

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:

  GENERIC-TRAP <generic-trap>

[ SPECIFIC-TRAP <specific-trap> ]

  NOTIFICATION  <alarm-type>  | DISCARD 

[ ATTRIBUTE-MAP <attr-name>=<attr-value>; ]

[                                   <attr-nameN>=<attr-valueN>;  ]

 FDN-MAP[ <FDN-template> ];;

FIGURE 11-4   SNMPv1 Trap Mapping Record Format

Where

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. 

enterprise 1.3.6.1.4.1.42

{GENERIC-TRAP 2

NOTIFICATION communicationsAlarm

ATTRIBUTE-MAP

    perceivedSeverity=varbindvalue3;

    probableCause=varbindvalue2;

FDN-MAP

    interfacesId=NULL/ifTableId=NULL/ifEntryId={varbindvalue1};;}

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> ];;

Where:

For example:

enterprise 1.3.6.1.4.1.42

TRAPOID <trapoid_list>

NOTIFICATION communicationsAlarm

ATTRIBUTE-MAP

    perceivedSeverity=varbindvalue3;

    probableCause=varbindvalue2;

FDN-MAP

    interfacesId=NULL/ifTableId=NULL/ifEntryId={varbindvalue1};;}

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:

<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-MAP

     perceivedSeverity=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 6

	 SPECIFIC-TRAP 13-25, 27, 29, 31-40

	 NOTIFICATION enterpriseSpecificTrap

	 ATTRIBUTE-MAP

	 	 	 probableCause=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 6

	 SPECIFIC-TRAP 13-25, 27, 29, 31-40

	 NOTIFICATION enterpriseSpecificTrap

	 ATTRIBUTE-MAP

	 	 	 probableCause=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.






   The following is an example of an embedded arithmetic expression.



  
  

     

enterprise 1.3.6.1.4.1 {

 GENERIC-TRAP 6
SPECIFIC-TRAP 50-55
NOTIFICATION enterpriseSpecificTrap
ATTRIBUTE-MAP
 probableCaus=varbindValue3;
perceivedSeverity=minor;
additionalText="Board number '$varbindValue1 * 10 +
 $varbindValue2' has a problem of type $varbindValue3";
 FDN-MAP ;;
 }



  














   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>]

 

}


  














   where






   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:
  



 	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.


       

    1. To stop the trap daemon, enter the following command (as root):
      

      
  
  
      
     

      #em_trapd stop

      		
  
      

      



      
      
       

    2. Restart the trap daemon by entering the following command (as root):
      

      
  
  
      
     

      #em_trapd start

      		
  
      

      



      
      
      

      
   Note – During this operation, any traps that arrive on the system are lost.

      



 	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:






   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:



  
  

     

enterprise 1.3.6.1.4.1 {

 

GENERIC-TRAP 6

SPECIFIC-TRAP 100

NOTIFICATION enterpriseSpecificTrap

ATTRIBUTE-MAP

 

probableCause=varbindValue1;

perceivedSeverity=critical;

additionalText="$ALLVARS;

 

CLASS-MAP "OP1 Library Vol. 1":computerSystem

 

FDN-MAP /systemId=name:"mars"/computerSystemId="paris" ;;

 

}


  








  





   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 STRING


  














   Each 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:






   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 = 1


  














   Consider 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.



    

   TABLE 11-7 	  Attribute Value Type Conversions
  
 Varbind Type

     Permitted Event-Report Attribute Types

  

  

    
 INTEGER (+ Counter, Gauge, TimeTicks

    
 OCTET STRING, DisplayString, Opaque

  

  

    
 OCTET STRING and DisplayString

    
 INTEGER, OBJECT IDENTIFIER, NetworkAddress, DisplayString

  

  

    
 OBJECT IDENTIFIER

    
 OCTET STRING, Opaque, DisplayString

  

  

    
 NetworkAddress

    
 OCTET STRING, Opaque, DisplayString

  

  

    
 Opaque

    
 Opaque, OCTET STRING

  















   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>


  














   where:






   Specify the CONVERT keyword only if:






   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 6

 

    SPECIFIC-TRAP 101

 

    NOTIFICATION internetTrapINTEGERV1Alarm

 

    ATTRIBUTE-MAP

 

        probableCause = localValue : 101;

 

    CONVERT 

 

	 	 objINTEGERV1 = 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.



    

    

   TABLE 11-8 	  Wild Cards for trap_mapping  
  
 


     


     Examples

  

  
 Wild Card

     Description

     SNMPv1

     SNMPv2c

  

  

    
 Match All

    
 An asterisk wildcard can used to match all traps with a specific enterprise OID.

    
 GENERIC-TRAP *

    
 TRAPOID *

  

  

    
 Ranges

    
 A dash between two numbers can be used to match a range of values. For example, a numeric range can be listed which assigns different severities based on a trap's value.

    
 SPECIFIC-TRAP 0 - 12

    
 TRAPOID 0 - 12

  

  

    
 Open-Ended Ranges

    
 An asterisk can be used to match a specific number and higher.

    
 SPECIFIC-TRAP 26 - *

    
 TRAPOID 26 - *

  

  

    
 Sets

    
 A comma-separated set of values can be given to match a non-continuous set of values. The set may contain sub-ranges.

    
 SPECIFIC-TRAP 13 - 25, 27, 29, 31 - 40

    
 TRAPOID 13 - 25, 27, 29, 31 - 40

  

  

    
 Varbind Names

    
 Varbind names refer to the part of a varbind instance OID that names the object being referenced, minus index information.
 Varbind names can be referenced in the trap_maps file using a varbindNameN variable analogues to a valueValue variable, where N is the varbind number.

    
 1.3.6.1.2.1.2.2.1

    
 1.3.6.1.2.1.2.2.1

  

  

    
 Varbind Indexes

    
 Varbind indexes are the index value of varbind instances. They are 0 for scalar instances and index numbers for table entries. Varbind names can be referenced in the trap_maps file using a varbindIndexN using variable analogues to a varbind valueValue variable.

    
 


    
 


  

  

    
 Strings Containing Varbind Values

    
 A varbind value, name, or index is placed within a string by preceding its name with a dollar sign.
 Varbind values are converted into DisplayString representation for inclusion in a string.

    
 causeText = "The varbind value is $varbindValue";

    
 causeText = "The varbind value is $varbindValue";

  















   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=NULL


  














   Thus, 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 FDN


   The 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>}

 


  











    

      
  Absolute Format:



  
  

     

/<naming-attribute>=<value>/<naming-attribute>=<value>

 


  









    




   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 example in Table 10-4 has the following FDN template:






   




 FIGURE 11-7 	  Sample FDN Template


   An SNMP trap variable binding field used in a template is specified in the following form:






   varbindvalueN






   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.


  

     
  Add the name of the trap daemon machine to the entry EM_ACCESS_TRUSTED_HOSTS. For example, if you have installed the trap daemon on the machine empress, the EM-config file on each MIS machine it is to connect to should have the following line:



  
  

     

EM_ACCESS_TRUSTED_HOSTS:    empress


  








  



 	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>

 

or

 

SNMPV2_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_range

 

SPECIFIC-TRAP spec_trap_range OPTIONAL

 

DISCARD: <mgr_hostname1>:<port1>, <mgr_hostname2>:<port2>


  














   The trap-filtering-record for SNMPv2c has the following format:



  
  

     

TRAPOID trapoid_list

 

DISCARD


  

























Sun Microsystems, Inc.

Copyright information. All rights reserved.






Doc Set  |  
Contents
  |  
Previous
  |  
Next
  |  
Index