21.8 Configuration Management

Introduction

Configuration management is the practice of defining, tracking, and controlling the state of network devices and systems over time. Instead of changing routers, switches, firewalls, and servers by hand, you describe how they should look in files, store those files in version control, and let tools apply and maintain that desired state for you.

For networking, configuration management becomes the backbone of repeatable, auditable, and scalable operations. It connects directly to automation, APIs, and tools such as Ansible and Terraform, which appear in other chapters, but here the focus is on the concept and process of managing configuration itself.

Desired State vs Actual State

At the heart of configuration management is a simple idea. There is how your network should be, and there is how your network actually is at any moment.

The "desired state" is the target configuration you define. It captures which protocols are enabled, which VLANs exist, which IP addresses are assigned, which ACLs are installed, and so on. This desired state is usually written as text, such as YAML, JSON, templates, or device specific configuration syntax.

The "actual state" is what the devices are truly running right now. This is the live configuration that you would see if you logged in and displayed the current settings. Configuration management tools compare these two states and then push changes that move devices from the actual state toward the desired state.

When engineers make quick manual changes on devices without updating the desired state, the two get out of sync. This is called configuration drift and it undermines the entire process.

Configuration as Code

Configuration management for networks increasingly uses the idea of "configuration as code." Instead of treating configuration as something you type manually in a terminal, you treat it like software source code.

Configuration as code has several key properties. First, configurations are stored in files, not just in devices. Second, these files live in a version control system, usually Git. Third, changes follow a workflow with reviews, approvals, and testing. Finally, tools read these files and automatically apply them to the network.

Version control brings several benefits. You can see who changed what and when. You can compare two versions of configuration side by side. You can roll back to a previous known good state if a new change breaks something. You can branch and test changes in a lab before merging them into the main configuration.

A typical configuration as code repository for networking might include templates, variables, device inventories, and generated configuration outputs. Even if later chapters introduce specific tools, the idea remains the same. The repository is where the truth about your network design and policies lives.

Idempotence and Repeated Runs

Configuration management tools typically aim to be idempotent. This means that if you apply the same configuration description many times, the result on the device stays the same after the first time.

For networking, idempotence matters because you often run automation jobs on schedules or in response to events. You want to be able to run them repeatedly without accidentally adding duplicate lines, creating conflicting settings, or causing outages.

Imagine a configuration management task that ensures a VLAN is present on a switch. An idempotent task will check whether the VLAN already exists. If it is missing, it will create it. If it already exists, the tool does nothing for that VLAN. The device remains in the correct state, and nothing is broken by running the same task again.

When network tasks are not idempotent, repeated automation runs can add many duplicate ACL entries, multiple routes, or repeated lines in an interface configuration. This can make troubleshooting harder and can even break connectivity.

Push vs Pull Models

Configuration management systems typically use either a push or a pull model to apply changes. Both approaches can be used in networks, and some environments mix them.

In a push model, a central system initiates configuration changes and sends them to devices. Network automation platforms that connect to devices and push configuration lines or structured data into them follow this style. Engineers start the job on the central system, and devices receive changes.

In a pull model, each device periodically connects to a central server and asks for configuration or state. If the server has new desired state, the device pulls it, applies it, and reports back. This is common in some operating system configuration tools and is starting to appear in certain networking stacks that support agents.

A simple comparison is useful.

The choice between push and pull affects how you design automation, security policies, and failure handling. For example, if your central push server is down, you cannot send new changes. If you use pull and the device cannot reach the controller, it may continue with the last known configuration until connectivity returns.

Templating and Standardization

Configuration management for networks depends heavily on templates and reusable patterns. Instead of writing full device configurations from scratch for each router or switch, you define common building blocks and then fill in only what changes between devices.

A template might describe the layout of an access switch configuration. It could include interface defaults, logging settings, management VLANs, and SNMP. Variables in the template, such as the hostname or local IP addresses, can be filled in from an inventory file or other data source.

Using templates gives several benefits. Configurations across devices become consistent. It is easier to roll out updates across hundreds of devices by changing a single template file. There is less chance of typing errors or copy and paste mistakes. You can also test and validate templates before using them in production.

A small illustration of the idea can help. In many tools you might see something similar to this pattern.

In practice, templating is not limited to device configurations. You can also template routing policies, firewall rules, monitoring configuration, and documentation that refers to IP schemes and VLAN numbers.

Detecting and Managing Configuration Drift

Configuration drift happens when device configurations slowly move away from the defined desired state without going through the standard configuration management process. This often occurs because of ad hoc manual changes during troubleshooting or emergency fixes that do not get recorded in the configuration repository.

Drift introduces risk. Documentation no longer matches reality. Security rules may be missing or different than expected. Team members lose confidence that the automation will be safe to run, since they cannot predict its effect on a device that has drifted.

Configuration management aims to detect and correct drift. Tools can regularly fetch current device configurations and compare them with the stored desired configurations. Differences can be flagged, reported, or even automatically corrected, depending on how strict the policy is.

Some teams choose a gentle approach where drift is reported but not fixed automatically. Others run regular jobs that reapply the desired configurations and override any unauthorized changes. The right choice depends on the environment, culture, and risk tolerance.

By treating manual changes as exceptions that must be captured later, you prevent the desired state from becoming stale and losing its authority.

Versioning, Review, and Change Control

Configuration management is closely tied to change management processes in networks. Because configurations are stored in version control, every change becomes a clear, trackable event. This supports reviews, approvals, and auditing.

A typical workflow might look like this. An engineer creates a change in a separate branch or working copy of the configuration repository. They adjust templates or variables for the devices that need to be updated. A peer then reviews the proposed change. They look at exactly which lines have been added, modified, or removed. They check whether the change is safe, aligns with design standards, and follows security policies. When satisfied, they approve the change, which merges into the main branch.

After approval, an automation job or pipeline applies the new desired state to the network. Timing may be controlled by maintenance windows. Logs will show which configuration version was applied, on which devices, and at what time.

If a problem appears, the previous version can be restored. Because configuration is treated like code, you can revert to an earlier commit. The automation then re applies that version, bringing devices back to a known good configuration.

Using this workflow, configuration management provides more than just automation. It provides a historical record and a safety net.

Compliance and Policy Enforcement

Networks often have compliance requirements. These might come from internal standards or from external regulations. Configuration management helps enforce these requirements consistently across devices.

Instead of manually checking each device to confirm that secure management settings are enabled, you define those settings in the desired state. Tools then ensure that every device has them. They can also verify that particular commands never appear, such as insecure protocols, or that required commands are always present.

Compliance checks can be integrated into the configuration workflow. For example, when a proposed change is created, automated tests can run to validate that the resulting configurations still meet security and design rules. If a change violates a rule, the system can block it or flag it for review.

Some setups maintain separate "policy as code" that lives beside configuration templates. These policies describe acceptable patterns and forbidden patterns. Configuration management tools can test configurations against these policies before deployment.

This approach turns network compliance from a manual inspection task into a continuous process built into daily operations.

Integrating Configuration Management with Networking Tools

Although details of specific automation tools appear in other chapters, it is helpful to see where configuration management fits into the bigger networking picture.

Configuration management systems often talk directly to devices through network APIs or management protocols. Many network operating systems now expose structured APIs that allow tools to retrieve and push configuration data without simulating manual command line interactions. This makes automated configuration more reliable and predictable.

Configuration management also interacts with inventory and source of truth systems. Rather than hard coding device details and IP addresses inside templates, these are stored in a dedicated database or inventory file. The configuration management engine reads this data and uses it to fill in templates. This reduces duplication and increases accuracy.

Monitoring and logging systems can be linked as well. When a configuration change is applied, events can be sent so that monitoring systems adjust their expectations. This avoids false alarms when known changes occur. Logs from devices can be correlated with configuration versions so that performance changes can be understood in terms of which configuration was active at the time.

As networks adopt more virtualization and cloud technologies, configuration management extends beyond physical devices into virtual routers, virtual firewalls, container networking policies, and cloud networking constructs. The same principles apply. Desired state is stored and managed as code, with tools ensuring that actual state follows.

Practical Strategies for Getting Started

For beginners, configuration management can seem like a big leap from manual CLI work. A gradual approach is usually best, focusing on a few practical steps that introduce the main ideas without changing everything at once.

One common starting point is to use configuration backup tools that regularly pull device configurations and store them in version control. This immediately gives historical versions and helps detect unexpected changes. Over time, some of these stored configurations can be turned into templates.

Another step is to standardize certain parts of the network where configurations are very repetitive, such as access switches or branch routers. Templates are easier to design in these environments and bring quick benefits. Later, more complex or unique parts of the network can be brought under configuration management.

It is also important to involve people and process, not only tools. Teams should agree on how changes are proposed, reviewed, and deployed. They should document how emergency fixes are handled. Training and practice in reading and understanding configuration diffs is essential, since this becomes the primary way to see what is changing.

Over time, as confidence grows, more of the network can be managed entirely through configuration as code, with less and less direct manual editing on devices. This progression reduces the risk of human error and builds a more controllable and understandable network environment.

Summary

Configuration management in networking is about controlling the life cycle of device and system configurations through defined desired state, versioning, and automation. It treats configuration as code, uses idempotent operations, and aims to prevent configuration drift. Templates and standardization reduce complexity and errors. Version control and review workflows provide safety, traceability, and the ability to roll back.

By integrating configuration management with inventory, monitoring, and automation tools, network engineers gain a powerful framework for building networks that are not only functional, but also repeatable, auditable, and easier to evolve over time.