skip to content

In NETCONF, how do <get> and <get-config> differ, and which one should a nightly configuration-backup job call?

level: middleimportance: must knowfreq 18%

answer

  1. two kinds of data on a device
  2. only one takes a source datastore
  3. counters change between runs
  4. read-only values in an archive

basics

~20 s

<get-config> returns only configuration data from a named datastore such as running, candidate or startup; <get> returns the running configuration plus read-only state such as counters. A backup job should call <get-config>, so the archive holds only restorable data.

solid answer

~40 s

RFC 6241 splits what a device holds into **configuration data**, the writable set that turns a factory-default box into its current state, and **state data**, the read-only status and statistics. `<get-config>` takes a `<source>` parameter (`<running/>`, or `<candidate/>` and `<startup/>` when those capabilities are advertised) and returns configuration only. `<get>` takes no source: it always returns the running configuration together with state. A backup or drift-diff job should call `<get-config>` on `<running/>`: state would make every comparison noisy with changing counters, bloat the archive, and put read-only values into data you may later try to write back. Use `<get>` when you actually want operational data. Both answer inside a `<data>` element and accept an optional filter.

code

xml · 8 lines
xml
<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
  </get-config>
</rpc>

go deeper

for a junior

Recall the split: configuration is what you set, state is what the device reports. <get-config> reads configuration from a named datastore; <get> reads running configuration plus state.

for a middle

Explain the parameters: <get-config> needs a source and can read candidate or startup when advertised, while <get> has no source. Give RFC 6241's reasons state does not belong in configuration work.

for a senior

Show the production habits: back up with <get-config> on running, verify changes with <get>, and check that the backup account can read everything, since access control silently omits unreadable nodes.

for a principal

Discuss what a backup is for: restore, audit or drift detection. Weigh running against startup comparisons and when NMDA's operational datastore should replace <get> in monitoring.

## Two kinds of data on a managed device NETCONF (RFC 6241, which obsoletes RFC 4741) is a protocol for reading and changing the configuration of network devices with XML-encoded **remote procedure calls** (RPCs). Before its retrieval operations make sense, you need the distinction its Section 1.4 draws: - **Configuration data** is "the set of writable data that is required to transform a system from its initial default state into its current state": interface MTUs, descriptions, addresses, routing-protocol settings. - **State data** is everything else the device can report: read-only status and collected statistics such as octet counters, operational link status or a neighbour table. A data model written in YANG marks each node as configuration (`config true`) or state (`config false`), so the device always knows which class a value belongs to. ## The two retrieval operations NETCONF's base protocol offers two read operations, and they are not two spellings of the same thing: | | `<get-config>` | `<get>` | |---|---|---| | Parameters | `<source>` (mandatory), `<filter>` (optional) | `<filter>` (optional) only | | Datastores it can read | `<running/>`; `<candidate/>` and `<startup/>` when the `:candidate` or `:startup` capability is advertised | always the running configuration | | What comes back | configuration data only | running configuration **plus** state data | | Reply wrapper | `<data>` inside `<rpc-reply>` | `<data>` inside `<rpc-reply>` | Without a filter, `<get-config>` returns the entire chosen datastore and `<get>` returns all configuration and state the device holds. Narrowing either with a subtree or XPath filter is a separate topic; what matters here is which class of data each operation can return at all. ## Why a backup job wants `<get-config>` RFC 6241 lists the problems that mixing state into configuration work would cause, and each is a reason a backup or drift-detection job should call `<get-config>` with `<running/>` as the source: 1. **Diffs are dominated by noise.** Counters and timers change between any two runs, so a nightly diff of `<get>` output reports a "change" every night and hides the one edit that mattered. 2. **Restores carry read-only values.** If the archive holds state, pushing it back with `<edit-config>` or `<copy-config>` contains nodes the device will refuse to write, and the restore fails or needs scrubbing first. 3. **Archives grow.** On a large device, state can be far bigger than configuration. A second, quieter trap applies to both operations. Under the NETCONF access-control model (RFC 8341, Section 3.2.4), data nodes the session's user may not read are **silently omitted** from the reply rather than reported as an error. A backup run under a narrowly scoped account can therefore look complete while missing whole subtrees; give the backup account read access to everything it is meant to archive. ## When `<get>` is the right call `<get>` exists for monitoring and troubleshooting: reading interface counters, checking operational status, confirming that a change took effect. Its reply mixes both classes, so a client has to know from the data model which nodes are state. `<get>` has **no source parameter**. It cannot read the candidate or startup datastore; to see an uncommitted candidate you use `<get-config>` with `<candidate/>` as the source. ## The NMDA refinement The Network Management Datastore Architecture (RFC 8342) observes that `<get>` returns the contents of running "together with the operational state", which is awkward when the configured value and the value actually in use differ. RFC 8526 adds `<get-data>`, which names its datastore by identity (including the operational state datastore) and can filter to `config true` or `config false` nodes. On a device that supports it, `<get-data>` against the operational datastore is the precise way to read what is in effect, while `<get-config>` on running remains the way to read what was asked for. ## Choosing in practice - **Backup, archive, drift diff, pre-change snapshot:** `<get-config>` with `<running/>`. - **What will boot after a reload:** `<get-config>` with `<startup/>`, when the device advertises `:startup`. - **What is staged but not yet committed:** `<get-config>` with `<candidate/>`, when it advertises `:candidate`. - **Counters, operational status, verification after a change:** `<get>`, or `<get-data>` where available. Every one of these returns an `<rpc-error>` instead of `<data>` when the request cannot be completed, for example when a source datastore the device does not support is named.

  • Which datastore should a NETCONF backup read on a device that also has candidate and startup datastores?
    Usually `<running/>`, because that is the configuration in effect. `<candidate/>` may hold someone's uncommitted, half-finished edits, and `<startup/>` is what the device will load at its next boot, which can lag running if nobody saved. A thorough backup reads running and, where `:startup` is advertised, also compares startup against it to catch unsaved changes.
  • Under NMDA, how would you read the value an interface is actually using rather than the one configured?
    RFC 8526's `<get-data>` names a datastore by identity, so it can read the operational state datastore directly, and its config filter can restrict the reply to state or configuration nodes. `<get>` mixes running with state; `<get-data>` on operational shows what is in effect, including values that differ from running because a change has not yet been applied.

saying these in an interview costs you the question

  • <get> and <get-config> return the same data in different formats.
  • <get> can read the candidate or startup datastore when asked.
  • A <get> dump can be pushed straight back with <edit-config>.
  • <get-config> includes interface counters because they live in running.
  • A <get-config> reply without an error always holds the whole configuration.