Posts

In Part 4 of this series, we decoupled our network intent from the execution logic, using Jinja2 templates and model-driven YANG schemas to push VPLS configurations to our Nokia SR OS nodes via NETCONF. But seeing a yellow CHANGED status in your terminal is only half the battle. The ultimate question isn’t “Did the configuration push successfully?”, it is “Is the service actually operational in the data plane?” In this fifth and final part of our series, we close the loop. We will look at how to treat network operational states as structured data, execute automated Pre-Checks vs. Post-Checks, and build an immutable validation gate using Ansible assertions to guarantee compliance across our Containerlab fabric. ...

In Part 3 of this series, we treated our physical network topology like software application code, using Containerlab to spin up our test sandbox in seconds. With our nodes live, how do we actually generate and push configurations to them? If you hardcode configuration blocks directly into your Ansible tasks, your playbooks quickly become unmanageable. The moment a VLAN ID changes, or you swap a router from a Nokia SR OS node to a Cisco instance, your entire automation framework collapses under its own weight. ...

Up until now, our pipeline has focused on the management and mapping of data. We modeled our nodes inside our NetBox source of truth (Part 1), and then we built a dynamic handshake to pull that data straight into Ansible (Part 2). But there’s a missing link: Where are the actual routers coming from? If we have to manually spin up heavy virtual machines, map virtual interfaces, and configure bridge links every time we want to test our playbooks, we lose all the speed advantages of automation. ...

By default, Ansible relies on static inventory files (hosts.ini or hosts.yaml). In a dynamic, modern network environment, managing these text files manually becomes an operational nightmare. To bridge this gap, we can tie Ansible’s execution directly to NetBox, using it as our single source of truth. Before we configure the plugin, your local control machine needs the official NetBox collection along with its underlying Python API wrapper and timezone dependencies: ...

NetBox is an open-source Infrastructure Resource Management tool designed to act as that single source of truth. It decouples your network state variables from both your configuration playbooks and your physical hardware. In this guide, we will deploy NetBox locally on Ubuntu and model a very simple set of infrastructural data. graph LR subgraph Truth [Data Layer] NB[(NetBox)] -- "Host Variables & State" --> API[REST API / GraphQL] end subgraph Logic [Execution Layer] API -- "Dynamic Inventory" --> Ans{Ansible Engine} end subgraph Infrastructure [Network Layer] Ans -- "SSH / Netconf" --> R1[Nokia 7750 SR-1] Ans -- "SSH / Netconf" --> R2[Multi-Vendor Edge] end style NB fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff style Ans fill:#1a202c,stroke:#e2e8f0,stroke-width:2px,color:#fff style R1 fill:#2b6cb0,stroke:#4299e1,stroke-width:2px,color:#fff style R2 fill:#2b6cb0,stroke:#4299e1,stroke-width:2px,color:#fff1. System Architecture & Dependencies Before provisioning, we must understand NetBox’s application layers. It is not a single monolith; it is an ecosystem of decoupled components that work together over defined boundaries: ...