Three baselines, three kinds of drift
- Running versus startup. Changes made but not saved. A reload silently reverts them: the fix made during last month’s incident disappears at the next power event. Junos (opens in a new tab) has no running and startup split; its equivalent risk is uncommitted work left in the candidate configuration.
- Running versus golden. Differences from the approved standard for the device’s role: management access, AAA, logging, NTP, SNMP, spanning-tree protections, control-plane policing. This is where security and consistency drift shows up.
- Running versus the last approved change. The configuration should equal the configuration left by the last approved change. Anything else is an unrecorded change: an emergency fix never written up, a test left in place, a change made on the wrong device.
Add a fourth comparison for redundant pairs. Members of an HSRP or VRRP pair, vPC or MLAG peers and firewall HA pairs should differ only where the design says they differ. A line present on one core and missing on the other is drift, even when both match the golden configuration.
Words in capitals in the commands below are placeholders for your values.
Cisco IOS XE: the configuration archive and differences
IOS XE compares configurations with show archive config differences. With no arguments it compares the startup configuration with the running configuration; with one file it compares that file with the running configuration; with two files it compares them in the order given. Lines marked + exist only in the second configuration, and lines marked - only in the first.
Turn on the archive so there is history to compare against. In configuration mode:
archiveenters archive configuration.path flash:archived-configsets where copies go; each copy gets a number.write-memoryarchives a copy every time the configuration is saved.time-period 1440also archives on a timer (the value is in minutes, so 1440 is daily).maximum 14keeps the 14 most recent copies.log config, thenlogging enable, records each configuration command with the user who entered it;hidekeysunderlog configkeeps passwords out of that log.
| Check | Command | What good looks like |
|---|---|---|
| Running versus startup | show archive config differences | No differences: everything running is saved |
| Archive settings and copies | show archive | Archive path set and the most recent copy listed |
| Archive a copy now | archive config | A new numbered copy appears in show archive |
| Compare two archived copies | show archive config differences flash:archived-config-3 flash:archived-config-4 | Only the lines of approved changes between the two copies |
| Compare a saved copy with running | show archive config differences flash:CHG-NUMBER-pre.cfg | Only the lines of approved changes made since that copy |
| Who changed what | show archive log config all | Every entry matches an approved change or a known operator (needs logging enabled under archive log config) |
| Configuration events in the log | show logging | include CONFIG_I | Every “Configured from” event matches a change record |
Syntax varies by platform and software version; test in a lab first.
Cisco NX-OS: running-config diff and checkpoints
NX-OS (opens in a new tab) shows unsaved changes with show running-config diff. Checkpoints give you a baseline to compare against: create one before every change and at the end of every approved window, then diff the running configuration against it. Checkpoint names must be unique and must not start with the word system.
| Check | Command | What good looks like |
|---|---|---|
| Running versus startup | show running-config diff | No differences: everything running is saved |
| Create a checkpoint | checkpoint NAME | Checkpoint created before each change and at the end of each approved window |
| List checkpoints | show checkpoint summary | A checkpoint exists for the last approved change |
| Compare a checkpoint with running | show diff rollback-patch checkpoint NAME running-config | Nothing beyond approved changes made since the checkpoint |
| Save a copy to bootflash | copy running-config bootflash:NAME.cfg | File saved for later or off-box comparison |
| Compare a saved file with running | show diff rollback-patch file bootflash:NAME.cfg running-config | Nothing beyond approved changes made since the file was saved |
| Who changed what | show accounting log | Every configuration command in the period matches an approved change |
| Roll back to a checkpoint: STATE-CHANGING, approved maintenance window only | rollback running-config checkpoint NAME atomic | Applied only if no errors occur; confirm afterward with show diff rollback-patch |
Syntax varies by platform and software version; test in a lab first.
Arista EOS: configuration sessions and diffs
EOS shows unsaved changes with show running-config diffs. Configuration sessions help prevent drift: a change made in configure session NAME is reviewed with show session-config diffs before it takes effect, and the session name can carry the change number. Check for abandoned sessions too; show configuration sessions lists them.
| Check | Command | What good looks like |
|---|---|---|
| Running versus startup | show running-config diffs | No differences: everything running is saved |
| Sessions on the switch | show configuration sessions | No abandoned sessions; session names match change numbers |
| Start a change in a session | configure session NAME | Changes held in the session until committed |
| Review the session before commit | show session-config diffs | Only the lines of the approved change |
| Commit with automatic rollback: STATE-CHANGING, approved maintenance window only | commit timer 00:10:00 | Session committed; rolled back unless confirmed within 10 minutes |
| Confirm the timed commit: STATE-CHANGING, approved maintenance window only | configure session NAME commit | Change kept |
| Discard a session | configure session NAME abort | Session removed; running configuration unchanged |
| Save a copy to flash | copy running-config flash:NAME.cfg | File saved for later comparison |
| Export without secrets for off-box diffs | show running-config sanitized | Passwords and keys masked in the output |
| Restore a saved configuration: STATE-CHANGING, approved maintenance window only | configure replace flash:NAME.cfg | Running configuration replaced by the file; verify afterward |
Syntax varies by platform and software version; test in a lab first.
Juniper Junos: commit history and rollback comparison
Junos (opens in a new tab) records every commit with its time, user and comment, and keeps previous configurations as numbered rollbacks (rollback 0 is the active configuration). That makes the last approved change easy to find: show system commit lists the commits, and show configuration | compare rollback N shows everything that changed since commit N. The same pipe compares against a file, which is how you check a device against a golden configuration stored on it.
One Junos (opens in a new tab) habit causes quiet drift. In shared configuration mode, uncommitted changes stay in the candidate, and the next person who types commit commits them. Check with show | compare and status before you start.
| Check | Command | What good looks like |
|---|---|---|
| Commit history | show system commit | Every commit in the period has a known user and a change number in its comment |
| What changed since commit N | show configuration | compare rollback N | Only lines from approved changes |
| Compare with a golden file on the device | show configuration | compare /var/tmp/GOLDEN.conf | Only the differences the role allows |
| Uncommitted changes (configuration mode) | show | compare | Nothing pending in the candidate |
| Who else is editing (configuration mode) | status | No one else editing, or the other users are known |
| Set-format export for off-box diffs | show configuration | display set | One line per statement, ready for a line-by-line diff |
| Commit events in the log | show log messages | match UI_COMMIT | Every commit matches a change record |
| Commit with the change number (configuration mode) | commit comment "CHG-NUMBER" | Comment visible in show system commit |
| Return to a previous commit (configuration mode): STATE-CHANGING, approved maintenance window only | rollback 1 | Candidate loaded from rollback 1; review with show | compare, then commit to apply |
Syntax varies by platform and software version; test in a lab first.
Comparing against a golden configuration
A golden configuration is only useful when it is rendered per device: the role template filled in with that device’s hostname, addresses and interfaces. Compare the rendered golden with the device’s running configuration, off the box, with any text diff tool.
- Normalize both sides first. Strip header comments and timestamps and compare in one format; on Junos (opens in a new tab),
display setoutput diffs cleanly line by line. - Never sort to make a diff tidy where order matters: ACL entries, route-map and policy terms, prefix lists. Their order changes behavior.
- Keep an exceptions list with the device, the lines, the reason, the approver and an expiry date. An exception without an expiry becomes the new standard by accident.
- Keep golden templates in version control and review changes to them like changes to the network.
What drift matters, and what is noise
Not every difference deserves a ticket. Rank findings by what they put at risk: security first, then redundancy, then routing policy. Filter the noise, but keep the filter visible so nobody hides a real change behind it.
| Category | Examples | Why it matters |
|---|---|---|
| Security | New local user; SNMP community or user added; management ACL removed from the VTY lines; logging or AAA server removed; a password or key changed outside a change | Access and audit trail. A changed secret with no change record is a security event until it is explained. |
| Redundancy | HSRP or VRRP priority, preemption or tracking different between peers; DHCP helper or static route on one core only; vPC or MLAG parameter mismatch; HA monitored interface removed | The pair works today and fails on the day it is needed. |
| Routing policy | Prefix-list entry added; route-map or policy-statement term changed; new redistribution; static route added; OSPF cost changed | Changes what the network advertises and where traffic goes, often far from the device that changed. |
| Noise | Header comments and timestamps; lines some Cisco (opens in a new tab) IOS releases write themselves, such as ntp clock-period; default lines a new release displays; order changes in sections where order has no effect | Filter it so real findings stand out, and review the filter itself from time to time. |
Adjust the categories and examples to your own standards and audit scope.
A weekly drift review routine
An hour a week keeps drift from piling up. Run it on the same day each week, with the same worksheet.
- Unsaved changes. List every device where running and startup differ and, on Junos (opens in a new tab), any uncommitted candidate. Find the change behind each: save it if it was approved, revert it if it was not.
- Unrecorded changes. List the configuration changes of the last 7 days from commit history, archive logs, accounting logs and syslog. Match each to an approved change record. Anything unmatched gets a ticket and an owner.
- Golden comparison. Compare every device with its rendered golden configuration. Review only deviations that are new since last week; known ones are either in the exceptions list or already have an owner.
- Pair comparison. Compare the members of each redundant pair on the lines that should match.
- Classify and assign. Mark each finding security, redundancy, routing policy or noise, and give it a severity, an owner and a due date.
- Trend. Record open findings at the start and end of the week, and how many are high severity. A number that only grows is a process problem, not a device problem.
Command accounting through TACACS+ records who entered which command on every platform that supports it, which makes step 2 much faster than reading device logs one at a time.