View source for TUT:snmptrap SNMPv3

== TRAPs vs INFORMs for SNMPv3 ==

=== Prerequisite reading: ===
* snmpv3 options 
* [[TUT:snmptrap | trap summary]]

=== TRAPs vs INFORMs ===


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). Their 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. 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 an "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 a 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. 
==== SNMPv3, users and engineIDs ====

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 an identifier for the given SNMP application you're 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 the user database based on this remote engineID. Makes things all nice and simple when talking to a remote agent. 
==== SNMPv3 INFORMs ====

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: 

* Stop any currently running snmptrapd 
* edit /var/net-snmp/snmptrapd.conf to insert the following line: 

  createUser myuser MD5 mypassword DES myotherpassword


Where 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). 

* (re)start the snmptrapd program. 


Now, you should be able to use the snmpinform command to send the trap daemon a coldStart INFORM message: 

 '''snmpinform -v 3 -u myuser -a MD5 -A mypassword -l authNoPriv localhost 42 coldStart.0'''

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

=== SNMPv3 TRAPs ===


SNMPv3 TRAPs are a bit more complicated in some ways, but it makes sense the protocol works this way if you spend a long time thinking about it. The difference is that SNMPv3 TRAPs use the engineID of the local application sending the trap rather than the engineID of the remote application. This means that you have to create users in your remote user database with a bit more care and need to create one for every engineID you wish to send traps from. This means that if you want to have 100 snmp agents send snmpv3 traps to your trap receiver, you need 100 createUser directives in your /var/net-snmp/snmptrapd.conf file. 

So, try the following: 

* Stop any currently running snmptrapd 
* edit /var/net-snmp/snmptrapd.conf to insert the following line: 

  createUser -e 0x0102030405 myuser MD5 mypassword DES myotherpassword

Note 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). 

* (re)start the snmptrapd program. 

Now, you should be able to use the snmptrap command to send the trap daemon a coldStart v3 TRAP message: 

  '''snmptrap -e 0x0102030405 -v 3 -u myuser -a MD5 -A mypassword -l authNoPriv localhost 42 coldStart.0'''

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. 

{{TUT:LIST}}