In brief

  • RANCID — Really Awesome New Cisco confIg Differ — regularly collects configurations through vendor-specific login scripts and modules, normalises the output and stores changes in CVS, Subversion or Git.
  • Its material is observed text, not desired state: a snapshot may reveal drift or an urgent change, but miss intermediate actions, runtime state and the identity of the person responsible.
  • A host that improves incident investigation becomes a high-value target because it concentrates management credentials, topology and configuration secrets for the entire fleet.
  • RANCID remains useful alongside GitOps, automation and source-of-truth systems because an independent collector can show what a device actually reported after the standard process was bypassed or only partly completed.

After an outage, the smallest useful question is often ‘what changed?’

A network can fail because of a complex interaction between routing policy, interface state, software faults and load. Yet the first practical clue is often a single line: a neighbour address changed, an ACL was moved, a match was added to a route-map, or a trunk lost a VLAN. The device accepted the command, while the consequences emerged later and perhaps far from the point of change.

RANCID was built to preserve such a clue. It connects to routers, switches and other supported devices, runs commands, filters the output and commits the resulting text to version control. When a file changes, the repository shows a diff and can send an email or trigger another workflow. The system does not need to understand the full business objective to record that the device now reports different text.

The modesty of the model is a strength. RANCID does not claim to be a complete control plane. It does not schedule maintenance windows, generate every configuration or guarantee compliance. It makes periodic observations. That makes it useful in a mixed estate, where some devices are automated, others are managed manually and others are too old for a modern API.

The model is incomplete by design. A change may be applied and reversed between two collections. A login failure may leave an old file looking current. A vendor module may fail to request the decisive command. Normalisation may remove a value that later proves important. A diff proves only the difference in text seen by the collector; it does not prove who changed the device, why they did so or whether the change caused the outage.

These boundaries do not diminish the value of the evidence; they define it precisely. RANCID provides a durable, low-complexity answer to one limited question. During an incident, that can be more useful than a broad dashboard of symptoms with no configuration context.

The project gave routers an external memory before controllers became fashionable

RANCID emerged when network equipment was managed mainly through the CLI. Configuration lived on routers and switches, while operational knowledge lived in engineers’ memories, terminal histories and personal directories. A device replacement or an erroneous command could reveal that the organisation had no independent, current copy.

The name began with Cisco, but coverage expanded through vendor modules. The architecture accepted an awkward fact: prompts, login sequences, paging behaviour and commands differ. Rather than wait for a single model, RANCID automated the interfaces that existed in practice.

clogin, working through Expect, can recognise prompts, conduct a session, enter privileged mode and run commands. A module retrieves the running configuration, inventory or other state; the output is then normalised and stored as text.

The approach is as fragile as any CLI automation. A new prompt breaks a script. Firmware changes the output. Banners, paging, authentication and timing differ. Some devices require Telnet or obsolete cipher suites. Local modules may diverge from upstream.

Its longevity shows that compatibility often comes through adaptation rather than an ideal standard. RANCID does not make CLIs uniform; it creates a common process over their differences. The repository becomes the stable interface. Crucially, the memory leaves the device: even if a router fails completely, its last configuration and history remain.

router.dbturns an estate into a scheduled collection plan

The traditional process begins withrouter.db, which associates hostnames, types and states. Active entries become targets. Groups define schedules, repositories and areas of responsibility. The file is easy to review and place under version control, but it determines which devices will be remembered and which will remain invisible.

Its simplicity makes mistakes readable: a typo in a name, the wrong type or a disabled state. But it does not guarantee completeness. A missing router is not discovered automatically. A decommissioned device may remain. A name may resolve to an unexpected address. The list must be checked against an asset register or source of truth.

Whenrancid-runstarts, it selects active targets, invokes login and vendor-specific logic, retrieves the output, compares it and commits meaningful changes. Errors and retries are part of the service. A device may be unreachable, authentication may fail or a command may return incomplete data. Every run needs a status; the presence of a file does not prove that it is fresh.

A stale copy may look clean and convincing. The operator needs the time of the last successful collection, the number of consecutive failures and confirmation that all expected commands ran. An archive without freshness monitoring creates false confidence.

Groups make it possible to limit the blast radius. Different environments use different credentials, frequencies and repositories; critical devices can be collected more often or from isolated hosts. Butrouter.dbis not a source of intent; it is a collection plan. Comparison with NetBox, Nautobot or an asset register reveals devices with no history and forgotten parts of the estate.

Expect-based login made automation possible and concentrated secrets

Interactive CLIs were designed for people. They display banners, request a username and password, negotiate terminal settings, pause output and change the prompt by mode. Expect waits for a pattern and responds, turning the dialogue into an automated sequence.

RANCID uses this model. Its tools open Telnet or SSH connections, handle prompts, enter privileged mode and run commands. This is how equipment was automated long before model-driven APIs.

The mechanism creates a serious concentration of risk. A collector may need access to hundreds or thousands of devices. Credentials are often described in.cloginrcand protected by file-system permissions. Compromise of the host or file gives an attacker a map of the estate and credentials for the management plane. Shared and privileged accounts broaden the consequences.

Even ‘read only’ depends on the platform. Some devices do not separate configuration display cleanly from broader commands. The repository may contain community strings, hashes, keys, customer names and internal addresses. Filtering helps, but does not guarantee the absence of secrets.

The RANCID host should be treated as a privileged system: segmented, patched, backed up and monitored. Accounts should be restricted, rotated and audited. SSH should replace Telnet wherever possible. Old algorithms should be isolated rather than enabled on a general-purpose management host. Repository access should follow the principle of least privilege.

Vendor modules translate unstable output into comparable text

RANCID does not retrieve an abstract, universal configuration. It runs commands for a specific platform, reads the output and applies parsing and filters. The module knows what to request, which lines to retain, how to handle modes and how to order the result.

This knowledge is an operational asset. Platforms use different terms for interfaces, inventory, software and route tables. Some print uptime, timestamps and counters. A module turns that diversity into files stable enough for a useful diff.

The translation can fail silently. A new release moves a line, changes a header or requires a different privilege level. The parser continues to run but loses a section. Success should therefore include content tests, not only an exit code.

Supporting modules requires access to equipment, sample outputs and knowledge of versions. Local forks solve a problem quickly and make updates harder. An organisation should know its patches, compare them with upstream and test firmware before production use.

Normalisation separates meaningful change from run-to-run noise

CLI output contains values that change without any configuration change: uptime, the date, counters, session IDs, encrypted hashes and line order. If everything is stored, every run produces a diff and the signal is lost.

RANCID removes or masks some of these values and stabilises the order. The repository shows changes to policy, an interface or access settings instead of a refreshed counter. This is why a simple diff can remain useful for years.

But normalisation is an editorial decision expressed in code. Too little filtering creates constant alerts; too much hides evidence that may matter to an incident or audit. A volatile value may become important when investigating a reboot or key rotation.

An operator should understand what the module filters. Filter changes should be treated as changes to the evidence format because they alter the evidence retained. For especially critical devices, separately protected unfiltered output can be kept alongside a normalised version for comparison.

Version control creates a chronology of text, not a transaction log

CVS, Subversion or Git retain versions, diffs and commit times. The archive shows how the observed text evolved and makes transfer, replication and review straightforward.

A commit is not a transaction on the router. Its author is usually a service account, not the person who entered the command. The time is that of collection or commit, not necessarily the change. Several commands may appear in one diff, while intermediate changes are absent.

The chronology must therefore be correlated with AAA, syslog, tickets, automation workflows and device events. The repository provides an independent but incomplete timeline. Its strength is retained text; its boundary is the lack of intent and transactional identity.

Git does not automatically strengthen the evidence if history can be rewritten, clocks are wrong or commits are not replicated. Retention, branch protection, signatures and immutable copies can increase assurance.

Periodic collection leaves a window in which the decisive change can disappear

RANCID observes snapshots. Between two runs, a person or automation may change a device, trigger an incident and roll back. The repository will show two identical states and miss the key event.

Reducing the interval narrows the window, but increases sessions, load, commits and overlapping jobs. Some devices cope poorly with frequent CLI queries. Large estates need scheduling and concurrency limits.

A fuller picture requires AAA, syslog, orchestration logs, intent commits, telemetry or command accounting. RANCID remains useful as a periodic, independent check.

Freshness must be visible. Each device should have an acceptable age and an alarm after repeated failures. A six-month-old copy is not false; it is evidence from a different moment. The interface must not present it as the current state.

A RANCID host can expose the entire management plane

The collector accumulates credentials, names, addresses, descriptions, configurations and device types. A compromise gives an attacker both a map and a means of access.

The repository may contain secrets even after filtering: community strings, hashes, keys, tunnel addresses, customer data and policies. Backups, Git mirrors and emails containing diffs multiply the copies. Every store becomes part of the control surface.

Protection must cover the entire path: a hardened host, management-network segmentation, read-only accounts, permissions on.cloginrc, encrypted and restricted backups, protected email, access logging and rotation. Interactive access should be rare and attributable.

There must be a plan for collector compromise. Reinstallation is not enough: every affected credential must be identified and rotated, copies located and sessions investigated. Centralisation improves day-to-day audit and increases the potential scale of an incident.

LibreNMS shows the symptom; RANCID adds configuration context

LibreNMS can report a port going down, a lost neighbour or rising error counts. RANCID shows a change in the related configuration. Together they accelerate diagnosis without turning correlation into causation.

The tools run on different schedules and may miss events. A hardware failure does not necessarily produce a diff; a diff may have no effect. Times must be aligned, freshness checked and logs or tickets added.

Integration should preserve provenance. A dashboard should not show a diff without the date and collection status. The archive should not claim to explain a symptom it did not measure. Together they provide a fuller account: what happened and what the device was reporting around that time.

GitOps and sources of truth describe intent; RANCID records the device’s answer

Modern systems model inventory, addresses, services and policies in authoritative data, generate configuration and apply changes through review and tests.

Afterwards, or in parallel, RANCID reads what the device actually reports. It confirms that intent was applied, reveals manual drift or shows that a vendor operating system normalised a command differently.

It is dangerous to make a collected configuration the new intent automatically. The observed drift may itself be the error. A robust process compares intent and observation, explains the difference and decides which side to correct.

The collector’s independence has control value. If the orchestrator, intent repository and device share the same error, a separate reading may reveal the state. But independence must be genuine: shared credentials, parsing logic or administrators create shared failure modes.

Oxidized and commercial managers modernise the workflow but do not remove the original task

Oxidized offers a newer architecture, an API and integrations. Commercial suites add support, compliance, orchestration and data models. They may simplify operations and provide contractual support.

No option removes the need to obtain evidence of what a device reports. They merely distribute effort differently among code, licensing, support and operations. Migration should be assessed by coverage, secrets, freshness, filters and retention, not only by how modern the interface looks.

RANCID may continue to serve legacy hardware while another tool takes on newer platforms. Temporary coexistence is safer than a cutover that loses years of history. It should be clear which tool is responsible for each device and how differences are reconciled.

Email diffs turn the repository into a human workflow

Email long served as the signalling layer. A change generates a diff for a list or team, placing the evidence in a familiar channel and enabling shared review.

The workflow can become noisy. Poor normalisation, verbose firmware or large-scale changes create a flood of messages that people stop reading. Lists may include unnecessary recipients, and email leaves sensitive copies outside the repository.

It should be defined which groups receive which devices, how messages are classified, how an expected change is linked to a ticket and what response an unexpected change requires. An unread diff is not a control.

Ticketing, chat and automation workflows can replace or supplement email, but the logic is the same: a textual change becomes a human decision. Automation can add age, change window and criticality without determining legitimacy on its own.

Looking glass shows that even read access needs boundaries

RANCID was historically associated with looking-glass functions that ran limited diagnostic commands. The idea is useful: provide visibility without full CLI access.

But ‘read only’ does not mean ‘risk-free’. Commands reveal topology, routes, policy, internal names and business relationships. Poorly validated input may permit unexpected commands. A heavy query loads the router. Results may be distributed too widely.

The interface should strictly restrict commands, parameters, targets and frequency, log usage and, where possible, use separate credentials. The information returned should suit the audience.

The wider lesson is that the management plane contains sensitive data even without the right to change it. Observation requires governance just as write access does.

Resilience rests on a small canonical project and many invisible installations

At the reporting cut-off, the canonical Shrubbery Networks site still listed RANCID 3.14 as current, while the 3.14 line was dated 2025. GitHub mirrors and distribution packages exist, but they do not replace the canonical source for status.

There is no audited installation count, budget or complete list of maintainers. Much of the value is invisible: old internal installations, local adaptations and packages whose users do not participate publicly.

That invisibility complicates assessments of influence and succession. Mature software can operate for a long time with few changes, but SSH, operating systems and CLI output continue to evolve. Critical knowledge may be concentrated among a few people.

Users should monitor versions, site activity, distribution patches, responses to reports, the condition of their own modules and their ability to migrate. Quiet does not equal abandonment, but it should not be treated as a guarantee without verification.

Migration must preserve the evidence, not merely replace the collector

Repositories may contain years of configurations, diffs, comments and timestamps. Starting afresh breaks the chronology precisely when it may be needed during an incident.

A migration must define the storage format, how old devices will be found, how names and identities are matched, and how old and new commits are separated. Timestamps and branches must be verified.

A parallel run on a sample is useful. Differences reveal missing commands, different filters and divergence in parsing. Success means not only connecting, but preserving equivalent evidence coverage and making errors visible.

Credentials should be rotated rather than copied blindly. Old hosts, backups, mailing lists and repositories should be demonstrably retired. Secrets left behind increase risk.

Configuration text is not the same as network behaviour

A file may look correct while forwarding is broken. A command may have been partly rejected, rewritten, overridden by dynamic state or neutralised by hardware. The RIB, FIB, sessions, queues and physical state cannot be reduced to text.

Some modules collect operational output, but the main artefact is a textual snapshot. Understanding behaviour requires reachability tests, telemetry, protocol state and active probes.

The reverse is also true: behaviour may appear normal while a dangerous configuration waits for the next failure. This is why a diff matters—it shows structural change before or after a symptom.

Correct interpretation links intent, observed configuration and runtime without conflating them. Each is a separate clue. An investigation explains the matches and gaps.

Audit value depends on provenance, retention and an explainable collector

For a repository to support an audit, it must be possible to explain how the data was obtained, which account and commands were used, how often collection ran, what filters were applied and what errors occurred. Without provenance, a set of files does not establish coverage.

Retention must be defined. Old devices and configurations may be needed for investigations or requirements, but they increase the risk associated with secrets and customer data. Branches, backups and email should follow an agreed policy.

Immutable copies, access control, independent logs and hashes improve integrity. They do not make the archive infallible, but they make undetected alteration harder and clarify the chain of custody.

The collector must also be documented: its version, local modules, normalisation changes and health. Otherwise, files may differ because the parser changed rather than the device. An audit must distinguish between the two.

Legacy equipment preserves the need for narrow compatibility

Networks keep devices longer than modern tooling cycles last. Some have no gNMI, reliable NETCONF or API. They continue to communicate through the CLI and sometimes use old cryptography. While they carry traffic, their state must be preserved.

RANCID fills this niche with narrow modules. That does not justify operating vulnerable hardware indefinitely. On the contrary, the tool should expose the debt: Telnet, weak algorithms, shared accounts and unmaintained modules.

Isolation is critical. The requirements of an old device should not weaken the general management host. Separate collectors, jump hosts and segmentation limit the risk until replacement.

Narrow compatibility becomes a transition mechanism: it preserves evidence and operations while an exit is planned, rather than serving as an argument against replacement.

In many estates, newer devices provide structured telemetry while older ones remain limited to CLI and SNMP. RANCID preserves evidence for the second group without turning compatibility into a claim about the equipment’s safety or long-term suitability.

A narrow tool can outlive several waves of management

RANCID has lived through NMS, SDN, intent-based networking, infrastructure as code and GitOps. It survived not by promising to replace them, but by retaining a limited function: retrieve text and show the change.

A narrow function is easy to explain, test and migrate. It reduces dependence on proprietary models. Text and diffs can be read with ordinary tools, lowering the cost of continuity.

Simplicity becomes a weakness if new platforms, security or succession are not supported. Past longevity does not guarantee the future. Every organisation must verify its own coverage and exit plan.

The lesson is not that simple is always better, but that an essential function should remain portable and understandable when the larger platform changes.

A textual diff matters because it is bounded, verifiable evidence

RANCID’s main strength is that it does not require trust in an opaque model. A file shows the text received; a diff shows added, removed and changed lines; the history shows sequential observations. An engineer can inspect all of it with ordinary tools.

Readability shortens the distance between collection and judgement. A filter can be challenged, an anomaly seen and an old configuration restored. The format is portable beyond the product. Even if RANCID disappears, the repository survives.

The evidence is bounded by the command set, the moment, the parser and access. It does not show everything. An explicit boundary is healthier than a dashboard that combines observation, calculation and conclusion without clear provenance.

Strategic value appears when it is independent of intent. An organisation can have a modern automation workflow and retain RANCID as a witness. A manual change, an orchestrator failure or a vendor discrepancy then has a point of comparison.

The cost is real: credentials, modules, storage, error handling and exposure of secrets. The question is not whether a diff is old-fashioned, but whether its investigative value exceeds the cost and whether the controls match the risk.

The final test is simple. After the next incident, can the team identify the last observed change and the time of the last successful collection, explain gaps in the module, and relate the diff to intent and events? If so, a tool from the CLI era remains useful infrastructure for organisational knowledge.