Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection
Configuration Drift · Change Control · Recovery

Your Running Config Is Not the Config You Think You Have

Somebody fixed something at 2am. They edited a file on the box, the incident closed, and nobody wrote it down. Multiply that by every engineer, every incident and every year the network has been running, and the gap between what you believe is deployed and what is actually on each machine becomes the thing you discover during the next reboot — at the worst possible moment.
Nearly every operator can detect drift. Very few can answer the next two questions: what exactly changed, and how do I put it back?
Per file
expected content recorded,
not just a change flag
Diff
first
see the difference before
anything is written
One
click
put the recorded version
back on the box
Unsaved
changes not yet written to
flash, counted and shown

Drift is not a sign of a badly run network. It is the natural residue of operating one: an emergency fix, a vendor's recommended workaround, a value tuned during a capacity crunch. The problem is not that it happens — it is that on most platforms drift is invisible between reboots. The box works, so nobody looks, and the divergence quietly accumulates until something restarts and comes back behaving differently to the way it did the day before.

What drift looks like when you can finally see it

Configuration Overview listing seventeen drifted configuration files on one gateway, each with the number of times it has drifted, when it was last detected, and a Review and restore action. The sidebar shows twelve changes not yet saved to flash.
One gateway. Every tracked file that has diverged from its recorded content, how many times it has done so, when it was last seen, and an action per row. Note the sidebar: twelve changes on this node have not yet been written to flash. Hostname and file paths are obscured; the drift counts, ages and unsaved total are real.

Two details in that list matter more than the headline count. One data-plane configuration file has drifted 44 times — that is not an accident, that is a file somebody edits routinely and never records, and it deserves a template rather than a repair. And an access-control file appears among the drifted paths: drift is not only a service-availability question, it is a security one. A file governing who can log in to a gateway had changed, and until it showed up in this list, nothing said so.

Repeat count changes the response. A path that drifted once is an incident to review. A path that has drifted forty-four times is a process problem — somebody is fighting the platform, and the fix is to make the intended value part of the template, not to keep pushing it back.

How it works

recorded what it should be 2am fix on the box never written down divergence detected + counted ELSEWHERE — THE STORY ENDS HERE invisible until something reboots SEE THE DIFFERENCE recorded vs live, side by side restore the recorded version logged, and only if it differs
Detection alone is common. The lower branch — showing the difference and putting the file back, as a recorded action — is the part that turns drift from an observation into something an operator can close.

It refuses to act when there is nothing to act on

A review and restore dialog for a configuration file, reporting that live content already matches this snapshot so there is nothing to restore, with the restore button disabled.
The same file, opened for restore a week after its drift was recorded. The live content had since returned to match, so the tool says exactly that and disables the action.

This matters more than it looks. A restore tool that always appears willing to write is a tool that will eventually overwrite a deliberate change with an old snapshot, during an incident, because somebody clicked the obvious button. Checking live content against the snapshot before offering the action is the difference between a recovery tool and a new source of outages.

The compounding risk nobody watches. On a gateway, applied and persisted are not the same thing. A change can be live and working while never having been written to flash — until an unplanned reboot returns the node to a state nobody has a record of. Drift tells you the running config diverged from your records; the unsaved counter tells you the running config will not survive a power cut. Together they are the two halves of "we do not actually know what this machine will boot into."

What most platforms give you instead

Nothing here is a claim that other systems cannot detect a changed file — many can, and configuration-management suites do it well. The gap is in what happens next, and in how much of the workflow the operator has to assemble.

The operator asks Typical chassis / router workflow
Cisco ASR 9000 · Nokia 7750 SR · MikroTik RouterOS		 BNGSOFT
"Has anything changed?" Config archive or an external management tool, if deployed and if the diff job runs. Frequently a scheduled export nobody reads. Per-file divergence, detected continuously, shown on the node's own page.
"How often has this file changed?" Derivable from archive history by someone willing to go looking. A repeat count per path, so a routine offender is obvious at a glance.
"What exactly is different?" Diff two archived versions — usually the whole configuration, not the one file in question. Recorded snapshot against live content, for that path, before any action.
"Put it back." Paste from archive, or a full-config replace with the risk that implies. Often deferred to a maintenance window. Restore that one file from its snapshot, verified different first, and logged.
"Will it survive a reboot?" Depends on whether someone remembered to save. There is usually nothing counting the gap. Unsaved changes counted and shown next to the save action itself.
The honest version of the claim. A well-run network with a mature configuration-management practice already solves much of this — with tooling the operator selected, integrated and maintains. What we ship is the same outcome without that project: drift, diff, restore and persistence all on the page for the node you are already looking at.

Why it is worth doing before you need it

Reboot
The moment drift becomes an outage
  • A node that has run for months on undocumented edits
  • Restarts, loads what was persisted
  • Comes back subtly different — and nobody knows which of forty files moved
Replacement
Rebuilding what you cannot describe
  • Hardware fails, a node is replaced
  • The rebuild matches your records
  • Your records were never the thing that was actually running
Audit
Proving what was in force
  • Access files drift too
  • "Who changed this, and when" is a question with a deadline attached
  • A per-file history answers it

Drift is not glamorous and it does not page anyone. It simply sits there, growing, until the day a node restarts and the network behaves in a way that nobody can explain from the documentation. The work of closing it is small — and almost always done after the outage that made it urgent.

Trademarks and non-affiliation. Cisco, IOS XR and ASR are trademarks or registered trademarks of Cisco Systems, Inc. Nokia and 7750 SR are trademarks or registered trademarks of Nokia Corporation. MikroTik and RouterOS are trademarks of Mikrotikls SIA. BNGSOFT is not affiliated with, endorsed by or sponsored by any of them, and names are used for identification and comparison only. The comparison above describes typical operator workflow rather than any specific release or feature set — capabilities vary by version, licence and deployment, and the vendors' own documentation is the authority on what their products do. Figures and screenshots are taken from a production deployment; identifiers are obscured.