How to ensure there is a rule set configured to receive traps and display them in the Live Exceptions browser

Document ID : KB000023167
Last Modified Date : 14/02/2018
Show Technical Document Details

Question:

How do I ensure there is a rule set configured to receive traps and display them in the Live Exceptions browser?

 

Answer:

1. Identify the trap in question in the TrapEXPLODER log file. ( Fore more information on determining if TrapEXPLODER is receiving traps, see How to verify trapExploder is receiving traps forwarded from an external source )

2. Obtain the Trap Type, Specific Type, and OID from the trap listing. With that information, translate this to an actual object description.

Example :

nhTestTrapRule [ -h ] [ -rev ] [ -v ] [ -u ][ -gt <genericType> ]

     [ -st <specificType> ] [ -e <enterpriseOid> ]

     [ -b <variable> <oid> <type> <value>... ]

-h   (Optional) Displays this command usage.

-rev (Optional) Displays the eHealth software revision.

-v   (Optional) Displays output messages in verbose mode.

-u     (Optional) Outputs the userMessage variable as a list of arguments and

     skips substitutions. The userMessage variable is one of eight variables

     that compose the User-Visible Information section of the TRF. This

     section defines the format of all user-visible information that appears

     in the Live Exceptions Browser or the Rule Editor dialog box.

-gt <genericType>

     (Optional) Specifies a generic trap type (numeric). The default is 0.

-st <specificType>

     (Optional) Specifies a specific trap type (numeric). The default is 0.

-e <enterpriseOid>

     (Optional) Specifies the enterprise OID (for example: 1.3.1.1.4.1.540).

     The default is 0.0.

-b <variable> <oid> <type> <value>

    (Optional) Specifies variable bindings lists consisting of three

     bindings: <variable>, <oid>, <type>, and <value>, separated by single

     spaces. The list functions as a data field in the SNMP protocol data

     unit (PDU) by binding objects with their current values. <variable>

     specifies the nam.e of the variable. <oid> specifies an ASN.1 object

     identifier (for example, .1.3.6.1.2.1.2.2.1). A symbolic OID must

     appear in one of the loaded MIBs or in a standard RFC MIB. <type>

     specifies the object type. oid, integer, and string are valid values.

     <value> specifies the value of the type. The value must be of the

     same object type specified by <type>. You must enclose empty strings

     with double-quotes created using escape sequences (that is, \").

     Enter long commands on one line.

 

The following example tests the generic type of 6 specific type 1 and 

enterprise Oid 1.3.6.1.4.1.546.1.1:

C:\eHealth\bin>nhTestTrapRule -gt 6 -st 1 -e 1.3.6.1.4.1.546.1.1

Rule empireApacheFootprintPercentCPU

----------------

eventName          "Apache Footprint Percent CPU"

eventType          "SystemEDGE Monitor - Apache Footprint"

eventDescription   "The percentage of CPU utilization, by Apache, over the last sample interval"

ipAddress          "0.0.0.0"

component          "Monitor entry: <Null>"

userMessage        "Description: <Null>, current value <Null> is <Null> threshold <Null>

1.3.6.1.2.1.1.3.0:0

1.3.6.1.6.3.1.1.4.1:1.3.6.1.4.1.546.1.1.0.1

1.3.6.1.6.3.18.1.3.0:0.0.0.0"

trapSense          1

eventCarrier       "Trap: Monitor Trap, Variable: apacheFootprintPercentCPU"

storeAllVarbinds   1

 

Also to find out what the generic type means in certified traps, look in the following file.

C:\eHealth\extensions\traps\sys\generic.trf

Certified Traps

# Traps:

#0       coldStart

#1       warmStart

#2      linkDown

#3       linkUp

#4       authenticationFailure

#5       egpNeighborLoss

#6 All other traps will be vender specific or uncertified traps .

 

3. Utilize the $NH_HOME/bin/nhTestTrapRule command, using the data obtained from step 2, to show what specific Event Type and Event Name should be used to match the trap in question. If the specific OID or a general rule containing that OID does not exist, then the trap is not currently certified and a Certification Request would need to be submitted. To submit a Certification Request, please follow the instructions found in Knowledgebase Solution ID TS6390. Alternatively, you can also create your own custom *.trf file for use in recognizing the uncertified trap. To learn how to create a custom *.trf file, please review the documentation referenced in the Knowledgebase Solution ID TS8893. Run the command with the -h flag to see the proper usage. Note the example given at the end of the help output and how it specifies the exact Event Type and Event Name that is necessary to trigger an LE alarm against the trap type in question.

4. Search the current profiles/rules sets to determine if a rule already exists to handle this trap type.

5. If not, create a new rule to associate with this trap type.

6. Apply the specific profile/rule to the group containing the source element.

7. The traps should now appear for that group using the rule set associated.

.