We describe network configuration as code from a single source of truth, whichever vendors you run. Every change is validated before rollout and goes through the same review as any other code.
When changes feel risky
A network changed by hand gets harder to change every year. It usually shows up like this.
Changes are made by handEvery change is made directly on the devices, feels risky and gets put off.
Configuration has driftedDevices that should match no longer do, and nobody quite knows why.
The diagrams are wrongDocumentation describes the network as it was, not as it is.
Troubleshooting under pressureAlerts say which port is down, but not what it affects.
The network described as code
Configuration is built from a source of truth and from templates, not from whatever happens to be on the devices. You can then see what the network should contain and spot when it doesn't.
What the network should containDevices, interfaces, segments and addresses are described in one place, for example in NetBox, Nautobot or files in your repository, starting from the records you already have. Configuration and documentation are built from it.
The same thing, done the same wayTemplates for each device type and role, whichever the vendor, and naming standards for devices, interfaces and segments that every change follows, so more than one person can understand the network.
What's actually runningWe start from the configuration on the devices, not the diagrams. Differences from the source, old exceptions included, become visible and are corrected one at a time.
Source of truthWhat the network should contain: devices, interfaces, segments and addresses.
Templates and naming standardsThe same device type is configured the same way.
Configuration per deviceBuilt from the source and templates, not by hand on the device.
DeviationWhat's running is compared with what should be running, so differences show.
How a change happens
Every change takes the same path, from a line in Git to the devices in the network.
Change in GitThe change is made in the source or the templates A branch and a description of why No commands typed directly on the devices Result A proposed change everyone can see
ValidationSyntax and structure, checked against the source and the standards New configuration compared with what's running Where it pays off, a run in a virtual lab such as Containerlab Result What would change on each device
ReviewA colleague reads the change and the diff The same routine as for other code Result An approved change with history
RolloutThe pipeline rolls it out, for example with Ansible or through the devices' APIs In stages when the change is large Checks on the devices afterward Result A network that matches the source
Follow-upAlerts tied to what's affected, from the same source as the configuration The latest changes at hand for whoever is troubleshooting Any change can be rolled back through Git Result Changes you can trace and roll back
Your team makes the changes
The repository, pipeline and standards are yours. We walk through them together, and your team makes the first changes itself while we're still on hand.
Take a change all the way from branch to rollout
Roll back a change through Git
Add a new device from the templates
RepositorySource of truth, templates and configuration, with a history of every change.
PipelineValidation and rollout, with the checks we agreed on.
Naming standardsHow devices, interfaces and segments are named, and why.
RunbooksCommon changes, troubleshooting and what to do when the pipeline can't be used.
