By the SNMP Monitoring team · Reviewed July 2026
Alerting on notifications only works if the notification arrives. Classic SNMP traps are fire-and-forget over UDP—great when the network is kind, silent when it isn't. Informs (InformRequest) add an acknowledgment and retransmission: the receiver sends a Response, and the sender tries again if the ack never shows.
If your NOC pages on traps alone across lossy WAN links, you've chosen hope as a transport. This page is trap vs inform without the marketing. Parent: traps vs polling. PDU catalog: PDU types.
What is a trap
A trap is an asynchronous notification from the agent (or a trap-generating tool) toward a manager's trap receiver—typically UDP 162. The sender transmits once. There is no acknowledgment in the classic trap model. If the packet drops, nobody on the agent side is obligated to notice.
Real-world loss scenarios I've cleaned up after:
- Receiver process down during a maintenance window
- Firewall "optimized" UDP and ate bursts after a power event
- Wrong trap destination still in old config
- Congested management path; trap storm + drops
- NAT/state timeouts on middleboxes that hate long-quiet UDP
Traps are still useful. They're just not a delivery guarantee. Treat them as best-effort signals that you correlate with polling.
Manager-side listening is a different job from polling 161—draw both on the diagram.
What is an inform
An InformRequest is a notification that expects a Response from the receiver. If the ack doesn't come back within a timeout, the sender retransmits (implementation knobs vary: retries, delay). Informs showed up with SNMPv2c (and exist in the v2c/v3 world—not a v1 thing).
Same destination port class as traps: notifications head for UDP 162. Different reliability contract.
Net-SNMP-style tooling exposes both ideas (snmptrap vs inform helpers—names vary by package). Conceptual shape:
Trap-style send (fire-and-forget tooling):
snmptrap -v2c -c <RO_string> <trap_host>:162 '' 1.3.6.1.6.3.1.1.5.1
Inform-style send (ack / retry tooling; package names vary):
snmpinform -v2c -c <RO_string> <trap_host>:162 '' 1.3.6.1.6.3.1.1.5.1
(no output on success is common for senders; failures show timeouts/retries in verbose mode)
Don't cargo-cult OIDs from the sample into production without checking what your agent actually emits. The point is the delivery model, not a specific enterprise trap.
Cost of informs: the sender keeps state (outstanding informs, timers, retries). Under a trap storm, that costs CPU and memory. Reliability isn't free.
Trap vs inform comparison
| Trap | Inform | |
|---|---|---|
| Acknowledgment | None | Response expected |
| Retransmit on loss | No (classic) | Yes (sender retries) |
| Reliability | Best-effort UDP | Higher (still not magic) |
| Overhead | Lower | Higher (state + retries) |
| Version | v1 traps + v2 traps | Introduced with SNMPv2c |
| Port (typical) | UDP 162 | UDP 162 |
| Sender state | Minimal | Must track outstanding informs |
"Higher reliability" still fails if the receiver is down longer than your retry budget, if credentials/views reject the inform, or if the path is hard-down. Informs improve odds; they don't create a TCP session with infinite patience.
When to use informs vs traps
Numbered guidance:
- Critical, rare events over paths that drop UDP — prefer informs if the device supports them.
- High-volume, loss-tolerant noise (chatty debug notifications) — traps or better: don't send them.
- Lossy WAN management — informs + still poll key state; never notify-only.
- Local LAN, hardened receiver, burst risk — traps may be fine; watch storm behavior.
- Compliance "we must not miss this" — informs help; also log on-box and poll a status object.
- Device only speaks traps — use traps, dual receivers if you can, and polling backup.
If someone sells "100% guaranteed SNMP traps," walk away. Protocol reality disagrees.
Configuration pointers
Agent side (net-snmp and friends): trap/inform destinations, community or v3 user for notifications, which events are enabled. See snmpd.conf.
Manager side: process listening on 162, parsing SNMPv2-Trap vs InformRequest, sending Response for informs, deduplicating retries so one event doesn't page five times.
Alerting pipeline after the PDU lands: monitoring alerts.
Sketch of what you're aiming at operationally:
- Destination host/IP correct on every agent
- Receiver actually bound on 162 (not "documented only")
- Firewall allows agent → receiver UDP 162
- For informs: receiver replies; sender retry timers sane
- Load test a burst before the first datacenter failover
Polling still covers "agent dead, sent nothing." Notifications never replace that. Parent comparison: traps vs polling.
Anti-patterns
- Informs for everything, including flappy interface counters every second — you'll DoS yourself with state.
- Traps only, five-minute polls, no correlation — silent gaps.
- Same community as RO polling with write-capable strings on the wire for notifications — fix auth design.
- Ignoring version: expecting informs from pure v1 gear.
Mini scenario
Distribution switch loses uplink:
- Trap: may arrive in under a second or vanish; you might learn from the next poll of ifOperStatus.
- Inform: higher chance the NMS saw it; retries if the first UDP frame died.
- Poll only: you wait up to the interval; fine for trends, sluggish for "page now."
Best estate: inform or trap for the event and poll interface state so a lost notification isn't the end of the story.
Receiver behavior that people forget
When an inform arrives, the manager must:
- Parse the InformRequest
- Apply auth (community or v3)
- Send the Response ack promptly
- Hand the event to the alert pipeline
- Survive retries without creating five tickets for one flap
If step 3 is slow or missing, the agent keeps retransmitting and you invent a self-inflicted storm. Load-test informs the same way you load-test trap bursts—before the outage, not during it.
Also remember: both traps and informs still need the agent healthy enough to generate them. Power-off is a polling problem. Notification config can't page a brick. Build for that truth on purpose in every runbook you ship to on-call.
Ports refresher: 161 & 162. Glossary: glossary. Versions context for v2c+: versions.
Frequently asked questions
Difference between a trap and an inform?
A trap is sent once with no ack. An inform (InformRequest) expects a Response and retransmits if the ack is missing.
Are SNMP informs acknowledged?
Yes. The receiver acknowledges with a Response; that's the point of InformRequest.
Which is more reliable?
Informs are more reliable than classic traps because of ack + retry. Neither is perfect on a dead path or dead receiver.
Which version added informs?
SNMPv2c introduced informs. They're not part of the original SNMPv1 trap-only story.
Key takeaways
- Traps = best-effort, no ack, can be lost on UDP 162.
- Informs = InformRequest + Response + retransmits; came with v2c.
- Higher reliability, higher overhead—use for critical notifications.
- Still combine with polling; dead agents send neither.
- Config: snmpd.conf, alerts: monitoring/alerts, parent: traps vs polling.