Dell OS10 Transaction-Based Configuration Mode: Candidate Config Workflow

Most switch operating systems apply configuration commands the moment you type them, which makes multi-step changes risky: a typo halfway through is already live. Dell OS10 solves this with transaction-based configuration mode, where commands are staged into a candidate configuration and only applied when you explicitly commit. This article explains how the mode works, why it is safer than the default behavior for production changes, and walks through the full command sequence with a real interface-description example. It is one of the most under-used safety features in the OS10 CLI.

Everything here follows Dell's KB 000120163, expanded with the details that matter when you use the feature for real: which commands belong to the transaction, how the candidate file behaves across sessions, what happens if your SSH session drops mid-change, and where transaction mode stops being useful and you should reach for a different tool instead.

Default Behavior vs. Transaction Mode

By default, every OS10 configuration command takes effect immediately in the running configuration. In transaction mode, your commands are stored in a candidate configuration; nothing changes in the running configuration until you commit. This gives you a review point before any change goes live, and a clean way to throw away mistakes with discard.

The trade-off is honestly small. Transaction mode is not a separate CLI, it does not change command syntax, and it does not slow you down unless you want it to. It is simply a switch that redirects configuration writes into a staging file, plus three verbs — review, discard, commit — that you get to use before anything reaches the data plane. Transaction-based configuration mode is disabled by default in OS10 (as of 10.4.x), so nothing changes for an engineer who does not ask for it.

Why It Matters in Production

Think about the last time you changed an interface description, added a VLAN to a trunk, or moved a port into a LAG during a maintenance window. Each of those is a small change, but they are usually delivered as a sequence: remove the old configuration, add the new one, save, verify. In the default OS10 behaviour, every line in that sequence is live the instant you press Enter. If you mistype a VLAN ID in the middle of the sequence, the network is already running the wrong thing while you look for the typo.

Transaction mode turns the sequence into a single unit of work:

• Review before impact. show diff candidate-configuration running-configuration prints exactly what will be added or removed, in configuration-file format, before a single packet is affected.
• Abort cheaply. A wrong candidate is discarded with one command; there is no rollback plan to write and no partial state to untangle.
• Batch related changes. A VLAN plus an interface plus a port-channel membership can be prepared and applied together, which reduces the window in which the network is half-configured.
• Teach the process to juniors. "Stage it, show the diff, commit" is a workflow you can put in a change runbook and audit afterwards, instead of relying on the operator's care while typing.

What it is not is a substitute for saving. A committed change lives in the running configuration, which is still RAM-only. Transaction mode changes how a change reaches the running configuration; it does not change the fact that you must persist it afterwards.

How to Use Transaction-Based Configuration Mode

Start the transaction from EXEC mode, then make your changes as usual:

OS10# start transaction

Now enter configuration mode and modify the interface — for example, changing the description of ethernet 1/1/1:

OS10# configure terminal
OS10(config)# interface ethernet 1/1/1
OS10(conf-if-eth1/1/1)# description TEST

From this point the session is in transaction mode: any configuration command you type goes into the candidate file. You can enter and leave configuration mode, work on interfaces, VLANs or the VLT domain, and nothing you type will reach the running configuration. The prompt does not change, which is the one usability wart of the feature — get into the habit of checking with a diff before you commit, not after.

Review the Difference

Before committing, see exactly what will change:

OS10(conf-if-eth1/1/1)# do show diff candidate-configuration running-configuration
!
interface ethernet1/1/1
 description TEST

The do prefix is what lets you run an EXEC-mode command without leaving configuration mode, and the diff output is deliberately readable: it shows the candidate as configuration text, so a missing VLAN tag or an extra shutdown is visible at a glance. Run the diff again after any further edit; it always reflects the current candidate, not a snapshot from when the transaction started.

Discard or Commit

If the change is wrong, discard the whole candidate:

OS10(conf-if-eth1/1/1)# do discard

If it looks right, commit it to the running configuration:

OS10(conf-if-eth1/1/1)# do commit
OS10(conf-if-eth1/1/1)# do show running-configuration interface ethernet 1/1/1
!
interface ethernet1/1/1
 description TEST
 no shutdown

Two behaviours follow from the commit. First, the running configuration now contains the change, and your re-run of show running-configuration is the proof — never assume a commit succeeded, look at the output. Second, the session leaves transaction mode and returns to the default "apply immediately" behaviour. If you have a second change to stage, start a new transaction.

Persisting the Change

Like normal OS10 changes, a committed change is not permanent until you save it:

OS10(conf-if-eth1/1/1)# do write memory

The equivalent form, if you have already left configuration mode, is copy running-configuration startup-configuration. Both write the running configuration over the startup configuration, which is what the switch reads at the next reload. If a reload happens between the commit and the save, the change is gone — the candidate configuration is not consulted at boot.

Command Reference

Session Behaviour and the Gotchas That Bite

The transaction is a property of the switch, not of your SSH session, and that is where the surprises live:

• All sessions share one candidate configuration. If two people are in transaction mode at the same time, they are editing the same staging file. Reviewing a diff may show changes you did not make.
• A commit publishes everyone's staged work. When any session commits, the changes staged by every session in transaction mode are applied. The same happens if somebody makes a configuration change in normal (non-transaction) mode — that act commits the candidate as well.
• Dell recommends one CLI session at a time. Treat transaction mode as a single-operator tool, and coordinate change windows accordingly.
• An interrupted session does not lose the work. If your terminal drops or the session times out without a commit, the candidate configuration retains the changes. You can open a new session, run start transaction, review the diff and continue.
• Do not forget you are still in transaction mode. The prompt does not tell you. If a change seems to have no effect, the first thing to check is whether you actually committed it.

Where Transaction Mode Stops Helping

Transaction mode is a staging and review mechanism, not a time machine. It protects you against the change that has not been committed yet — nothing more. In particular:

• It does not validate the change at a protocol level. A commit will happily apply a configuration that breaks OSPF adjacencies, VLT, or LACP negotiation; the diff is a text comparison, not a simulation.
• It does not provide a rollback of committed changes. For that you want the platform's rollback and rollback-config capabilities, or an out-of-band copy of the working configuration that you can restore.
• It does not protect against a wrong-but-well-typed change. If the VLAN ID in the candidate is the wrong VLAN but a real one, the diff looks perfect.
• It does not replace saving. Commit puts the change in the running configuration; write memory puts it in the startup configuration.

So the safe pattern is layered: stage with a transaction, review the diff, commit, verify with show running-configuration, save with write memory, and keep a backup of the previous configuration on a server so you have a real rollback option.

Comparing the Approach Across Platforms

If you work in a mixed environment, the mental model maps cleanly. OS10's transaction mode is a lightweight version of the config session and rollback features found elsewhere: Arista EOS configuration sessions with commit and abort, Junos commit confirmed with automatic rollback, and IOS XR's commit replace and rollback points all attack the same problem — never let a half-finished change go live. OS10's version keeps the review-and-abort half but not the automatic-rollback half, which is exactly why the out-of-band configuration backup belongs in the runbook.

A Practical Runbook

OS10# copy running-configuration tftp://10.0.0.50/pre-change-$(date).cfg
OS10# start transaction
OS10# configure terminal
OS10(config)# interface ethernet 1/1/1
OS10(conf-if-eth1/1/1)# description uplink-to-core-sw01
OS10(conf-if-eth1/1/1)# exit
OS10(config)# interface port-channel 5
OS10(conf-if-po-5)# vlt-port-channel 5
OS10(conf-if-po-5)# exit
OS10(config)# end
OS10# show diff candidate-configuration running-configuration
OS10# commit
OS10# show running-configuration interface ethernet 1/1/1
OS10# show running-configuration interface port-channel 5
OS10# write memory

The order is deliberate: back up, stage, review, commit, verify, save. Note that the diff runs in EXEC mode after end rather than with the do prefix inside configuration mode — both work, and doing it after leaving configuration mode gives you a cleaner final review of the whole batch.

Key Takeaways

• start transaction switches to candidate-based configuration editing.
• show diff candidate-configuration running-configuration reviews pending changes.
• discard rolls back the candidate; commit applies it; write memory saves it.
• All sessions share the candidate configuration, so make changes one session at a time.
• An interrupted session keeps its staged work, and a commit anywhere publishes it.

Pair this workflow with the basics covered in Dell OS10 基础管理配置 and the port-group guidance in Dell OS10 S5212F 快速入门 to build a safe day-to-day OS10 operating routine.

For the neighbouring workflows, see Dell OS10 port-channel and LACP configuration for the change most often staged this way, Arista EOS configuration sessions with commit and rollback and Junos commit confirmed and rollback for the equivalent safety nets on other platforms, and Dell OS10 VLT setup for a multi-step change that is much safer to stage and review than to type live.

原文链接：https://www.dell.com/support/kbdoc/en-us/000120163/dell-emc-networking-os10-how-to-use-transaction-based-configuration-mode