On a NETCONF device advertising :startup, why does a committed change disappear after a reboot, and how do you make it persist?

## Two copies of the configuration The `:startup` capability (RFC 6241 Section 8.7, identifier `urn:ietf:params:netconf:capability:startup:1.0`) announces that the device keeps **separate running and startup datastores**. Their roles are fixed: - `<startup>` is the configuration the device **loads when it boots**. - `<running>` is the configuration **active now**. - Operations that affect running are **not automatically copied** to startup. RFC 8342 describes the same pair: on devices with non-volatile storage, startup typically persists across reboots, and at boot the device loads the saved startup configuration into running. So a change that reached running by any route, whether a `<commit>` from the candidate or an `<edit-config>` on a writable running datastore, lives only until the next reboot. ## The save operation RFC 6241 names the operation explicitly: to save the startup configuration, use `<copy-config>` to copy the running datastore to the startup datastore. `<copy-config>` replaces an entire target datastore with the contents of the source, so the result is that startup becomes an exact copy of running at that moment. The `:startup` capability adds `<startup/>` as a legal parameter to these operations: | Operation | Parameter | Note | |---|---|---| | `<get-config>` | source | read what the device will boot with | | `<copy-config>` | source and target | the save, or a restore into running | | `<lock>` / `<unlock>` | target | guard startup while saving | | `<validate>` | source | only if `:validate:1.1` is advertised | | `<delete-config>` | target | the RFC notes this resets the device to its factory defaults | `<edit-config>` is not on that list. RFC 8342 Section 4.1 says the same thing in prose: in the standardized NETCONF editing model, startup can only be modified by copying running to it. You do not edit startup line by line; you make running right and copy it. If the source and the target name the same datastore, RFC 6241 requires an `invalid-value` error, which catches a script that builds the RPC from the wrong variable. ## When to save RFC 6241 Appendix E lays out the steps for changing one device: lock, checkpoint running, load and validate, change running, **test the new configuration**, then make the change permanent "if desired", then unlock. The order is deliberate: 1. Apply the change to running. 2. Test it: reachability, routing tables, the specific feature you changed. 3. Only when the tests pass, copy running to startup. Leaving startup alone until step 3 means a change that breaks management access can still be undone by power-cycling the device, because it will boot the last configuration you trusted. Saving immediately throws that recovery path away and makes the broken configuration the one the device returns to. The opposite failure is forgetting step 3. The change works, nobody saves it, and months later a power event brings the device back with the old configuration. The usual guard is a check in the automation that compares running with startup, both readable with `<get-config>`: - **startup equals running**: the device will come back as it is now. - **startup lags running**: an unsaved change exists; either it is still under test or someone forgot to save. - **startup differs in a way no recent change explains**: someone copied a different configuration into startup, and the next reboot will apply it. A lag that persists past the end of a change window is the signal worth alerting on, because it is the state that turns a routine power cycle into a configuration rollback nobody asked for. ## Devices without :startup Not every device separates the two. Without `:startup` there is no startup datastore to name and **no save step on the wire**. RFC 8342 says such a device will typically use non-volatile storage so that running itself persists across reboots, but this is how implementations usually behave, not an operation the protocol defines. The capability list in the server's `<hello>` is what tells the client which model applies. ## Other clients on the same device RESTCONF, the HTTP-based sibling of NETCONF, behaves differently. RFC 8040 Section 1.4 says that if the server supports `:startup`, the RESTCONF server must automatically update the startup configuration after running has been altered by a RESTCONF edit. A device managed through both protocols therefore saves on every RESTCONF write but only on an explicit `<copy-config>` from NETCONF, and a NETCONF change committed but not yet saved can be swept into startup by an unrelated RESTCONF edit. Teams that mix the two should know which one owns the save.