I just wrapped up a presentation and demo of NVIDIA Config Manager (NVCM) in Dublin at iNOG::16 on September 10. It was the first iNOG back after a long post-COVID break, and it was great to see the Irish networking community getting together again.
And for anyone new or old to Dublin: you need to get the wings at Elephant & Castle in Temple Bar. Best wings out there, I tell ya.
My topic for the presentation was how NVIDIA is automating the network infrastructure behind AI factories using NVIDIA Config Manager (NVCM). NVCM is open source, built by NVIDIA, and brings together the concepts of Source of Truth, configuration rendering (and storage), ZTP, DHCP, and workflow automation.
As I learned more about NVCM and prepared the demo, I kept coming back to a broader concept. Namely that Configuration is an output and Design is the input. Or said differently: THE DESIGN IS THE DATA.
This isn’t a new idea per se. At Network to Code, we’ve been talking for years about moving network automation toward data models, intended state, and reusable, codified network designs. In fact, Nautobot Design Builder was built specifically around that idea. Basically, you take a relatively small number (the fewer the better) of user-facing design inputs and use them to create the full set of data required to represent and automate devices and networks. Net net, we want minimal [user] inputs to drive maximum [data] outputs.
What I like about NVCM is seeing these concepts applied to the problem of building and operating AI infrastructure at a significant scale. While AI factories are a great use case, this approach goes far beyond AI data centers. It applies just as well to a 500-site branch network, 2,000 retail stores, a global campus environment, or 100s of wiring closets that enterprises still build one switch at a time.
Diving into NVIDIA Config Manager
At the center of the default NVCM deployment is Nautobot. Within the default deployment architecture, Nautobot serves as the Source of Truth for data about the network, modeling devices, interfaces, cabling, IP addresses, routing, device roles, and other data such as NTP servers through configuration contexts, along with anything else needed to describe and automate the network. Also bundled with the NVCM deployment are Nautobot Apps including Design Builder, Firewall Models, and BGP Models built by Network to Code. NVIDIA also includes several Apps they built and maintain, including nautobot-broker-nats, nautobot-nvdatamodels, nautobot-fsus, nautobot-app-overlays, and nautobot-nv-config-manager.
Changes from Nautobot are published as events through NATS JetStream, triggering configuration generation within the NVCM Render Service. The result is a near real-time generated intended configuration that is stored in the NVCM Config Store. Temporal provides the workflow engine for operations such as deployments, backups, validation, multi-device changes, etc.
NVCM also brings DHCP, ZTP, an operator UI (the NVCM UI), and an MCP server into the pre-packaged platform all installed via a single helm chart.
AI Factories Meet Design-Driven Automation
The scale NVIDIA is solving for justifies and requires the need to start with data. In the reference architecture I used during the presentation (the NVIDIA SuperPOD architecture), a single H100 SuperPOD has roughly 80 switches across compute, storage, in-band management, and out-of-band management fabrics. That equates to roughly 5,000 switch ports, thousands of cables, hundreds of IP addresses, multiple BGP ASNs, and all-in thousands of individual objects that need to exist correctly before the infrastructure can operate. Keep in mind, that’s one pod.
The important point isn’t that there is a lot of data to manage. It is that we humans shouldn’t have to enter thousands of individual objects to describe that network or infrastructure.
Instead, we should describe the design. That means focusing on answering questions such as:
- What site and racks are being built?
- Which network blueprint are we deploying?
- What switch roles exist within that blueprint?
- Which address pools should be used?
- What are the BGP and routing parameters?
- Which devices belong in each location?
- How should those devices and interfaces be connected?
From a relatively small amount of design inputs, automation can create the devices, interfaces, IP addresses, cables, ASNs, DHCP reservations, configuration contexts, and anything else needed to represent a configuration. This video describes it well before Source of Truth, Nautobot, and Design Builder became a thing – it’s worth a watch. That video is an oldie, but a goodie!
That’s where Design Builder comes in. It allows us to define the network [design] as data.
Design Builder Enables Design-Driven Automation
Nautobot Design Builder lets you define and codify standardized network designs directly in Nautobot.
Rather than treating the Source of Truth as a database that you or your team has to populate, the design itself becomes an executable model for creating the desired intended state.
Design Builder’s !create_or_update behavior makes adding data idempotent, so rerunning a design converges Nautobot toward the intended design instead of blindly creating duplicate objects. Deployments are also tracked and attributable, tying the data back to the design and deployment that created it.
Now imagine extending that model into a simple “Add Rack” operation.
The engineer provides the rack type, site, role, and a small number of local parameters. Again, the fewer the better. From those inputs, the design could:
- Create the required switches and other infrastructure objects.
- Allocate addresses from the correct pools.
- Create interfaces and cabling.
- Establish BGP and routing data.
- Generate DHCP reservations.
- Build the required configuration contexts.
- Render the intended device configurations.
- Launch a governed multi-device deployment.
Instead of saying, “Configure these eight switches,” we’re saying, “Add another rack using this design.” That’s design-driven network automation.
For more on Design Builder, check out this blog when we first announced it and another when we added more features and functions.
The Demo
For the live demo, I used NVIDIA DSX Air with virtual Cumulus Linux switches.
For Day 0, I wiped one of the switches back to essentially factory state. It received what it needed to start ZTP from DHCP, applied that configuration, and updated its status in Nautobot, and then kicked off a backup of itself to complete the ZTP process. All within a minute or less.
For Day 2, I changed network intent in Nautobot (just updated an interface description to keep it simple). That change triggered an event in NATS JetStream, NVCM generated a new intended configuration, and I launched a deployment workflow in which I saw the diff (human approval) before proceeding with a config deployment.
The sequence diagram above describes what I demo’d and the core workflows you get out-of-the-box with NVCM.
Beyond AI Factories
AI factories are an ideal example because they require scale with highly repeatable designs, but repeatability is everywhere in networking.
A campus may have hundreds of wiring closets, but probably only a handful of actual designs:
- 48-port access closet
- 96-port access closet
- High-density wireless closet
- Building distribution
A retailer might have:
- Small Store
- Medium Store
- Large Store
- Distribution Center
A branch architecture might have:
- Small single-WAN branch
- Standard redundant branch
- Large regional branch
- SD-WAN hub
We don’t really want an automation called: “Configure NYC-STORE-047-SW01.” We want: “Deploy Store -Type Small”.
The design should describe everything required for that location, e.g. WAN connectivity, switches, wireless, VLANs, addresses, interfaces, routing, security policy, etc. and everything else that makes that location a “Small Store.”
Of course, as AI and agentic workflows increase, the value of structured data and designs only goes up.
An AI agent that only sees device configs/commands is missing much of the context that matters. What role does this device play? What design is it part of? What should it be connected to? What policies apply to it? What is its intended state? What other infrastructure will be affected if something changes?
A Network Source of Truth starts answering those questions. A design-driven Source of Truth answers even more of them.
Closing
Of course, I’m obviously excited to see Nautobot and Design Builder playing such important roles in the default NVCM architecture, but the bigger takeaway for me is the architecture and the approach.
As I said, AI factory networks make the scale easy to see, but the same approach applies to campus networks, branches, retail stores, traditional data centers, and just about anywhere infrastructure is built from repeatable patterns.
At Network to Code, we’ve spent more than a decade helping network teams move from scripts and task automation toward data-driven automation, automation platforms, and reusable network designs. If you’re experimenting with NVIDIA Config Manager, we’d love to hear what you’re building. If you want help, even better!
But the idea I hope people take away goes beyond NVCM, Nautobot, or any individual product:
Stop treating configuration as the thing you’re automating. Automate the design. Let the design create the data. Let the data drive the configuration.
Finally, nice job by NVIDIA releasing NVCM as open source, and I look forward to the next iNOG that I can attend.
-Jason
