What is network configuration management?

Network configuration management, often shortened to NCM, is the practice of knowing exactly how every router, switch and firewall is configured, keeping a history of every change, checking configurations against the rules they must follow, and changing them in a controlled way. Tools that do this are called NCM tools, but the practice matters more than the tool: it is configuration management, applied to devices that rarely have a package manager or a deployment pipeline of their own.

Why it matters

Networks break most often when someone changes them. A mistyped access list, a route map applied to the wrong neighbor or a forgotten no shutdown can take down more than any hardware failure, and the first question in most network incidents is "what changed?".

Configuration management answers that question, and three others: what is each device running right now, does that meet our standards, and can we change it safely? Auditors ask the same questions, which is why security frameworks treat configuration management as a control of its own; NIST's SP 800-128 is a detailed guide to it.

What it covers

Inventory. A list of the managed devices, with their platform, operating system version and how to reach them.

Backups and history. Regular copies of each device's running configuration, kept as versions, so you can see what a device ran last Tuesday and diff it against today.

Drift. The gap between the configuration a device should run and the one it does. Drift often starts as an emergency fix made at the console and never written down.

Compliance. Rules every configuration must meet, such as SSH only, no default SNMP communities, logging to a central server, and reports on which devices fail them.

Change management. Changes proposed, reviewed and approved before they are applied, inside agreed maintenance windows, with a record of who did what.

Automation and templates. One definition of a standard, such as the NTP servers or the login banner, applied to many devices across vendors.

Credentials. Every capability above needs privileged access to devices, so the credentials need careful storage.

How tools talk to devices

Two families of protocols do the work.

The CLI over SSH is universal. A tool logs in, runs show running-config or its equivalent, and saves the output. To change a device, it sends the same commands an engineer would type. It works with almost anything, but the tool has to understand each vendor's syntax and parse text output.

Model-driven management treats configuration as structured data described by a schema. NETCONF carries configuration as XML over SSH, with operations such as locking a datastore and validating a candidate configuration before committing it. Its schemas are written in YANG. gNMI, from the OpenConfig project, does the same over gRPC. With a model, a tool can change exactly the fields it means to and read them back, with no text parsing. Support varies by vendor and model, so most networks need both approaches.

Intent, not scripts

Mature configuration management describes what a device should look like, its intent, rather than the steps to get there. A tool compares intent with the running configuration, shows the difference, and changes only what differs. That makes changes reviewable, because a reviewer reads a difference rather than a script, and repeatable, because applying the same intent twice changes nothing the second time.

How Tracix handles it

Configuration management in Tracix works through the collectors on your networks, so devices only need to accept connections from a collector nearby.

• Backups. Collectors capture running configurations over SSH for 30 network OS families, on a schedule, and right after a device announces a configuration change with an SNMP trap. Every changed configuration becomes a new version.
• Intent and drift. You declare intended configuration from vendor-neutral templates, by hand, or with Brain, and Tracix shows whether each device is in sync, has drifted, or has a backup too old to tell.
• Compliance. Ten built-in rules, such as Telnet disabled and no default SNMP community, plus text checks of your own, evaluated against the latest backup or the intent. A check Tracix can't evaluate is reported as such, never as a pass.
• Reviewed changes. Changes go through change requests: an offline preview with safety checks, an approver, maintenance windows and blackouts, then deployment by the device's collector.
• Where it changes devices. Over SSH on Cisco IOS, NX-OS and IOS-XR, Arista EOS, Juniper Junos, Fortinet FortiOS, Palo Alto PAN-OS and VyOS. Over NETCONF or gNMI on Arista EOS and gNMI on Nokia SR Linux, writing only the fields a change names and reading them back. Other OS families are backed up, never changed.
• Credentials. A write-only vault encrypted with AES-256-GCM. Collectors receive a credential for one job at a time.
• Firmware. Tracix copies firmware images to devices and verifies their checksums there. It never changes the boot image or reloads a device.

Network changes like code follows a change from draft to read-back, and Network configuration management in the docs covers each task.