Additional SNMP Trap Receiver Tips and Techniques
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:
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 “.220.127.116.11.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 18.104.22.168.22.214.171.124.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.
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.
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:
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 126.96.36.199.188.8.131.52.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.
Dual Trap Logging
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged. With additional steps, the second level will be 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 filename window, select Yes, and click Select Logging Options. 2) Without disabling logging, enter a different filename in the filename 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 named, whatever it is, 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).