Difference between revisions of "TUT:Configuring snmptrapd"

From Net-SNMP Wiki
Jump to: navigation, search
(config v1/v2c)
 
(add tut TOC trailer)
Line 118: Line 118:
  
 
   trap: demoNotif localhost 127.0.0.1 SNMPv2-MIB::sysUpTime.0 = 1:19:02:06.33, SNMPv2-MIB::snmpTrapOID.0 = UCD-NOTIFICATION-TEST-MIB::demoNotif, SNMPv2-MIB::sysLocation.0 = "just here"
 
   trap: demoNotif localhost 127.0.0.1 SNMPv2-MIB::sysUpTime.0 = 1:19:02:06.33, SNMPv2-MIB::snmpTrapOID.0 = UCD-NOTIFICATION-TEST-MIB::demoNotif, SNMPv2-MIB::sysLocation.0 = "just here"
 +
 +
<hr>
 +
 +
{{TUT:LIST}}

Revision as of 21:33, 27 December 2007

snmptrapd is a Net-SNMP application that lets operators receive SNMP notifications (informs and traps) and process them.

Configuring snmptrapd to allow traps in the door

By default, snmptrapd does not do anything with received notifications. You have to tell it what you want to receive notifications.

Configuring snmptrapd to accept SNMPv1 or SNMPv2c notifications

To receive SNMPv1 or SNMPv2c notifications you need to tell snmptrapd your community strings. The easiest way to do this is by using the authCommunity snmptrapd.conf configuration file token. For example, this line: 

 authCommunity log,exececute,net public

Will let snmptrapd process notifications received using the "public" community string. Those notifications may be logged, allowed to trigger executable actions (see below), and resend data to the network (forward).

Configuring snmptrap to accept SNMPv3 notifications

SNMPv3 adds security to the SNMP protocol and is a safer way to receive notification data. But, it's a bit more complex to set up. Configuration of SNMPv3 notifications is described fully on a separate page:

Processing Notifications

Generating traps is only half of the battle. We also need something to receive the notification, and respond accordingly. The Net-SNMP suite includes an application snmptrapd which can accept and process such notifications.

By default, it will simply log all incoming notifications via syslog. The two snmptrap commands above would be logged as: 

 1999-11-12 23:26:07 localhost [127.0.0.1] UCD-TRAP-TEST-MIB::demotraps:
       Enterprise Specific Trap (demoTrap) Uptime: 1 day, 5:34:06
       SNMPv2-MIB::sysLocation.0 = "Just here"

and 

 1999-11-13 08:31:33 localhost [127.0.0.1]:
       SNMPv2-MIB::sysUpTime.0 = Timeticks: (13917129) 1 day, 14:39:31.29
       SNMPv2-MIB::snmpTrapOID.0 = OID: UCD-NOTIFICATION-TEST-MIB::demoNotif
       SNMPv2-MIB::sysLocation.0 = "just here"

respectively.

Trap Handlers

The snmptrapd utility also has the ability to execute other programs on the reception of a trap. This is controlled by the traphandle directive, with the syntax 

 traphandle OID command

Notice, that this only takes an OID to determine which trap (or notification) is received. This means that SNMPv1 traps, which have a trap type and specific type, need to be represented in SNMPv2 format, which is described in RFC 2089.

Matching SNMPv1 OIDs

SNMPv1 traps fall into two broad categories: generic and enterprise specific. Generic traps use trap types 0 through 5, and do not use the specific type. To match a generic trap, the traphandle OID should be the SNMPv2-MIB::snmpTraps OID, with an additional final OID of the trap type + 1. For example, to match linkDown traps (specific type 2), the correct OID would be "1.3.6.1.6.3.1.1.5.3" (or SNMPv2-MIB::snmpTraps.3, which is also IF-MIB::linkDown).

When the specific type is 6, the trap is an enterprise specific trap. When matching these traps, the traphandle OID is constructed using the enterprise OID and specific type specified in the trap. Earlier in the tutorial, we sent a SNMPv1 enterprise specific trap with an enterprise OID of UCD-TRAP-TEST-MIB::demotraps, a trap type of 6 and a specific type of 17. To match this trap type, the traphandle OID should be the enterprise OID, plus 0, plus the specific type. So the correct OID would be ".1.3.6.1.4.1.2021.13.990.0.17" (or UCD-TRAP-TEST-MIB::demoTrap).

Matching SNMPv2 OIDs

SNMPv2 traps and informs are much easier, because they include the correct OID in the SNMPv2-MIB::snmpTrapOID.0 variable in the trap.


Example handler script

The command specifies a command to be executed by snmptrapd upon reception by the command. This command is executed with the data of the trap as its standard input. The first line is the host name, the second the IP address of the trap sender, and the following lines consists of an OID VALUE pair with the data from the received trap.

A simple shell script to be called from snmptrapd is the following: 

 #!/bin/sh
 
 read host
 read ip
 vars=
 
 while read oid val
 do
   if [ "$vars" = "" ]
   then
     vars="$oid = $val"
   else
     vars="$vars, $oid = $val"
   fi
 done
 
 echo trap: $1 $host $ip $vars

Now, given the following sample snmptrapd.conf file, 

 # the generic traps
 traphandle SNMPv2-MIB::coldStart    /home/nba/bin/traps cold
 traphandle SNMPv2-MIB::warmStart    /home/nba/bin/traps warm
 traphandle IF-MIB::linkDown         /home/nba/bin/traps down
 traphandle IF-MIB::linkUp           /home/nba/bin/traps up
 traphandle SNMPv2-MIB::authenticationFailure /home/nba/bin/traps auth
 # this one is deprecated
 traphandle .1.3.6.1.6.3.1.1.5.6     /home/nba/bin/traps egp-neighbor-loss
 
 # enterprise specific traps
 traphandle UCD-TRAP-TEST-MIB::demoTrap /home/nba/bin/traps demo-trap
 traphandle UCD-NOTIFICATION-TEST-MIB::demoNotif /home/nba/bin/traps demo-notif

The following snmptrap invocation, to issue a generic Link down trap, 

 % snmptrap -v 1 -c public localhost TRAP-TEST-MIB::demotraps localhost 2 0 "" \
       IF-MIB::ifIndex i 1

results in the following output from snmptrapd: 

 1999-11-13 12:46:49 localhost [127.0.0.1]  TRAP-TEST-MIB::traps:
       Link Down Trap (0) Uptime: 1 day, 18:54:46.27
       IF-MIB::ifIndex.0 = 1

and the following output from the handler: 

 trap: down localhost 127.0.0.1 SNMPv2-MIB::sysUpTime = 1:18:54:46.27, SNMPv2-MIB::snmpTrapOID = IF-MIB::linkDown, IF-MIB::ifIndex.0 = 1, SNMPv2-MIB::snmpTrapEnterprise = TRAP-TEST-MIB::traps

and issuing our enterprise specific trap gives this output from our handler: 

 trap: demoTrap localhost 127.0.0.1 SNMPv2-MIB::sysUpTime = 1:19:00:48.01, SNMPv2-MIB::snmpTrapOID = UCD-TRAP-TEST-MIB::demoTrap, SNMPv2-MIB::sysLocation.0 = "just here", SNMPv2-MIB::snmpTrapEnterprise = UCD-TRAP-TEST-MIB::traps

and finally our enterprise specific notification: 

 trap: demoNotif localhost 127.0.0.1 SNMPv2-MIB::sysUpTime.0 = 1:19:02:06.33, SNMPv2-MIB::snmpTrapOID.0 = UCD-NOTIFICATION-TEST-MIB::demoNotif, SNMPv2-MIB::sysLocation.0 = "just 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:Configuring_snmptrapd&oldid=3230"