case studies
Intent Based Networking in Production
INTENT BASED NETWORKING IN PRODUCTION: WHAT THE ARCHITECTURE ACTUALLY LOOKS LIKE
Customer Story
One of our clients came to us still provisioning their network from a single Python script held together by IF statements. If the device was model X, apply config Y. If model A, apply config B. The variables it needed lived in a file someone filled in by hand before every run.
It was automation without intent. The script produced a config, but nothing held the intent behind it. There was no source of truth, no record of what changed or why, and once the script finished the live network was free to drift. Turning up a new site took weeks, sometimes months, and after a while nobody could say with confidence what the network was supposed to look like.
Engineering
Published: June 8, 2026
Client: Non Disclosure
Industry: Hosting & Cloud Provider
Services: Professional Network Services, Network Automation
Solution
We rebuilt the network around a simple principle. Describe what the network should be, once, in a single place, and derive everything else from it. Config is rendered from intent, every change is reviewed against intent, and the running network is reconciled back to intent.
Intent lives in NetBox: devices, IPs, VLANs, VRFs, interface settings, routing policy, and BGP through the plugin. Python reads the intent and Jinja2 renders per-vendor config from it, so an engineer changes intent and the config follows. The output is committed to Git, where every change is a reviewable diff with a full audit trail. GitHub Actions runs the pipeline: validation checks and a live diff against the running config on every pull request, then a human approval gate. Once approved, a deployment worker pushes over eAPI, NETCONF, gNMI, or SSH, confirms connectivity, and rolls back if anything goes wrong. After a clean deploy the source of truth updates itself, and a webhook sync registers the device in Zabbix with the right template. No vendor magic and no model in the path. Just intent, deterministic rendering, and a disciplined pipeline.
WHAT WE AUTOMATED
If it affects the running config, it is expressed as intent, not typed on a device. That covers: ports modeled directly as access or trunk with specific VLANs, IP assignment, SVIs, MTU, descriptions, port-channel membership, and DHCP relay with the correct helper; device and rack provisioning by device type; VPS, bare metal, and BGP customer service provisioning; internal fabric BGP and external sessions with peers, upstreams, IXs, and customers, plus route maps and Arista RCFs through the plugin; prefix management as the system of record; and CoPP and ACL changes driven by IP and prefix tagging.
KEY DECISIONS
We picked Python and Jinja2 over Ansible or Terraform so the network team could own the pipeline without a separate DevOps function. Ansible holds up until the conditionals get ugly, and a multi-vendor fabric makes them ugly fast. Terraform for networking is powerful but wants a dedicated team to keep it stable.
The hard part of intent-based network integration has nothing to do with network code. It is how you model intent. In NetBox the choice is Config Context versus Custom Fields. Config Context is elegant until a non-technical person has to touch it. Custom Fields are cleaner for humans but mean more setup per use case. The data model is where the project actually lives, and you rebalance it for months.
Production drifts. When the running config diverges from intent, the system flags it and lets you choose the direction: trust intent and push the model onto the devices, or trust the network and pull the live state back into the model. That closed loop is what separates real intent-based networking from a one-time push.
We also made the safe path the only path. On Arista we use commit and commit-confirmed with automatic rollback, and we disabled configure terminal entirely. The only way to change a device is through the commit workflow, which removes the most common source of untracked drift: a quick manual fix nobody records.
THE RESULT
Site turn-up went from weeks, sometimes months, to one to two days. The headline number is not the most useful part. The network now has a single, queryable definition of what it should be, every change is reviewed and recorded, and the model and the running network agree.
OUR TAKE
A lot of intent-based networking marketing puts an LLM or closed-loop AI at the center. For deterministic work like provisioning and policy you do not need it. Real intent-based networking is a good data model, deterministic network automation, and a disciplined pipeline. Before reaching for AI, the honest question is whether a workflow and a template would already do the job. For this class of work, they do.
be our next success story!
Drop us a line! We care for your Business and are here to answer your questions 24/7