Automating Config Deployment with NetBox#
CfgMgmtCamp Ghent 2026 digest Program Core pick 2–4 February 2026
Christopher Rössler, network engineer at the Berlin Commercial Internet Exchange (BCIX)
- Why: A real, production network-automation story from an Internet Exchange — exactly the physical-networking source-of-truth problem (scattered data across IXP Manager, NetBox, and running configs) that anyone running switch fabrics faces. No vendor pitch; this is an operator describing how they closed the loop from intended-state database to deployed switch config.
- What: BCIX's journey from hand-written switch configurations to a mostly automated pipeline centered on NetBox as the single source of truth, plus how that foundation now also drives maintenance prep and peering-platform announcements (from abstract only).
- How: A four-step pipeline: collect/normalize data into NetBox with Ansible; generate configs from Jinja2 templates; diff and validate actual vs. intended configuration; deploy to switches. The interesting part is reconciling IXP Manager (INEX's IXP operations platform) with NetBox so both agree with what's actually on the boxes.
- Where applicable: IX/peering-specific in its tooling (IXP Manager), but the pattern — consolidate sources of truth, generate, diff, deploy — is broadly applicable to any multi-tool network environment. Worth watching for how they handle intended-vs-actual drift detection in a fabric where consistency errors cause real outages.