SNMP Traps and snmptrapd: Alerting That Scales

Polling tells you what a device looks like every five minutes; traps tell you the moment something changes. Link flapping, power supply failure, a BGP peer dropping - traps arrive unprompted, which is why switches are almost always configured to send them. The receiver side is where deployments quietly fail: since Net-SNMP 5.3, snmptrapd drops everything that is not explicitly authorised, so a correct sender and a silent receiver is the normal first symptom.

Trap versus inform

A trap is fire-and-forget: no acknowledgement, so a lost UDP packet means a lost alert. An inform is an acknowledged trap - the receiver replies, and the sender retransmits unacknowledged notifications. For anything that matters, use SNMPv3 informs. The authoritative SNMP engine differs between the two: for traps it is the sender, for informs it is the receiver, which is why the user and engine ID setup differs.

Receiving v1/v2c notifications

# /etc/snmp/snmptrapd.conf
authCommunity log,execute,net public
# restrict a community to specific senders
authCommunity log 10.10.0.0/16,10.20.0.0/16 monitoring
disableAuthorization no

Authorising a community means those notifications may be logged, may trigger executable actions, and may be forwarded. Grant only what you use - log alone is fine for most devices, and never leave disableAuthorization yes (or the older disableAuthorization behaviour) in place: it accepts traps from anyone who can reach UDP 162.

Receiving v3 traps and informs

# /var/lib/snmp/snmptrapd.conf - createUser must live here, not in the main config
createUser -e 0x8000000a3f01a2b3c4d5e6 v3user SHA "auth-passphrase" AES "priv-passphrase"
createUser informuser SHA "auth-passphrase" AES "priv-passphrase"

# /etc/snmp/snmptrapd.conf
authUser log,execute,net v3user
authUser log,execute,net informuser

For traps the engine ID on the createUser line must be the sender's engine ID, taken from the device (show snmp engineID on Cisco, or the oldEngineID entry in the device's snmpd.conf on Linux hosts). For informs the receiver is authoritative, so createUser without -e is correct and the device must be configured with the receiver's engine ID. Getting this pair backwards is the number one reason v3 traps never appear.

Turning traps into action

traphandle SNMPv2-MIB::coldStart        /usr/local/bin/trap-notify cold
traphandle IF-MIB::linkDown             /usr/local/bin/trap-notify linkdown
traphandle IF-MIB::linkUp               /usr/local/bin/trap-notify linkup
traphandle default                       /usr/local/bin/trap-notify other

The handler receives the sender's hostname on the first input line, its IP on the second, then the varbinds as OID value pairs. A short script that formats those lines and pipes them into the internal mail relay keeps the whole path self-hosted - see Postfix Internal SMTP Relay for Device Alerts for the relay itself.

Device-side configuration and verification

! Cisco IOS-XE
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps bgp
snmp-server host 10.10.0.50 version 3 priv v3user bgp
snmp-server host 10.10.0.50 informs version 2c monitoring

! verify receiver is reachable and traps are being sent
show snmp host
show snmp stats oid

• Confirm the receiver listens: ss -lunp | grep :162.
• Watch arrivals during a maintenance window: snmptrapd -f -Lo -n in the foreground prints decoded notifications as they arrive.
• Generate a test trap with snmptrap -v2c -c monitoring localhost '' 1.3.6.1.6.3.1.1.5.3 and confirm it appears in the log and triggers the handler.
• Keep MIB files installed, or traps log as numeric OIDs and become unreadable. For a broader correlation layer, feed the same events into the collectors described in Graylog as a Central Syslog Server for Network Devices.

原文链接：https://www.net-snmp.org/wiki/index.php/TUT:Configuring_snmptrapd