skip to content

How do NETCONF event notifications (RFC 5277) differ from SNMP traps and informs in delivery, content, and recovering events a manager missed?

level: seniorimportance: nice to knowfreq 9%

answer

  1. who asks for the events first
  2. UDP datagram versus open session
  3. Response-PDU only for informs
  4. eventTime versus sysUpTime.0
  5. replay from a startTime

basics

~20 s

SNMP traps are unacknowledged UDP datagrams sent to configured targets; informs add acknowledgement and retransmission. RFC 5277 notifications flow only after a client subscribes, ride its reliable NETCONF session, carry an eventTime, and can be replayed from a log.

solid answer

~40 s

An SNMP agent sends an `SNMPv2-Trap-PDU` to targets it was configured with, normally over UDP, and RFC 3416 says there is no confirmation; an `InformRequest-PDU` is answered with a `Response-PDU`, so the sender can retransmit. Both start with `sysUpTime.0` and `snmpTrapOID.0`, and RFC 3535 notes that traps usually need follow-up gets to interpret. In NETCONF the client sends `<create-subscription>`, optionally naming a stream and a filter; the server then sends `<notification>` messages over that session, each with an `<eventTime>` and with no reply. Delivery inherits the session's reliable, sequenced transport, but events during an outage are not queued for you: the client resubscribes with a `<startTime>`, and the server replays from its log if the stream supports replay.

go deeper

for a junior

Recall that a trap is unacknowledged, an inform is acknowledged, and a NETCONF client must subscribe before it receives notifications.

for a middle

Explain create-subscription with stream and filter, the eventTime in each notification, and why sysUpTime.0 and snmpTrapOID.0 lead every trap.

for a senior

Design for gaps: traps can vanish, informs fail after their retries, and a NETCONF subscription ends with its session, so a collector must track the last eventTime and replay or poll.

for a principal

Decide where event delivery guarantees belong in a monitoring architecture, weighing agent-side retransmission state, server-side replay logs and periodic reconciliation by polling.

## Why this comparison comes up A management system needs to hear about events, such as a link going down or a configuration change, without polling for them. SNMP and NETCONF both push events, but with different delivery models, and the differences decide what you can trust after an outage. This answer covers RFC 5277 event notifications; streamed telemetry subscriptions are a separate subject. ## SNMP traps and informs RFC 3416 defines two notification PDUs: - **`SNMPv2-Trap-PDU`.** Sent by a notification originator to destinations chosen by the agent's own configuration. "There is no confirmation associated with this notification delivery mechanism." Over the usual UDP transport, a lost datagram is simply gone. - **`InformRequest-PDU`.** The receiver answers with a `Response-PDU`. The sender learns that the event arrived, and can retransmit when no response comes, governed in SNMPv3 by the timeout and retry objects of the SNMP-TARGET-MIB (RFC 3413). Both carry variable bindings whose first two are `sysUpTime.0` (hundredths of a second since the agent's management subsystem started) and `snmpTrapOID.0` (which event this is), followed by the objects the `NOTIFICATION-TYPE` lists. RFC 3417 suggests that notification receivers listen on UDP port 162. RFC 3535 recorded the operators' view: traps track state changes, but "usually require subsequent get operations to figure out what the trap really means", and syslog is often considered more useful. ## NETCONF event notifications RFC 5277 adds an optional capability, `:notification:1.0`, with a different model: 1. **The client asks.** "A NETCONF server does not send notifications before being asked to do so." The client sends `<create-subscription>` with an optional `<stream>` (default: the `NETCONF` stream) and an optional `<filter>`, in the same format as NETCONF's retrieval filters. 2. **The server pushes on that session.** Each event is a `<notification>` element holding a mandatory `<eventTime>` (a date-time with time zone) and content defined by a YANG `notification` statement or another model. There is **no response**. 3. **The transport is reliable while it lasts.** RFC 6241 requires NETCONF sessions to provide reliable, sequenced delivery, normally SSH over TCP, so notifications are not silently dropped mid-session. 4. **The subscription lives and dies with the session.** It ends with `<close-session>`, `<kill-session>`, transport failure, or a `<stopTime>`. It cannot be modified once created, and unless the server advertises `:interleave` it rejects other operations on that session with `resource-denied`. ## Recovering missed events | Situation | SNMP | NETCONF (RFC 5277) | |---|---|---| | Datagram or message lost in flight | trap: lost; inform: retransmitted | not applicable while the session is up | | Manager down or unreachable | traps lost; informs fail after the last retry | session drops; no queueing | | Getting the gap back | poll the relevant tables | resubscribe with `<startTime>` for replay | | Knowing when replay is done | not applicable | `<replayComplete>` notification | Replay is optional per stream. A client reads `<replaySupport>` and `<replayLogCreationTime>` from the `<streams>` data to see whether and how far back the log goes, and how much the server keeps is implementation-specific. A `<startTime>` older than the log simply starts at the earliest stored notification. ## Designing a NETCONF collector for gaps 1. Keep the subscription on its own session unless the server advertises `:interleave`. 2. Store the `<eventTime>` of the last notification processed. 3. After a reconnect, check `<replaySupport>` and `<replayLogCreationTime>` for the stream. 4. Resubscribe with `<startTime>` set to that stored time, and expect to see the boundary event again, so deduplicate. 5. If the log does not reach back far enough, reconcile by reading current state instead. ## What this means in practice - A trap is a hint; design for loss and confirm by polling. - An inform adds delivery feedback, at the cost of state and retransmissions on the agent. - A NETCONF notification is reliable only for as long as the session is up; reliability across outages comes from replay, not from the transport. - Timestamps differ: `sysUpTime` is relative to an agent restart, while `<eventTime>` is an absolute time, which makes correlation across devices simpler as long as their clocks are synchronised.

  • Why might a NETCONF client open a second session just for notifications?
    RFC 5277 says that while a subscription is active the server must accept `<close-session>`, but may reject other operations with `resource-denied` unless it advertises the `:interleave` capability. Without interleave, a client that also needs to edit or read configuration keeps one session for the subscription and another for its RPCs.
  • A collector resubscribes with a startTime older than the server's log; what does it get?
    RFC 5277 says replay begins with the earliest available notification, not an error. The client should compare its startTime with `<replayLogCreationTime>` to know that some events were lost, then reconcile by reading current state. A `<replayComplete>` notification marks the end of the replayed events.

saying these in an interview costs you the question

  • NETCONF notifications are acknowledged by the client, like SNMP informs.
  • SNMP traps are retransmitted until the manager answers them.
  • Under RFC 5277 a NETCONF server sends notifications to configured managers unasked.
  • A NETCONF server resends missed notifications automatically when the client reconnects.
  • Replay means the server keeps every notification forever.