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

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.

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).

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

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.

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.
• 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.

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

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