How do you detect and deal with configuration drift?
Show the answer
Say this first
Drift is the difference between intended config (rendered from the source of truth and templates) and
what is actually running. I detect it on a schedule by rendering the full intended config and diffing it
against the device: NAPALM load_replace_candidate plus compare_config, Ansible check mode with diff, or
controller compliance reports. Each difference is either an approved emergency change that goes back
into the source of truth, or an unauthorized one that gets remediated by pushing intent again.
Go deeper
Where it comes from
- CLI fixes during incidents that never made it back to the data.
- Partial pushes that failed halfway.
- Software upgrades that change defaults or how config is displayed.
- Other tools writing to the same device.
Why merge-only automation cannot see it
If you only merge lines, extra config added by hand never shows up in your diff. Only a full intended config compared with the full running config (replace semantics) reveals additions as well as changes.
Practical setup
- Nightly job renders intended configs and diffs them with the running configs.
- Ignore volatile lines:
! Last configuration change at ..., certificate blobs,ntp clock-period. - Report per device and per section, and track the drift count over time.
- Backups (Oxidized or RANCID style) in Git give a timeline of when each line appeared.
- Ansible:
ios_configwithdiff_against: intendedandintended_config, run with--check --diff.
Policy
Decide per section: some are enforced (AAA, SNMP, NTP, ACLs), where intent always wins and drift is corrected automatically; others are report-only while the team builds trust.
They will ask next
An engineer fixed an outage at 2 a.m. by CLI. Your nightly drift job wants to revert it. What should happen?
The job should report, not blindly revert, for sections where emergency changes are allowed. The engineer opens a merge request to put the fix in the source of truth. Once merged, the drift disappears. If nobody claims it in a set time, it is treated as unauthorized and reverted in the next window.
Traps
- Auto-remediating everything from day one. A wrong template then "fixes" correct configs across the estate.