Octet

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_config with diff_against: intended and intended_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.

Traps

  • Auto-remediating everything from day one. A wrong template then "fixes" correct configs across the estate.
How did you do?