Why is SNMP mostly used to monitor network devices, while NETCONF is the protocol usually chosen to configure them?
answer
- a 2002 workshop asked the operators
- few writable objects in standard MIBs
- no full configuration dump and replay
- configuration apart from operational state
- stage, validate, commit, all or nothing
basics
~20 sSNMP was designed for cheap polling of counters and status, and standard MIB modules rarely expose writable configuration; NETCONF was designed for configuration, with full-configuration retrieval, staged and validated edits, an all-or-nothing commit and a YANG schema.
solid answer
~40 sThe 2002 IAB network-management workshop (RFC 3535) found that SNMP works well for monitoring: polling is stateless and cheap, and core MIB modules such as `IF-MIB` are on most devices. It also found SNMP rarely used for configuration: standard MIB modules lack writable objects, a complete configuration usually cannot be retrieved and replayed, for many features configuration is not separated from operational state, and one logical change becomes a sequence of SNMP interactions the device must track and undo. NETCONF (RFC 6241, which obsoletes RFC 4741) answers those findings: `<get-config>` returns configuration alone, edits can be staged in a `candidate` datastore, checked with `<validate>` and applied by `<commit>`, and YANG models mark configuration and state apart. Both protocols can read and write; the split is a design centre, not a hard boundary.
go deeper
Recall the split: SNMP for polling counters and status, NETCONF for configuration. Be ready to name one reason SNMP is awkward for configuration, such as few writable objects in standard MIB modules.
Explain the workshop findings behind the split and map them to NETCONF features: get-config for configuration only, candidate plus commit for staged changes, validate, and YANG models that separate configuration from state.
Show that the split is about design centre, not capability: SNMP can set objects and NETCONF can read state. Explain why a sequence of SNMP sets leaves the device to track and undo partial changes.
Frame the choice historically and economically: vendors had little incentive to write full writable MIB modules, so programmatic configuration needed a protocol whose model could follow the device's own configuration closely.
## Two protocols, two design centres **SNMP** (the Simple Network Management Protocol; SNMPv3 is STD 62, RFC 3411-3418) dates from the late 1980s. A manager sends small request PDUs, normally over UDP, to an **agent** on the device, reading and writing individual **managed objects** named by object identifiers and described in **MIB modules** written in SMIv2. It was built as a programmatic interface for monitoring applications: poll a counter, compare it with the last poll, raise an alarm. **NETCONF** (RFC 6241, which obsoletes RFC 4741 from 2006) is a configuration protocol. A client opens a long-lived, connection-oriented session (normally SSH on TCP port 830, RFC 6242) and sends XML remote procedure calls against **configuration datastores**: `running`, and optionally `candidate` and `startup`. Its data is described by **YANG** models. The question is why the industry ended up with one for each job, and the honest answer comes from the operators themselves. ## What the 2002 IAB workshop found In June 2002 the Internet Architecture Board held a workshop where operators told protocol developers what was not working; RFC 3535 (Informational) records it. On SNMP it found strengths: - SNMP **works reasonably well for device monitoring**; its stateless nature suits statistical and status polling. - It is **widely deployed**: core modules such as `IF-MIB` (RFC 2863) are implemented on most networking devices. - It is an important data source for **event correlation, alarm detection and root-cause analysis**. And it found the reasons SNMP was **not widely used for configuration**: - **Too few writable objects.** Standardised MIB modules often lack writable objects; the interesting ones sit in proprietary modules, and routers are usually not fully configurable through SNMP. - **No easy retrieval and playback of a configuration.** Configuration objects are hard to identify, and the naming system ties them to physical layout, so a saved configuration may not replay after hardware changes. - **No separation of configuration from state.** For many features there is no way to tell what an administrator set from what the device learned. - **A weak transaction model.** One logical operation becomes a sequence of SNMP interactions; the agent must keep state until it completes and roll the device back if it fails. - **Poor fit for operators.** MIB modules are a data-centric "list of ingredients without a recipe", while operators think in tasks. The workshop recommended that the IETF focus resources on configuration management and on XML-based configuration technologies. NETCONF was the result. ## What NETCONF was built to provide | Workshop requirement | NETCONF answer | |---|---| | Fetch configuration separately from state | `<get-config>` returns configuration only; `<get>` adds state data | | Dump and restore whole configurations | `<get-config>` of a datastore, `<copy-config>` to replace one | | Distinguish distribution from activation | edit the `candidate`, then `<commit>` it to `running` | | Transactions and consistency checks | `<validate>`, all-or-nothing `<commit>`, confirmed commit that reverts on its own | | A schema operators and tools can share | YANG modules, which the server advertises to the client | | Protection from concurrent changes | `<lock>` on a datastore, which SNMP and CLI writes must also respect | The mechanics of each row (datastores, the edit operations, locking, model discovery) are their own subjects; what matters here is that each one closes a gap the workshop named. ## Where the line is not hard It is tempting to say "SNMP reads, NETCONF writes". Both halves are wrong as absolutes: 1. SNMP has had a `SetRequest-PDU` since SNMPv1 (RFC 1157), and some device classes are configured through writable MIB modules; RFC 6632 names cable modems as an example. 2. NETCONF's `<get>` returns operational state as well as configuration, and RFC 5277 adds event notifications. The difference is what each was **designed** to do well. SNMP is optimised for many small reads from many devices; NETCONF for complete, validated, transactional configuration of a device. ## How to answer it in an interview 1. Name the source: the 2002 IAB workshop, RFC 3535. 2. Give SNMP's strengths (cheap stateless polling, `IF-MIB` everywhere) and its configuration gaps (few writable standard objects, no dump and replay, no configuration and state split, weak transactions). 3. Map NETCONF's features onto those gaps. 4. Close with the nuance: both can read and write, and most networks run both.
- What did the workshop say SNMP still does well, and where is it slow?RFC 3535 says SNMP works reasonably well for monitoring: stateless polling suits statistics and status, `IF-MIB` is on most devices, and SNMP feeds event correlation and alarm detection. It performs reasonably when retrieving a small amount of data from many devices, but becomes slow when retrieving large amounts, such as routing tables, from a few devices.
- Did the workshop recommend replacing SNMP?No. It recommended that the IETF stop forcing working groups to provide writable MIB modules, investigate why MIB modules and SNMP miss some monitoring needs, and focus resources on configuration management, with strong operator consensus for XML-based configuration technologies. NETCONF followed as RFC 4741 in 2006, now obsoleted by RFC 6241; SNMP stayed as the monitoring workhorse.
saying these in an interview costs you the question
- SNMP cannot change a device; it only has read operations.
- NETCONF can only touch configuration and cannot read operational state.
- SNMP lost configuration work mainly because its UDP transport is unreliable.
- NETCONF made SNMP obsolete for monitoring as well as configuration.