Difference between revisions of "TUT:snmptrap SNMPv3"
m (Fix minor typo, reported by Kyle Stemen) |
|||
| Line 1: | Line 1: | ||
| − | == TRAPs vs INFORMs for SNMPv3 == | + | == TRAPs vs INFORMs for SNMPv3 with USM == |
=== Prerequisite reading: === | === Prerequisite reading: === | ||
Latest revision as of 00:20, 22 June 2010
TRAPs vs INFORMs for SNMPv3 with USM
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.
- How SNMP Works: About the protocol itself (GETs, GETNEXTs, etc)
- What data is in SNMP: All about SNMP Management Information Bases (MIBs)
- Securing SNMP: How to use the SNMP protocol securely
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!
- snmptranslate: learning about the MIB tree.
- snmpget: retrieving data from a host.
- snmpgetnext: retrieving unknown indexed data.
- snmpwalk: retrieving lots of data at once!
- snmptable: displaying a table.
- snmpset: peforming write operations.
- snmpbulkget: communicates with a network entity using SNMP GETBULK request
- snmpbulkwalk: retrieve a sub-tree of management values using SNMP GETBULK requests.
- snmptrap: Sending and receiving traps, and acting upon them.
- Traps/informs with SNMPv3/USM: Sending and receiving SNMPv3/USM TRAPs and INFORMs
- Sending Traps/Informs via AgentX: Sending notifications from the command line through snmpd
- Common command line options:
- Writing mib2c config files
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.
- SNMP Agent (snmpd) Configuration
- SNMP Notification Receiver (snmptrapd)
- Agent Monitoring
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.
- Client / Manager Coding Tutorials
- Agent Coding Tutorials
- The Agent Architecture page might be worth reading before or after the agent coding tutorials, and describes how the Agent Helpers work under the hood.
- Writing a mib module to serve information described by an SNMP MIB, and how to compile it into the net-snmp snmpd agent.
- Writing a Dynamically Loadable Object that can be loaded into the SNMP agent.
- Writing a Subagent that can be run to attach to the snmpd master agent.
- Writing a perl plugin to extend the agent using the NetSNMP::agent module.
- Writing shell scripts to extend the agent
- Using mib2c to help write an agent code template for you
- Header files and autoconf
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:
- Debugging output printed using the -D command line option
- Using -Ddump to display packet breakdowns
- Debugging using GDB
Operating System Specific Tutorials
- Building With Visual Studio 2005 Express
- Building Net-SNMP 64-bit with Visual C++ 2010 Express
- Net-Snmp on Ubuntu
- Net-SNMP and lm-sensors on Ubuntu 10.04
- Net-SNMP for windows:
