Network IaC in the pipeline — the missing piece

Network configuration lags behind cloud, host, and workload configuration in CI/CD adoption. Cloud resources are declared against a stable API (Terraform), hosts are configured against a stable interface (Ansible), and workloads are reconciled against a stable control plane (Kubernetes). Networks are configured against a patchwork of vendor CLIs, vendor APIs, and shared devices that do not have a single source of truth. Closing that gap is hard, and the production framing has to respect that.

Where network IaC sits in the flow

flowchart LR
    A["Git commit of intent"] --> B["Batfish analysis"]
    B --> C["Render vendor config - NAPALM or Ansible"]
    C --> D["Diff against golden config"]
    D --> E["Change-window approval"]
    E --> F["Apply to device"]
    F --> G["Batfish post-change analysis"]
    G --> H["Rollback playbook ready"]

Three properties of this flow are worth pulling out:

• Analysis runs before and after the change. Batfish parses the candidate and live configurations and computes what would change in routing, reachability, and ACL semantics.
• The vendor CLI is wrapped, not replaced. NAPALM and Ansible network modules provide a thin abstraction layer; the device still runs the vendor’s parser.
• The change window is human-gated. Production network changes typically require a maintenance window.

Why networks lag

Three structural reasons explain why networks lag behind the other layers:

• Vendor fragmentation. Every vendor has its own CLI dialect, API surface, and configuration format. Cisco IOS and Juniper Junos are not interchangeable, and even within a vendor the syntax changes between platforms. Terraform providers exist for major vendors but coverage is uneven.
• Shared device, blast radius. A cloud resource belongs to one workload. A network device carries traffic for every workload that uses it. The blast radius of a wrong BGP change is the entire estate.
• Live state is hard to model. A router’s running configuration is the source of truth for what it is doing now. The startup configuration is what it will do at next reload. The two diverge after every out-of-band change.

These reasons mean the network layer is the last one a team should expect to GitOps-ify, and the first one where a pipeline that ignores them will cause an outage.

Analysis versus provision

The pipeline has two distinct jobs at the network layer:

• Analysis. Batfish takes a candidate configuration and a topology snapshot and answers questions: which routes would change, which ACLs would match differently, which prefixes would become unreachable. This is the safety net for CI.
• Provision. NAPALM and Ansible network modules take the candidate configuration and apply it. NAPALM provides a normalised abstraction over get-config and load-config; Ansible modules wrap the vendor CLIs with idempotent semantics.

The two are complementary. Batfish catches a change that would black-hole a prefix before the change is applied; NAPALM applies the change idempotently; a post-change Batfish run verifies the predicted behaviour matches the observed.

Production discipline

The production framing of network IaC in a pipeline has three rules:

1. Analyse first, apply second. A PR that does not produce a Batfish report is a PR that has not been reviewed at the network layer. The report goes in the PR description.
2. The rollback playbook is committed alongside the change. A BGP change without a recorded rollback is a BGP change that will be undone under stress, when the playbook is most needed.
3. Change windows are respected, not bypassed. A pipeline that can apply a network change outside the change window has lost the human-maintained safety layer.

Cross-course references

• Networking for Production Sysadmins - Parts XIX-XXII (Automation) cover the vendor-agnostic abstraction layers.
• Ansible for Production Sysadmins - Parts XLI-XLIV (Network modules) cover the Ansible collections for Cisco, Juniper, Arista, and Nokia.
• Terraform for Production Sysadmins - Parts XXI-XXIV (Multi-cloud networking) cover the cloud-side of network IaC.
• Observability for Production Sysadmins - Parts XXXI-XXXIV (Network telemetry) cover the gNMI and SNMP feeds for Batfish.

Quiz