skip to content

A NETCONF <edit-config> changing twenty interfaces hits an error on the twelfth; what does each error-option value leave in the target datastore?

level: seniorimportance: should knowfreq 7%

answer

  1. the default stops, but promises little
  2. an error reply, yet edits landed
  3. one value needs its own capability
  4. test-option runs before any of this

basics

~20 s

stop-on-error, the default, aborts at the first error without promising to undo earlier edits; continue-on-error applies what it can and still replies with an error; rollback-on-error, which needs the :rollback-on-error capability, restores the target to its state before the request.

solid answer

~40 s

RFC 6241 gives `<edit-config>` three `error-option` values. `stop-on-error`, the default, aborts the operation on the first error; the RFC does not say the eleven edits already applied are undone, so a client cannot assume the target is unchanged. `continue-on-error` keeps processing, records each error and returns a negative reply if any occurred, so the target may hold nineteen changes under an `<rpc-error>`. `rollback-on-error`, usable only when the server advertises `:rollback-on-error`, stops and restores the target to its complete state at the start of this `<edit-config>`; RFC 6241 strongly suggests a lock on shared datastores, because the rollback can undo other sessions' changes. Separately, on a server advertising `:validate:1.1`, the default `test-option` of `test-then-set` validates first and applies nothing if validation fails, so an invalid value is often rejected before any edit lands.

code

xml · 14 lines
xml
<edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <target><running/></target>
  <test-option>test-then-set</test-option>
  <error-option>rollback-on-error</error-option>
  <config>
    <top xmlns="http://example.com/schema/1.2/config">
      <interface>
        <name>uplink-1</name>
        <mtu>9000</mtu>
      </interface>
      <!-- nineteen more interface entries -->
    </top>
  </config>
</edit-config>

go deeper

for a junior

Recall the three error-option values, stop-on-error, continue-on-error and rollback-on-error, and that stop-on-error is the default.

for a middle

Explain each value's effect on the edits around a failure, the capability rollback-on-error requires, and how test-option's default validates before applying.

for a senior

Show the operating habit: never read an rpc-error as no change, read back after stop or continue, and lock before relying on rollback on a shared datastore.

for a principal

Weigh rollback-on-error against staging in a candidate datastore for all-or-nothing changes, and decide which bulk jobs may tolerate partial application at all.

## Two parameters, two phases A NETCONF `<edit-config>` (RFC 6241) can carry two optional parameters that decide what happens when something goes wrong: - **`<test-option>`** controls whether the server **validates** the change before applying it. - **`<error-option>`** controls what the server does when an error occurs **while applying** it. They act at different moments, and a senior answer keeps them apart. ## test-option: validate first, or not `<test-option>` may be sent only if the server advertises the **`:validate:1.1`** capability. Its values: | Value | Behaviour | |---|---| | `test-then-set` | Validate, and if validation errors occur, do not perform the edit. **The default.** | | `set` | Apply without a validation test first. | | `test-only` | Validate only; never apply, even if there are no errors. Added in `:validate:1.1`. | On a server with `:validate:1.1`, then, a request whose twelfth interface carries a value the server's validation catches is rejected **before anything changes**: validation fails and the edit is not performed. RFC 6241 requires validation to check at least for syntax errors; how much more it checks is up to the server. `error-option` matters for the errors validation does not catch, and on servers that do not advertise the capability at all. ## error-option: what happens to the other edits | Value | On the first error | Reply | What the target can hold | |---|---|---|---| | `stop-on-error` (default) | Abort the operation | `<rpc-error>` | Possibly the edits applied before the error; RFC 6241 does not promise to undo them | | `continue-on-error` | Record the error, keep processing | One or more `<rpc-error>` elements, no `<ok>` | Every edit that succeeded, around the failures | | `rollback-on-error` | Stop, restore the target | `<rpc-error>` | Its complete state at the start of this `<edit-config>` | Read the twenty-interface case through each row: 1. **`stop-on-error`**: processing ends at interface twelve. The text says only "abort the operation on first error"; a client that needs to know what the target now holds must read it back with `<get-config>` rather than assume interfaces one to eleven were reverted. 2. **`continue-on-error`**: interfaces thirteen to twenty are still attempted. The reply is negative even though nineteen interfaces may now carry the new setting, so a client that treats any `<rpc-error>` as "nothing happened" is wrong here. 3. **`rollback-on-error`**: the server stops and puts the datastore back as it was when this request began. If that restoration itself fails, the error-tag is `rollback-failed`. ## The cost of rollback-on-error `rollback-on-error` is a capability, `urn:ietf:params:netconf:capability:rollback-on-error:1.0`, and a client must check the server's `<hello>` for it before using the value. RFC 6241 also warns that on a **shared** datastore the rollback "can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed", and strongly suggests taking the configuration lock before the edit. The restore point is the whole datastore at the start of the request, not just your own nodes, so another session's concurrent change can be swept away with yours. ## Why a client cannot rely on a progress report RFC 4741 had a `partial-operation` error-tag whose `error-info` listed which elements succeeded, failed or were not attempted. RFC 6241 made it **obsolete**: servers should not send it. A client therefore cannot expect the server to say which of the twenty edits landed under `stop-on-error` or `continue-on-error`; reading the datastore back is the reliable way to know. ## Choosing in practice - **A change that must land whole or not at all:** `rollback-on-error` where advertised, inside a lock on a shared datastore, or stage the edit in a candidate datastore and commit it as one unit where the device has one. - **A best-effort bulk update whose items are independent:** `continue-on-error`, then reconcile from the per-error `error-path` values and a read-back. - **A dry run in a review step:** `test-only`, which validates without applying and so checks syntax and constraints, not intent. - **Plain `stop-on-error` on running:** acceptable only when the client follows every failure with a read-back. - **Report honestly upstream.** A job runner that maps every `<rpc-error>` to "failed, nothing changed" misleads the next operator; record which `error-option` was used, so the follow-up step knows what it has to check.

  • Why does RFC 6241 strongly suggest a lock when using rollback-on-error on a shared datastore?
    The rollback restores the whole target datastore to its state at the start of the `<edit-config>`. If another session changed the datastore during that window, its change is part of what gets rolled back. Holding the datastore's lock for the duration keeps other writers out, so the only changes undone are your own.
  • After a continue-on-error reply carrying two <rpc-error> elements, how should a client reconcile?
    Treat the request as partly applied. Use each error's `error-tag` and `error-path` to identify the failed nodes, then read the affected subtree back with `<get-config>` to confirm what landed, since the server need not report every error. Retry only the failed items, ideally with tolerant operations so a retry cannot fail on data that is now correct.

saying these in an interview costs you the question

  • An <rpc-error> after stop-on-error proves the target was left unchanged.
  • continue-on-error returns <ok> as long as some edits succeeded.
  • rollback-on-error can be sent to any NETCONF server.
  • rollback-on-error undoes only my edits, never another session's change.
  • test-only can be sent whether or not :validate:1.1 is advertised.
  • A NETCONF server reports which edits succeeded through partial-operation.