Arista EOS Configuration Sessions: commit, abort, rollback

Making several dependent configuration changes on a live Arista switch is risky: each command applies the moment you press Enter in configure terminal, so a mid-change mistake can leave the box half-configured. EOS configuration sessions fix this by staging changes in an isolated copy of running-config that only replaces the live configuration when you explicitly commit. This guide shows the session workflow - create, edit, diff, commit, abort - and the commit-timer safety net that auto-rolls-back a bad change.

Creating a Configuration Session

Enter a session with configure session and an optional name. The prompt changes to show the session, making it obvious you are not in live configuration mode:

switch# configure session change-mgmt-ip
switch(config-s-change-)#

Within the session you run ordinary configuration commands - they modify only the session's copy of the configuration, leaving running-config untouched:

switch(config-s-change-)# interface Management1
switch(config-s-change-)# ip address 4.3.2.1/24
switch(config-s-change-)# exit

Note the truncated prompt: the session name change-mgmt-ip appears as change- because EOS keeps the prompt short enough to fit a terminal line. If you have several sessions open the prompt is the only reliable indication of which configuration you are editing, so use short, meaningful session names.

Two other entry points exist. configure session with no name creates a session named unnamed-session, which is fine for a quick experiment but impossible to reference later. configure private creates a session owned exclusively by your CLI session, so nobody else can see or edit it — the right choice for a change window where several engineers are logged in:

switch# configure private
switch(config-s-)#
switch# configure session add-uplink-vlans
switch# show configuration sessions

show configuration sessions (available from the enable prompt) lists every pending session, who owns it, and when it was created. EOS keeps up to five pending sessions; creating a sixth requires deleting an existing one.

Reviewing Changes Before Commit

Before making anything live, diff the session against the running configuration:

switch(config-s-change-)# show session-config diffs
--- system:/running-config
+++ session:/change-mgmt-ip-session-config
@@ -35,7 +35,6 @@
 interface Management1
-  vrf forwarding management
-  ip address 1.2.3.4/24
+  ip address 4.3.2.1/24

show session-config diffs (also available outside config mode as show session-config named <name> diffs) is the pre-flight check - review it, fix mistakes, and only then commit. Read the diff carefully for unintended deletions: a negative line means a command that existed in running-config and will be removed by the commit. Removing vrf forwarding management in the example above would take the interface out of its VRF, which is easy to miss and hard to notice afterwards.

switch# show session-config named change-mgmt-ip diffs
switch# show session-config named change-mgmt-ip
switch(config-s-change-)# show run

The whole configuration of the session is available as show session-config named <name>, which prints the complete staged config rather than the delta. On a long change that is the better review artefact: pipe it to a file with | redirect flash:change.cfg and keep it with the change record.

Commit or Abort

switch(config-s-change-)# commit          # apply the session atomically
switch(config-s-change-)# abort           # throw away all changes

Because the whole session is applied as one replacement of running-config, commit is atomic: either all changes land or none do. If the session was a mistake, abort discards it completely. Uncommitted sessions are discarded on reboot and time out after 24 hours; EOS keeps up to five pending sessions, and multiple CLI users can work in the same named session (only one may commit).

An explicit abort is not always required — exiting a session with end leaves it pending, so if you want the changes gone you must say so. A common mistake is to leave half a dozen abandoned sessions behind, hit the five-session limit, and then have to clean up before editing again:

switch# show configuration sessions
switch# configure session change-mgmt-ip
switch(config-s-change-)# abort
switch# show configuration sessions

Note that a committed session does not write to flash by itself. Commit updates the running configuration; you still need write memory (or copy running-config startup-config) to persist it across a reload, which also gives you one more chance to back out before the change becomes permanent.

Auto-Rollback with commit timer

The killer feature for risky changes: commit timer commits the session but automatically rolls it back if you do not confirm within the interval. If the change breaks connectivity, the switch reverts itself before you lose access permanently:

switch(config-s-change-)# commit timer 00:05:00

The timer starts at commit. If everything still works, confirm the change from the session:

switch(config-s-change-)# commit
switch(config-s-change-)# abort

Committing again inside the timer window makes the change permanent; running abort inside the window rolls it back immediately instead of waiting for the timer to expire. That second option is the fast way out when you can already see the change is wrong and do not want to wait out the remainder of the interval.

Five minutes covers most management-plane changes. For anything that touches the management interface or the routing protocol that carries your SSH session, use a longer window and make sure you have an out-of-band path — console server, terminal server or a serial connection — before you start, because a rollback that has to reach the box over the interface you just broke is not a rollback.

Confirm the change (or let it revert) afterwards; see the EOS session management documentation for the full command set. A related pattern on the Junos side is commit confirmed, covered in our Junos commit confirmed guide, and NX-OS implements the same idea with rollback checkpoints in Cisco Nexus checkpoint and rollback.

Sessions, configure replace and Checkpoints

Two more mechanisms build on the session engine and are worth knowing about:

switch# configure replace flash:known-good-config overwrite
switch# show rollback
switch# rollback clean-config

configure replace replaces the running configuration with the contents of a file, and EOS executes that internally as a configuration session — which is why the operation is atomic and why a failed replacement leaves the switch untouched. It is the fastest recovery when a change window goes wrong: keep a copy of the last good configuration on flash and on a tftp/http server, then replace instead of trying to reverse-engineer the diff. show rollback lists the checkpoints the rollback engine maintains, and rollback clean-config resets the box to its factory defaults, which is a useful last resort before an RMA. The same idea in a different vendor's syntax appears in Cisco IOS XR commit replace and rollback and in SONiC config_db.json save and replace.

Sessions from Automation and eAPI

Sessions are not just a CLI feature. eAPI, Ansible and other automation tools can wrap a change in a session so that a partially applied playbook does not leave the device half-configured. The pattern with a single eAPI call looks like this:

import requests, json

url = "https://switch/command-api"
payload = {
  "jsonrpc": "2.0", "method": "runCmds", "id": 1,
  "params": {
    "version": 1, "format": "json", "timestamps": False,
    "cmds": [
      "configure session auto-deploy",
      "interface Ethernet10",
      "description ANSIBLE-MANAGED",
      "switchport access vlan 20",
      "show session-config diffs",
      "commit"
    ]
  }
}
r = requests.post(url, data=json.dumps(payload), verify=False,
                  auth=("admin", "admin"), headers={"Content-Type": "application/json"})
print(r.json()["result"][-2]["diffs"])

Because commit is the last command in the batch, a failure anywhere earlier in the list means the commit never runs and the session is left pending rather than applied. That single property removes the most common cause of configuration drift between the source of truth and the device. Tools such as NAPALM can also diff configurations, which is a useful cross-check before you commit; see NAPALM getters, config diff and load.

Practical Use Cases

• Multi-interface changes (VLAN + SVI + routing in one transaction) - see the EOS VLAN/SVI configuration guide for what such a session typically contains.
• Management-plane changes: IP address, VRF, AAA or SSH, where a mistake locks you out and commit timer is the difference between a five-minute outage and a site visit.
• Routing changes: adding a BGP peer, changing a route-map or adjusting a prefix-list, which must land as a set rather than one line at a time.
• Automation-driven changes: tools such as Ansible/Goes and eAPI can wrap every change in a session so a failed run never leaves partial config.
• Replacing the whole config with a known-good file via configure replace, which EOS internally executes as a configuration session.

Verification and Troubleshooting

After a commit, confirm the change actually landed and that it survived the write to flash:

switch# show running-config
switch# show running-config diff
switch# show startup-config
switch# show configuration sessions
switch# show logging | tail 50

Common failure modes and what they mean:

• "Cannot create new session — maximum number of sessions reached." Five pending sessions already exist. List them with show configuration sessions and abort or delete the stale ones.
• Commit is refused because another user committed. Only one user can commit a named session, and the session contents may have changed since you last saw them. Re-read the diffs before retrying.
• Changes disappeared after a reload. The commit succeeded but write memory was never run. Check show running-config diff, which compares running against startup.
• The session prompt is unfamiliar. Run show configuration sessions to identify the session you are inside, and end to leave it without committing.

Sessions are a core habit for safe EOS operations - the rest of the daily command set is in our Arista EOS CLI cheat sheet.

FAQ

Does an aborted session leave any trace? No. The staged copy is discarded and running-config is untouched. The only evidence is the session's presence in show configuration sessions up to the moment you abort it.

Can two engineers edit the same session? Yes, for a named session, but only one of them can commit. For parallel work use configure private so each CLI session gets its own isolated configuration.

What is the difference between commit and write memory? Commit applies the staged configuration to the running system. Write memory persists the running configuration to startup-config so it comes back after a reload.

How long do uncommitted sessions survive? They are discarded on reboot and time out after 24 hours, so a session left over from yesterday morning is very likely already gone.

Does commit timer work for changes that break my SSH session? Yes — that is precisely its purpose. The switch reverts after the interval whether or not you still have a connection, so a change that drops your session rolls itself back.

原文链接：https://damianzaremba.co.uk/2017/01/a-look-at-aristas-configuration-session