In SNMP, what is the difference between a Trap and an InformRequest, and what does the sending agent learn from each?
answer
- one is answered, one is not
- Unconfirmed versus Confirmed Class
- Response-PDU echoes the request-id
- timeout, retry count, then give up
basics
~20 sAn SNMP Trap is fire-and-forget: the agent sends it once and learns nothing. An InformRequest is confirmed: the receiver answers with a Response-PDU, and the agent retransmits on timeout until a retry count runs out.
solid answer
~40 sBoth carry the same notification: in v2c and v3 the first two varbinds are `sysUpTime.0` and `snmpTrapOID.0`, then the objects the notification defines. The difference is delivery. An `SNMPv2-Trap-PDU` is Unconfirmed Class: RFC 3416 says there is no confirmation, so the agent never knows whether a collector heard it. An `InformRequest-PDU` is Confirmed Class: the receiver replies with a `Response-PDU` carrying the same request-id and varbinds, and the originator keeps state, retransmits on timeout and gives up after the retry count. That buys detection and a few more chances, not a guarantee — RFC 3416 itself says there is no guarantee of delivery. The price is memory on the agent for every pending inform and extra packets. SNMPv1 has only the Trap-PDU; informs need v2c or v3.
go deeper
Recall the one-line contrast: a trap is sent once and never answered, an inform is answered with a Response and resent if no answer comes.
Explain the originator's procedure: cache the target, wait for a Response with the same request-id, retransmit on timeout, give up after the retry count. Name both PDUs exactly.
Show you know an inform only tells the agent whether delivery failed; say what it costs in agent memory, duplicates and retransmissions, and when a trap is the better choice.
Frame the choice as where you pay for knowing about loss: in device state with informs, or in receivers and reconciliation polling with traps, and justify which events deserve which.
## Two ways to say "something happened" SNMP is mostly a polling protocol: a **manager** asks an **agent** on a device for values. **Notifications** run the other way: the agent speaks first, because an event — a link going down, a reboot, an authentication failure — is worth reporting before the next poll. The SNMPv2 protocol operations (RFC 3416, part of the SNMPv3 Internet Standard, STD 62) define two PDUs for this, and they carry the same content: - **`SNMPv2-Trap-PDU`** (context tag `[7]`) — an **unconfirmed** notification. - **`InformRequest-PDU`** (tag `[6]`) — a **confirmed** notification. In both, the varbind list starts with `sysUpTime.0` (when the event happened, in the agent's uptime) and `snmpTrapOID.0` (which notification this is), followed by the objects the notification's definition lists — for an interface `linkDown`, `ifIndex`, `ifAdminStatus` and `ifOperStatus`. ## What the RFC says about each | | Trap (`SNMPv2-Trap-PDU`) | Inform (`InformRequest-PDU`) | |---|---|---| | PDU class (RFC 3411) | Notification + **Unconfirmed** | Notification + **Confirmed** | | Receiver's reply | none | `Response-PDU`, same request-id and varbinds | | Agent keeps state | no | yes, until acknowledged or retries exhausted | | Retransmission | none | on timeout, up to a retry count | | RFC 3416 wording | "no confirmation associated with this notification delivery mechanism" | "a confirmed notification delivery mechanism, although there is, of course, no guarantee of delivery" | | Versions | v2c and v3 (v1 has its own `Trap-PDU`) | v2c and v3 only | The notification originator procedure in RFC 3413 makes the difference concrete. For an unconfirmed PDU the agent calls its dispatcher with "no response expected" and is done. For a confirmed PDU it: 1. sends the `InformRequest-PDU` and **caches** information about the target; 2. waits for a `Response-PDU` from that target's transport endpoint; 3. on a response, considers the notification **acknowledged** and deletes the cached state; 4. on silence (or certain Report indications), resends, up to the **retry count**; 5. when the retries are exhausted, records the acknowledgement as **failed** and stops for that target. The timeout and retry count come from the target's row in the SNMP-TARGET-MIB (`snmpTargetAddrTimeout`, `snmpTargetAddrRetryCount`), and the choice between the two PDUs is the SNMP-NOTIFICATION-MIB's `snmpNotifyType` object: `trap(1)` or `inform(2)`, with `trap` as its default value. ## What the agent learns - **From a trap: nothing.** The agent cannot tell a delivered trap from one dropped by a full queue, a restarting collector or a congested link. UDP gives no acknowledgement, and neither does the PDU. - **From an inform: one of two outcomes.** Either a response arrived (the receiving SNMP entity accepted it and passed it to its notification receiver application), or the agent gave up after its retries. The agent knows *which* — something a trap can never tell it — and that is the main thing an inform buys. An inform does not make delivery certain. If the receiver is down for longer than the timeout multiplied by the attempts, the inform fails exactly as a trap would; the difference is that the failure is now known to the agent, which can record or report it. ## What informs cost - **Agent memory**: each pending inform holds state per target until it is answered or abandoned. During an event storm towards a dead collector, that state piles up. - **Traffic**: every inform costs at least two messages, and each retransmission adds one. - **Duplicates**: if a `Response-PDU` is lost, the agent resends a notification the receiver already handled, so receivers must tolerate seeing it twice. - **SNMPv3 set-up**: in USM the receiver of a Confirmed Class PDU is the authoritative engine (RFC 3414 §1.5.1), so for informs the agent must learn the collector's engine ID first — a matter for the SNMPv3 security model. ## Versions SNMPv1 (RFC 1157) defines one notification PDU, the `Trap-PDU`, with its own layout (enterprise, agent-addr, generic-trap, specific-trap, time-stamp). The inform arrived with the SNMPv2 operations: it can be sent in community-based **SNMPv2c** messages (RFC 1901, an Experimental RFC, though nearly every device speaks it) and in **SNMPv3** messages. An agent cannot send an inform to a v1-only receiver — a v1 message has no confirmed notification PDU — and RFC 3413 lets it send a v1 `Trap-PDU` to that target instead, losing the acknowledgement. ## The interview point The weak answer is "informs are reliable, traps are not". The precise answer is: a trap tells the agent nothing, an inform tells the agent whether it got through and gives it a few more chances; neither tells you the event reached a human, and neither replaces checking the device's state another way.
- Why does RFC 3416 say an inform has no guarantee of delivery if it is acknowledged?Because the acknowledgement only bounds the agent's uncertainty. The originator retries a fixed number of times; if the receiver is unreachable for longer than those attempts span, the inform is abandoned and the event is gone. What changes is that the agent knows it failed. Delivery of a notification over UDP to a host that may be down cannot be guaranteed by any finite retry policy.
- Can a device send an inform to a collector that only speaks SNMPv1?No. SNMPv1 defines five PDUs, and its only notification is the unconfirmed Trap-PDU; there is no confirmed notification in a v1 message. RFC 3413's proxy rules say the same thing from the other side: when forwarding a confirmed notification, a proxy does not use targets whose SNMP version has no confirmed notification PDU. The device must send a trap to that collector, or the collector must be upgraded to v2c or v3.
- If informs are better, why is trap the default notification type in the SNMP-NOTIFICATION-MIB?Because informs cost state and traffic on the device, and many notifications are not worth that. snmpNotifyType defaults to trap(1). Each inform holds state on the agent until it is answered or abandoned, needs at least two messages and is retransmitted towards a dead receiver. For high-volume or low-value events that cost buys little; many operators reserve informs for the few events whose loss they would otherwise not detect.
A trap is a postcard: dropped in the box, and the sender never learns whether it arrived. An inform is a letter sent for a signed receipt: the sender keeps a copy and re-sends a set number of times if no receipt comes back, then gives up. Better odds and a known outcome — still no guarantee.
saying these in an interview costs you the question
- Informs guarantee delivery because the receiver acknowledges them.
- A trap is retransmitted if the collector does not answer.
- Traps and informs carry different varbind content.
- SNMPv1 agents can send informs to a v1 collector.
- A trap sent to a down collector is queued and delivered once it returns.
- Informs cost nothing extra on the device compared with traps.