A quick recap on the difference between TRAPs and INFORMs: A TRAP is a SNMP message sent from one application to another (which is typically on a remote host). They're purpose is merely to notify the other application that something has happened, has been noticed, etc. The big problem with TRAPs is that they're unacknowledged so you don't actually know if the remote application received your oh-so-important message to it. SNMPv2 PDUs fixed this by introducing the notion of an INFORM, which is nothing more than an acknowledged TRAP. IE, when the remote application receives the INFORM it sends back a "I got it" message. This is nice because then the person sending the traps can keep trying until the trap gets through. The net-snmp snmptrap program can send both TRAPs and INFORMs. Add -Ci to the command line of snmptrap if you want it to send an INFORM instead, or call the snmpinform command (which is functionally the same as snmptrap -Ci). Note that you must use snmpv2c or snmpv3 to send INFORMs. snmptrapd is able to receive and display both INFORMs and TRAPs.
Note: snmptrapd will not display SNMPv3 TRAPs or INFORMs sent by a user which has not been configured using the createUser directives discussed below. They will be silently dropped by the snmptrapd program. If your run snmptrapd with the -Dusm flag you'll get debugging output which says "no such user", which is exactly why they're being dropped.
Note: Starting with net-snmp 5.3, snmptrapd will no longer accept all traps by default. It must be configured with authorized SNMPv1/v2c community strings and/or SNMPv3 users. Non-authorized traps/informs will be dropped. Please refer to the snmptrapd.conf(5) manual page for details.
TRAPs and INFORMs get a little more complex with respect to SNMPv3. The reason behind it is how the user database is maintained. SNMPv1 and SNMPv2c community based messages merely always display the message to the end user. SNMPv3 mandates that the message is rejected unless the SNMPv3 user sending the trap already exists in the user database. Sounds simple enough, right? Except for one small problem: The user database in a SNMPv3 application is actually referenced by a combination of the user's name (called a "security Name") and a identifier for the given SNMP application your talking to (called an "engineID"). Normally when you use the rest of the snmp applications (snmpget, snmpwalk, ...) the application "discovers" the remote engineID for you and then inserts the username, engineID and passwords into user database based on this remote engineID. Makes things all nice and simple when talking to a remote agent.
INFORMs operate on a similar principal. When you send an INFORM you use the remote engineID when sending the message and the securityName and engineID must exist as a pair in the remote user table. The snmptrap program discovers the remote engineID just like the rest of the applications would do and then appropriately creates the SNMPv3 message with the proper user that the remote side is expecting to get. And all is well. So, all you have to do when setting up the remote snmptrapd application (assuming you're using our trap/inform receiver) is to create a v3 user in the snmptrapd configuration database. You do this as follows:
createUser myuser MD5 mypassword DES myotherpasswordWhere myuser is the security name you want to use, and mypassword is your authentication password and myotherpassword is your encryption password (or leave it blank if you want it to be the same or don't want to use encryption).
Now, you should be able to use the snmpinform command to send the trap demon a coldStart INFORM message:
If you did everything correctly, you should have seen something like this in your snmptrapd output:
2001-10-31 11:21:05 localhost.localdomain [127.0.0.1]: sysUpTimeInstance = Timeticks: (42) 0:00:00.42 snmpTrapOID.0 = OID: coldStart.0
So, try the following:
createUser -e 0x0102030405 myuser MD5 mypassword DES myotherpasswordNote that this time we explicitly set the engineID of the user to 0x0102030405 (which technically is not a recommended value, but it really doesn't matter).
Now, you should be able to use the snmptrap command to send the trap demon a coldStart v3 TRAP message:
This should produce similar output as the example above did.
I should go rambling on here about the intricate details of v3
engineIDs, INFORMs, TRAPs, engineID discovery, secret keys, passwords,
localized keys, etc. But it took the SNMPv3 working group 18223 lines
of text (RFCs 2570 - 2575) to try and explain it all, so I don't think
I'll reiterate that here.
Last modified: Thursday, 26-May-2011 23:21:32 UTC
For questions regarding web content and site functionality, please write to the net-snmp-users mail list.