Additional SNMP Trap Receiver Tips and Techniques

From Control Solutions IoTServer Documentation
Revision as of 01:54, 22 May 2019 by Jimhogenson (talk | contribs) (Two-Level Trap Logging)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Trap Filters

The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:


Snmptrapd-conf edit detail 1.jpg


This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules.

The traphandle includes the trap filter "default". This is equivalent to .1.3.6.1.4.1* as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.


Snmptrapd-conf edit detail 2.jpg


The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.

We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user following the #Users... line. These are pulled in automatically from the User List when the Generate button is clicked.

Receiving SNMPv1 Generic Traps

There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:

generic-trap parameter snmpTrapOID.0
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)

If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.

Two Level Trap Logging

Snmp trap receiver config file 5.jpg

When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.

The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging.

There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:

  • 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.
  • 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again.

You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.

Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).

Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.