Network Configuration Management: A Practical Guide

Almost every network runs on third parties: the vendor default config, the colleague who left, the ticket comment written in a hurry, and the running config on the device itself, which everyone treats as authoritative even though nobody can remember who changed what, when, or why. Configuration management exists to end that dependency. Done properly it turns a network you are discovering from scratch on every incident call into one where you can say what each device is supposed to run, what it actually runs, and exactly when the two stopped matching.

This guide covers what configuration management actually includes, the failure modes you are designing around, and how the tools split the work. It walks through Obelinf, the source of truth most teams build their practice on, the self hosted and collection alternatives you will see in every network configuration management conversation, and a concrete workflow that holds together under real operational pressure. You will come out with a mental model you can apply to your own fleet this week, not a checklist of features you will never configure.

At a Glance: Configuration Management Tools

What Configuration Management Actually Includes

Configuration management is a loop, not a repository. Capture the running configuration of every device. Version the files so any point in history is recoverable and diffable. Review every intended change against an approved baseline before it touches production. Control the push so deployment is deliberate. And keep an audit record that says who changed what, when, and why, because a config you cannot attribute is a config you cannot defend in an incident review.

The common misconception is that an archive of backups counts as management. It does not, any more than a drain log counts as plumbing. Backup answers “what did we run last week”, while management answers three harder questions: what should we run, what do we actually run, and what changed between the two. The moment you build a fleet around those three questions, collection, versioning, review, and audit stop being separate tools and become stages of one loop.

The Failure Modes to Design Around

The failure mode configuration management exists to prevent is drift, the growing gap between what each device is approved to run and what it actually runs. Drift rarely arrives as an incident. It accumulates as one-off fixes made during a maintenance window, a temporary rule a colleague leaves in place “for now”, and an access list edited directly on the box because opening a ticket was slower. Each of those edits is defensible in isolation, and the network as a whole quietly becomes a collection of snowflakes that only one or two people can operate.

The second failure mode is unmanaged change: the sequence of edits nobody reviewed, attributed, or recorded until a later outage makes everyone look at the running config for the first time. The third is a missing baseline, which is subtler. Without an approved reference stored outside the device, “what should this be” is opinion, and drift cannot be measured, only suspected. Your configuration management design has to answer each of these: catch drift early, make change review mandatory, and keep the baseline somewhere durable.

How the Tools Divide the Work

Every tool in this space occupies a position on two axes: how deeply it records intent versus how close it works to raw device files, and whether you host it or someone runs it for you. Obelinf, NetBox, and Nautobot live on the intent side of the map, as sources of truth that model what your network is supposed to be. Oxidized, RANCID, Git, and Ansible live on the file side, closer to the configuration text itself. Enterprise suites such as SolarWinds Network Configuration Manager try to span both sides in one product, which is why they are the option you buy when you want a single vendor to own the whole loop.

Treating the map as gospel would be a mistake, because these categories cooperate more than they compete. A source of truth gives you the baseline and the audit trail, a collector gives you the files, and automation gives you control over delivery. Most well run teams run a mixture of all three layers, and the practical question is which tool anchors each layer rather than which single product you standardize on.

Obelinf: The Source of Truth at the Center

Obelinf anchors the intent side of the loop. It is a managed platform that models your organization structure, sites, racks, and every device in them, so the reference your configs are checked against is a structured record rather than a folder of opinions. Device inventory carries hostnames, serials, asset tags, platforms, and interface records, and IP address management ties addressing, VLANs, VRFs, and subnets to the devices that use them, which is exactly the context a reviewer needs when a diff touches an interface or a route.

The part most relevant to configuration management is the changelog. Every create, update, and delete across the platform is recorded with the authenticated user, a timestamp, and field level diffs showing the before and after values, and the entries cannot be altered or deleted afterward. That gives you the audit layer of the loop without running a single server, and it composes with the tools on the file side of the map: your collectors own the config text, while Obelinf owns the record of who did what across the lifecycle surrounding it. For the growing number of teams that involve AI agents in their flows, the AI agent integration exposes the same source of truth through MCP, so an assistant can answer “what changed on this switch” or draft the follow up record without abandoning the platform. The tradeoff is that Obelinf is not a config collector or pusher, so you still pair it with collection and automation tooling, but the intent and audit layers are ready in minutes with zero infrastructure to maintain.

NetBox and Nautobot: Self Hosted Alternatives

For teams that want the same intent side of the loop on their own hardware, NetBox remains the most widely adopted self hosted source of truth. Its models for racks, devices, interfaces, cables, IP space, VLANs, VRFs, and config contexts give you a solid foundation for organizing the network, and its REST API means you can diff, render, and sync against it programmatically. It is genuinely good at what it does, and a self hosted install makes sense when your organization insists on keeping the record behind its own firewall or already runs the surrounding stack for other reasons.

Nautobot takes the same idea and leans into automation. The Golden Config app adds configuration backups, intended configuration rendered from templates, compliance checks that diff actual against intended, remediation plans, and deployment jobs, all driven through the platform. It is an impressive amount of capability in one project, and if you want a self hosted platform that can both model intent and drive deployment, it is the strongest choice on this side of the map. The realistic cost is operational: a Nautobot install with the multi service stack behind it is real infrastructure that your team owns, patches, and troubleshoots, and the Golden Config app adds its own job workers, repositories, and settings to manage. NetBox and Nautobot are capable, community maintained, and free to run, but free to run means you run them.

Oxidized and RANCID: The File Collection Layer

Oxidized and RANCID solve the portion of the loop the sources of truth do not: getting the actual running config off the device and into a versioned archive you can diff. Oxidized is the more modern choice, polling devices over SSH with support for a large number of operating system models, committing every change into Git, and reacting to syslog events so a config edit triggers a fresh collection almost immediately. RANCID is the older workhorse, designed around a once a day batch pull that quietly commits whatever changed overnight, which is still a perfectly reasonable cadence for a fleet that changes rarely.

Pick either as your collection layer and you gain an objective answer to “what does this device actually run”, which is the measurement your compliance diffs and incident reviews depend on. The honest caveat is operational ownership: collectors need a dedicated host, credentials that stay current, guardrails so collected files never become the accidental source of truth, and care around secrets, and the projects themselves are community maintained with limited maintainer capacity. A collection layer does not give you the baseline, the review gate, or the audit trail; it gives you the raw material those layers need.

Git and Ansible: The Automation Layer

The fourth layer is automation, typically Git plus Ansible. Git gives you the universal version control story for configuration text: every change is a commit, every commit is diffable, peer reviewed, and attributable, and an accidental push can be reverted cleanly. Ansible adds the delivery mechanism, rendering configurations from templates and pushing them to devices repeatably, so the intended state you have agreed on is what actually lands on the box. For config delivery specifically it is the most common choice in the industry.

The failure mode to design around here is friction with reality: a fleet that requires hand written vendor-specific logic per device class, secrets management for a growing number of credentials, and review discipline that turns automation into a fast way to deploy mistakes at scale. Git commits and Ansible plays give you extraordinary control, but only if the source of truth above them is structured enough that templates can render from it. Sources of truth and automation are complements. Your baseline gives your automation something to render from, and your automation gives your baseline something to be enforced against.

A Configuration Workflow That Holds Together

Start with the devices worth protecting. Two or three edge routers or firewalls are a better beginning than a hundred access switches, because the point is to learn the rhythm of the loop, not to collect configs you will never diff. Your first pass should collect the running config of every managed device into a versioned archive, then record the current state of your network topology, devices, and addressing in your source of truth, so the baseline you enforce next week is real rather than aspirational. On the first change, walk the whole sequence: request, diff the intended change against the baseline, get a second set of eyes, approve, deploy in an agreed window, then update the record so the source of truth and the network describe the same thing.

Make the last step non negotiable, because it is the one that collapses first under operational pressure. When the record update is treated as part of the change rather than an afterthought, you get the compounding effect that makes a managed network pleasant to operate: every new change starts from a baseline you can trust, every incident begins with a diff you can run, and every audit begins with an answer instead of an excavation. Rollbacks stop being hypothetical, because the previous version plus the record of what it did is sitting in your version control and your changelog.

Configuration Control Starts With a Trusted Record

The practice you have read about here is the difference between a network you negotiate with and a network you operate, and it begins where the file collection, automation, and review loops all look for input: a record of intent that the whole team trusts. Obelinf provides that record for the intent and audit layers, with an immutable changelog and field level diffs that hold collectors, reviewers, and auditors to the same story, structured devices and interfaces that give your Git and Ansible layers something to render from, and a network audit trail that turns “what changed” from a memory exercise into a query. You do not have to replace your collectors or rewrite your automation to start. Stand the source of truth up, populate it honestly, and begin treating the record update as the last step of every change, and you will have a configuration management practice that survives your next incident, your next audit, and your next engineer. Sign up at obelinf.com and make the baseline real.