Snapshots, diff & drift

Every collection produces a snapshot — one immutable, content-hashed capture of a device’s config. Snapshots are what the tracker versions, diffs and watches for drift, and — because Taranac is your AAA server — what it can attribute to the operator who made the change.

config-tracker · core-sw01

v1 v2 v3 init baseline drift

interface Gi0/1

- ip access-group 10 in

+ ip access-group 42 in

who typed it j.doe conf t · ip access-group 42 in

Term	What it is
Snapshot	One capture, stored with its content hash, size and capture time. The scrubbed text is stored inline; binary configs are stored hash-only (versioned by hash, no diff).
Version (v{n})	A per-config sequence number — v1 is the oldest capture, v{n} the newest. It counts that config’s snapshots in capture order.
Content hash	A SHA-256 of the scrubbed body. It’s how the tracker decides whether a capture is a change or a duplicate.
Baseline	The one snapshot per config you declare “known-good.” Drift is measured against it.
Drift	The latest capture’s hash no longer matches the baseline’s hash.
Config status	A derived health value shown on the Configs list (below).
AAA activity	Who logged in, which commands they ran, and the session accounting — in the window between two versions.

When a collection completes, Taranac hashes the scrubbed config and compares it to the latest snapshot only:

• Same hash → nothing is stored. The run records the target as unchanged; no new version is cut.
• Different hash → a new snapshot is stored and the version number advances (changed).

Because comparison is against the latest snapshot (not the whole history), reverting a device to an older config is correctly recorded as a new change — the hash differs from the current latest, so a new version is cut. Version numbers are per config, so every tracked config has its own clean v1…v{n} timeline.

Any version can be pinned as the baseline — the config you consider correct. From then on, the tracker compares each new capture’s hash to the baseline’s:

• Latest hash matches baseline → the config is in sync.
• Latest hash differs → the config is drifted, and it’s flagged the instant the drifting capture lands.

There is exactly one baseline per config: pinning a new one moves the marker off the old version. A config with no baseline is never “drifted” — drift is defined only relative to a baseline you’ve set.

Beyond the baseline, a version can also carry a free-form tag (a label plus an optional note) to mark releases or maintenance windows in the history. Tags are organisational only — they don’t affect drift.

The Configs list shows a derived status per tracked config. It is computed at read time in priority order (the first that applies wins):

Status	Meaning
Disabled	The config is disabled and is not collected.
Collector offline	A collector that serves this config’s addresses is offline.
Failing	The most recent scheduled collection failed (with a failure class — auth, transient or partial).
Drifted	The latest capture’s hash differs from the baseline’s.
Never collected	Nothing has been captured yet.
OK	Collected, and either matching the baseline or with no baseline set.

Open a config and pick a version on the Versions rail to see a side-by-side diff. By default a version is compared to the one before it; you can also compare against:

Compare mode	Diffs the selected version against…
Previous (default)	The capture immediately before it.
Baseline	The pinned baseline (shows the full drift).
Snapshot	Any other version you pick.

The diff renders as aligned side-by-side rows (and a unified view). Binary configs can’t be diffed — they’re offered as a download instead, versioned by hash.

This is what a standalone backup tool can’t do. Open the diff and choose View AAA activity: Taranac shows who touched that device in the window between the two versions being compared — (previous capture time → this capture time]. (For the very first version, it looks back 24 hours.) The drawer has three tabs:

Tab	Shows	Source
Authentication	Who logged in, from where, and whether it succeeded.	TACACS+ and RADIUS
Authorization	Which commands were run, permit/deny.	TACACS+ only
Accounting	Session start/stop and elapsed time.	TACACS+ and RADIUS

The honest limit: per-command attribution needs TACACS+ command authorization. A RADIUS-only device still gives you who-logged-in and session accounting — it just can’t tell you the individual commands, because RADIUS device administration doesn’t record them. (802.1X / MAB network-access sessions are excluded — this is device-admin activity only.)

Correlation is by device address: the activity is matched to the config’s addresses against the AAA logs’ NAS-IP. That’s a heuristic on the same network identity, so keep a tracked config’s addresses accurate for the attribution to line up. A user filter and per-tab counts let you narrow to one operator quickly.

Captures happen inside a collection run, listed under Configuration Tracker → Collection Runs:

• Scheduled — a leader-driven periodic sweep collects every enabled config; the sweep interval is the collection cadence (there’s no per-config schedule).
• On demand — an operator’s Collect now on a single config.

A run’s status is running, completed, or interrupted (an interrupted run is one whose lease expired mid-flight — e.g. an HA failover — and is never resumed). Each target in a run gets a per-device result: ok (first capture), changed, unchanged or failed.

The Collection Runs journal: scheduled sweeps and on-demand collects, each with its per-device tally of collected / changed / unchanged / failed. Failed results carry a failure class — auth (never retried, to avoid tripping device lockouts), transient (retried with backoff) or partial (holds the last-good). When a config’s scheduled collections fail repeatedly, Taranac escalates a collection-failed alert.

Prove nothing changed overnight. Sort the Configs list by status; anything not OK stands out. For a clean config, the version rail shows no new version since the baseline.

Investigate an unexpected change. Open the drifted config, diff the latest version against the baseline to see the full delta, then View AAA activity to see who logged in and what they ran in that window.

Roll back and record it. Restore the device to a known-good config out-of-band, then Collect now. The revert is captured as a new version (hash differs from the drifted latest), and pinning the restored version as the baseline clears the drift.

You want to…	Do this
See what changed between two captures	Side-by-side diff, Previous mode
See everything that drifted from known-good	Diff against Baseline
Compare two arbitrary versions	Diff in Snapshot mode
Find out who made a change	View AAA activity on the diff
Define what “correct” means for a device	Pin baseline on the good version
Force a fresh capture now	Collect now

Snapshot facts:

Field	Notes
Version	Per-config sequence number, oldest = v1.
Content hash	SHA-256 of the scrubbed body; drives de-dup and drift.
Content kind	text (stored inline) or binary (hash-only, no diff).
Captured at	When the snapshot was taken.
Attribution	The AAA-derived “who changed it,” computed at capture.
Raw body	Off by default; encrypted; revealable only with ncm_tracked_configs.reveal_raw.

Compare modes: prev (default) · baseline · snapshot. Run triggers: scheduled · on_demand. Run statuses: running · completed · interrupted. Per-device results: ok · changed · unchanged · failed (classes auth · transient · partial).

• Recipes & scrub sets — how a capture is cleaned before it becomes a snapshot.
• Credentials & the vault — the logins that make a collection possible.
• Change alerts & safe deletion — drift and collection-failed alerts.
• Audit & syslog — where reveals and other privileged actions are recorded.