TUT:snmptrap SNMPv3

From Net-SNMP Wiki
Revision as of 13:22, 24 February 2009 by Dts12 (Talk | contribs) (Fix minor typo, reported by Kyle Stemen)

Jump to: navigation, search

TRAPs vs INFORMs for SNMPv3

Prerequisite reading:

Additionally, the following page is similar in many ways to this page but laid out from the perspective of the snmptrapd application. It's possibly better written too:

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 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 you 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). Actually you would set it as "-e 0x{actual engineID}" where the -e and 0x are required followed by the actual remote device's engineID without the {squiggly brackets} so it would look something like "-e 0x800000090300001B371D4601" for a Cisco device.

  • (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 3410 - 3415) to try and explain it all, so I don't think I'll reiterate that here.

Tutorial Sections

About the SNMP Protocol

These tutorial links talk about SNMP generically and how the protocol itself works. They are good introductory reading material and the concepts are important to understand before diving into the later tutorials about Net-SNMP itself.

Net-SNMP Command Line Applications

These tutorial pages discuss the command line tools provided in the Net-SNMP suite of tools. Nearly all the example commands in these tutorials works if you try it yourself, as they're all examples that talk to our online Net-SNMP test agent. Given them a shot!

Application Configuration

All of our applications support configuration to allow you to customize how they behave.

Net-SNMP Daemons

Net-SNMP comes with two long-running daemons: a SNMP agent (snmpd) for responding to management requests and a notification receiver (snmptrapd) for receiving SNMP notifications.

Coding Tutorials

Net-SNMP comes with a highly flexible and extensible API. The API allows you to create your own commands, add extensions to the agent to support your own MIBs and perform specialized processing of notifications.

Debugging SNMP Applications and Agents

All our tools and applications have extensive debugging output. These tutorials talk about how the debugging system works and how you can add your own debugging statements to you code:

Operating System Specific Tutorials

Retrieved from "https://net-snmp.sourceforge.io/wiki/index.php?title=TUT:snmptrap_SNMPv3&oldid=3725"