What does a Response to an SNMP InformRequest actually prove, and what can still be lost or duplicated after the agent receives it?

## What the receiver does, step by step RFC 3416 §4.2.7 defines what a receiving SNMP entity does with an `InformRequest-PDU`: 1. It works out the size of a message carrying a `Response-PDU` with the same request-id, error-status, error-index and varbinds. 2. **If that would exceed** a local constraint or the originator's maximum message size, it sends an **alternate Response** — same request-id, error-status **`tooBig`**, error-index 0, empty varbinds — and stops. If even that does not fit, it increments `snmpSilentDrops` and discards it. 3. **Otherwise** it presents the contents to the appropriate application, builds a `Response-PDU` with the same request-id and varbinds, error-status **`noError`** and error-index 0, and sends it back. So a normal acknowledgement means exactly this: *the SNMP entity at the far end accepted the message and handed the notification to its notification receiver application.* Nothing in the protocol says what that application did next. ## What the acknowledgement does not cover | Situation | What the agent believes | What actually happened | |---|---|---| | Receiver replies, then crashes before storing | delivered | event lost | | Receiver stores, but alerting rules drop it | delivered | nobody is told | | Response lost on the way back | not yet delivered | receiver already has it; a duplicate follows | | Alternate Response with `tooBig` | depends on the implementation | receiver did not hand it on | | Proxy acknowledges | delivered | at least one downstream manager acknowledged | The first two rows are the end-to-end problem: an acknowledgement at one hop does not prove an outcome further along. The protocol orders the steps — present to the application, then respond — which lets a receiver implementation make the acknowledgement mean more: if the receiver application writes the event to durable storage before the Response is generated, a crash after the reply no longer loses it. That is a receiver design choice, not a protocol rule. ## Duplicates RFC 3413's originator retransmits when no response arrives in time, by repeating the send of the PDU it built once, so a lost Response produces a **second copy** of a notification the receiver has already processed. The protocol does not require the receiver to suppress it. A collector should therefore deduplicate, for example on the sender plus `request-id`, `sysUpTime.0` and `snmpTrapOID.0`, and alerting should be idempotent — a second `linkDown` for the same interface and uptime is the same event, not a new outage. ## The tooBig edge RFC 3413's originator procedure says that if a response is received in time, "the notification is considered acknowledged"; it does not single out error-status. An alternate Response with `tooBig` is a response — but the receiver did **not** present that notification to its application. An originator that treats every Response as success miscounts this case. It arises when the inform is close to a size limit: many varbinds, or a receiver with a small local constraint. RFC 3417 only requires UDP entities to accept 484-octet messages and recommends 1,472. ## Proxies RFC 3413 §3.5.2 defines notification forwarding for a **proxy forwarder**: - It forwards a received inform as informs to its configured targets. - It answers the original inform **only when at least one** forwarded inform has been acknowledged; if none is acknowledged within the longest timeout, it halts and sends nothing. - Targets whose SNMP version has no confirmed notification PDU — SNMPv1 — are not used for forwarding a confirmed notification. So through a proxy, an acknowledgement means "at least one downstream manager acknowledged", not "all of them". ## SNMPv3: failure becomes visible RFC 3412 requires the reportable flag to be **one** for Confirmed Class PDUs such as an inform and **zero** for unconfirmed ones such as a trap. When an SNMPv3 receiver cannot process an inform — for instance it does not know the user or the authentication fails — it can return a Report, and RFC 3413 lets the originator treat such a Report as a failed acknowledgement without further retries. A trap with the same misconfiguration is simply discarded at the receiver, and the agent never hears about it. The detail of which Reports mean what belongs to the SNMPv3 security model. ## The interview point The strong answer separates three levels — the packet arrived, the SNMP entity accepted it, the event was stored and acted on — says the Response proves only the second, and names what closes the gap: deduplication, store-before-acknowledge receivers and a reconciliation check against device state.