skip to content

In NETCONF, what do the running, candidate and startup configuration datastores each hold, and which one must every device have?

level: juniorimportance: must knowfreq 28%

answer

  1. one live, one draft, one for boot
  2. the base model has exactly one
  3. capabilities add the other two
  4. :candidate and :startup capability URIs

basics

~20 s

Running holds the configuration in use now and is the only datastore every NETCONF device has. Candidate is an optional full working copy you edit and then commit; startup is an optional copy loaded at boot.

solid answer

~40 s

RFC 6241 defines a configuration datastore as the complete set of configuration needed to take a device from its default state to the desired one. `<running>` is the configuration currently active, and it is the only datastore the base model guarantees. `<candidate>` exists only when the server advertises `:candidate`: it is a full configuration you can change without touching the device, and a `<commit>` makes running equal to it. `<startup>` exists only with `:startup`: it is what the device loads at boot, and changes to running are not copied there automatically, so you save with `<copy-config>` from running to startup. A client reads the server's `<hello>` capabilities to learn which of the three it can use.

go deeper

for a junior

Recall the three names, that running is the only one always present, and that candidate and startup appear only when the server advertises :candidate or :startup.

for a middle

Explain how the datastores relate: edit candidate, commit to running, copy running to startup, and boot loads startup into running. Know that each datastore is a full configuration.

for a senior

Show that you check the server hello before choosing a workflow, and that you know an unsaved change on a :startup device is undone by a reboot, which is both a risk and a recovery path.

for a principal

Discuss how an automation platform should model devices that expose different datastore sets, and why the RFC 8342 architecture later added intended and operational to the original three.

## What a configuration datastore is NETCONF (RFC 6241, which obsoletes RFC 4741) separates *where* configuration lives from *how* you change it. A **configuration datastore** is, in the RFC's words, the complete set of configuration data required to get a device from its initial default state into a desired operational state. Two consequences follow straight from that definition: - A datastore is a **whole configuration**, not a list of pending changes. - A configuration datastore holds **no state data** such as counters or learned neighbours, and no executive commands. Protocol operations name the datastore they act on with an empty element: `<running/>`, `<candidate/>` or `<startup/>` inside a `<source>` or `<target>` parameter. ## The three datastores of RFC 6241 | Datastore | What it holds | Present when | How it changes | |---|---|---|---| | `<running>` | the configuration active on the device right now | always; exactly one exists | `<edit-config>` or `<copy-config>` if `:writable-running` is advertised, or a `<commit>` from the candidate | | `<candidate>` | a full working copy that does not affect the device | the server advertises `:candidate` | `<edit-config>`, `<copy-config>`; reset by `<discard-changes>` | | `<startup>` | the configuration loaded when the device boots | the server advertises `:startup` | `<copy-config>` from running to startup | The base model has **only `<running>`**. RFC 6241 Section 5.1 says additional datastores may be defined by capabilities and exist only on devices that advertise them; Sections 8.3 and 8.7 define candidate and startup that way. RFC 8342, the datastore architecture, adds that running does not even have to be writable: a device may expose running for reading and accept changes only through the candidate. ## How a client learns what exists Each peer sends a `<hello>` listing its capabilities as URIs when the session opens. The three datastore-related ones are: 1. `urn:ietf:params:netconf:capability:writable-running:1.0` - running can be the target of `<edit-config>` and `<copy-config>`. 2. `urn:ietf:params:netconf:capability:candidate:1.0` - the candidate datastore exists, and so do `<commit>` and `<discard-changes>`. 3. `urn:ietf:params:netconf:capability:startup:1.0` - running and startup are distinct, and saving is an explicit step. A client that skips this check and assumes a candidate will find `<commit>` unavailable on a device that never advertised `:candidate`. ## How the datastores relate RFC 8342 draws the original NETCONF model as three boxes with running in the middle: 1. The client edits `<candidate>`; nothing on the device changes yet. 2. `<commit>` sets `<running>` to the candidate's contents, and the device starts behaving accordingly. 3. `<copy-config>` with running as source and startup as target saves the result. 4. At boot, the device loads `<startup>` into `<running>`. RFC 8342 also says how the copies behave across a reboot: the candidate does not typically persist, and if it is kept in non-volatile storage it is reset to the contents of running at boot. A device with no distinct startup will typically use non-volatile storage so that running itself persists, which is an implementation choice rather than a protocol step. ## Common confusions - **"Candidate holds my diff."** It holds a full configuration, so a commit makes running equal to everything in it, including edits another session left there. - **"Changing running updates startup."** On a `:startup` device, RFC 6241 Section 8.7 says operations that affect running are not automatically copied to startup. - **"Startup is where you stage changes."** Staging is the candidate's job; startup is only what boot loads, and the standard editing model changes it only by copying running into it. - **"Every device has all three."** Only running is guaranteed; candidate and startup are optional and announced. - **"Running includes interface counters."** Counters are state data. The NETCONF `<get>` operation returns running together with state, which is why the two are easy to mix up, but the datastore itself is configuration only. ## Why the split matters to an operator The set of datastores a device advertises decides how a change can be pushed safely. With a candidate, a large change can be assembled, checked and applied in one step. With only a writable running datastore, every edit is live the moment it is accepted. With a distinct startup, a change that was never saved is undone by a reboot, which is a recovery path as much as it is a trap. Knowing which datastores exist is therefore the first question any NETCONF automation asks of a device.

  • Does the NETCONF candidate datastore survive a device reboot?
    RFC 8342 says the candidate does not typically persist across reboots, even when non-volatile storage is available. If an implementation does store it in non-volatile storage, the candidate is reset at boot to the contents of running. Uncommitted work in the candidate should therefore be treated as lost on reboot.
  • Can a NETCONF device have a candidate but refuse direct writes to running?
    Yes. `:writable-running` and `:candidate` are independent capabilities. A device that advertises `:candidate` without `:writable-running` accepts NETCONF configuration only through the candidate, so over NETCONF a `<commit>` is how running changes. RFC 8342 notes that running does not have to be writable.
  • Why does RFC 6241 keep state data out of the configuration datastores?
    A configuration datastore is defined as the configuration needed to reach a desired state, so it excludes state data and executive commands. That keeps datastores copyable and comparable: copying running to startup copies intent, not counters. State is read with `<get>`, which returns running plus state, or under NMDA from the operational datastore.

Running is the plan on the team's whiteboard that everyone is working from; candidate is a full redraft on a shared flip chart beside it that nobody acts on until someone copies it onto the board; startup is a photo of the board kept for the morning. Redrawing the board does not retake the photo; you have to take it again.

saying these in an interview costs you the question

  • Candidate and startup exist on every NETCONF device.
  • Changing running also updates startup automatically.
  • The candidate holds only the diff waiting to be applied.
  • Startup is the place to stage changes before activating them.
  • The running datastore includes counters and other state data.