TUT:snmptrap SNMPv3 - Revision history

Wes at 00:20, 22 June 2010

2010-06-22T00:20:17Z

Dts12: Fix minor typo, reported by Kyle Stemen

2009-02-24T13:22:58Z

Fix minor typo, reported by Kyle Stemen

Wbenton@aa.aeonnet.ne.jp: /* SNMPv3 TRAPs */

2008-06-03T04:53:08Z

‎SNMPv3 TRAPs

Wbenton@aa.aeonnet.ne.jp: /* SNMPv3 TRAPs */

2008-06-03T04:50:43Z

‎SNMPv3 TRAPs

Wbenton@aa.aeonnet.ne.jp: /* SNMPv3 TRAPs */

2008-06-03T04:46:55Z

‎SNMPv3 TRAPs

← Older revision		Revision as of 00:20, 22 June 2010
Line 1:		Line 1:
−	== TRAPs vs INFORMs for SNMPv3 ==	+	== TRAPs vs INFORMs for SNMPv3 with USM ==

	=== Prerequisite reading: ===		=== Prerequisite reading: ===

@@ Line 13: / Line 13: @@
-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.
+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.

@@ Line 65: / Line 65: @@
 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.
+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.
 {{TUT:LIST}}

@@ Line 55: / Line 55: @@
    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}.
+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.

@@ Line 55: / Line 55: @@
    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).
+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}.
 * (re)start the snmptrapd program.