An AI data center fabric is not simply a collection of switch configurations. It is a connected design spanning hundreds of switches, thousands of interfaces, multiple layers of topology, and an addressing hierarchy that must remain consistent across every pod and rack.
The network team operates against a demanding timeline. GPU and HBM infrastructure begins consuming capital when the hardware is ordered, while the return begins when the environment is available for workloads. For neocloud operators and other AI infrastructure providers, bringing the fabric online sooner shortens the path to revenue, while a repeatable delivery model makes it possible to expand capacity across sites without scaling engineering effort at the same rate.
Generating the initial configurations is only one part of that work. You also need to retain the design decisions behind the fabric, coordinate engineers working in parallel on shared design standards, and understand exactly what should change when you add capacity or update a standard later.
Design-driven automation gives you a way to manage the fabric throughout its lifecycle. Define the topology, addressing, device standards, and other design parameters as structured intent; generate the technical implementation from that source; and continue using the same model as the environment expands and evolves.
Infrahub provides the foundation for this approach. It stores the design and implementation together as structured, versioned data, connects them through explicit relationships, and provides a controlled process for generating, validating, reviewing, and merging changes. Instead of maintaining separate YAML files, scripts, and site-specific conventions, you can work from a shared design model that supports the initial build, day-two changes, and repeatable deployment across sites.
The open-source Infrahub AI Data Center reference solution makes this approach faster to evaluate and adopt. Rather than creating the schemas, resource pools, Generators, event triggers, and vendor templates first, you can begin with a complete working implementation. Run a fabric build, inspect how the design produces the implementation, make a scoped day-two change, and then adapt the same structure to your own topology, vendors, and standards.
The first build is not the hard part
Before any infrastructure can be generated, someone has to create the data pipeline that feeds the automation.
Teams often maintain large sets of YAML files or build custom Python and Jinja code to translate inventory and design information into the inputs required by their automation tools. This can automate the first build, but it introduces a second system that must be developed, tested, and maintained alongside the network itself.
The more difficult question appears later: what was this environment designed to be?
In many scripted workflows, the design is spread across documents, input files, and automation logic. Once the script has run, there may be no structured record connecting a rack, device, interface, or IP allocation to the design decision that created it.
Six months later, adding a rack requires more than generating two new leaf switches. You need to identify the applicable topology, addressing rules, interface standards, upstream connections, and configuration dependencies. Updating a standard across several sites raises the same question at a larger scale: which objects should change, and which ones already follow the new standard?
The challenge grows as more sites and engineers are involved. Multiple people share IP and ASN space while adapting the same templates to local requirements. Without a common design model, site-specific decisions can gradually become site-specific conventions.
As one principal network engineer at a hyperscale colocation provider described it:
“Every engineer, despite having config templates, you find one-offs or slight differences depending on who did the copy and paste.”
The goal is therefore broader than generating configurations. You need to preserve the context behind the generated infrastructure so your team can understand, review, and evolve it over time.
Learn more in the webinar on automating AI data center deployments at scale:
Store the design, then generate the implementation
With design-driven automation, you begin by describing what the infrastructure should look like.
A fabric object defines the top-level design. Pod and rack objects describe the hierarchy below it. Device templates capture interface layouts and roles. Resource pools define the IP prefixes, ASNs, VLANs, and other identifiers available to the design.
These objects remain in Infrahub as structured, queryable data. Generators read them and create the technical implementation: devices, interfaces, links, IP allocations, routing sessions, configuration data, and operational artifacts.
What is an Infrahub Generator?
A Generator is an Infrahub capability that converts higher-level design intent into the infrastructure objects needed to implement it.
You define a Generator in Python and specify the data it should read and the objects and relationships it should create or update. Instead of producing only a final configuration file, a Generator materializes the implementation as structured data in Infrahub, where it remains connected to the design inputs that produced it. Generators are declarative and idempotent — running one again creates only what is missing.
Generators can also be divided into smaller units with clear responsibilities. One Generator can create the fabric layer, while others create the pods, racks, or overlay services beneath it. This makes the logic easier to test and allows independent parts of the design to be processed in parallel.
The design-driven automation lifecycle
The design-driven automation lifecycle takes the fabric from structured intent through deployment and ongoing change in four parts:
- Define. Store the topology, addressing structure, vendor selections, device standards, and other design parameters as structured intent.
- Generate. Run modular Generators that translate the design into devices, interfaces, connections, IP allocations, routing sessions, and other implementation data.
- Deploy. Pass the generated configurations and artifacts to the tools already responsible for deployment, such as Ansible or Nornir.
- Evolve. Update the design and re-run the Generator responsible for the affected scope.
Infrahub provides the data foundation and controlled-change workflow that make this lifecycle practical across a real engineering team:
- Model the architecture on your terms.
- Define the objects and relationships that represent your environment.
- Extend the schema for optical infrastructure, InfiniBand, GPU clusters, or other domain-specific technologies.
- Generate the API and user interface from the same schema.
- Keep the design connected to its implementation.
- Store fabric, pod, rack, device, interface, resource, and service objects in a graph database.
- Preserve explicit relationships between the design and the infrastructure generated from it.
- Query both what exists and the design context behind it.
- Version and review the complete change.
- Version schema, infrastructure data, and generated artifacts together.
- Develop changes in isolated branches.
- Open a Proposed Change, run CI checks, inspect the diff, and review the update before it merges.
- Coordinate parallel builds through shared resources.
- Allocate IPs, prefixes, VLANs, ASNs, and other identifiers from shared pools.
- Keep allocations consistent across concurrent branches.
- Allow multiple engineers and site builds to progress without relying on separate allocation spreadsheets.
This follows the broader Infrahub model: unify infrastructure data, apply change control to the data and configuration logic, and integrate with the automation tools you already use rather than replacing them.
From one fabric object to a complete data center
The AI Data Center reference solution makes this workflow concrete.
It models a five-stage Clos fabric using a three-level hierarchy:
- A Fabric defines the super-spine layer.
- A Pod defines the spine layer and its relationship to the fabric.
- A Rack defines the leaf layer and its relationship to the pod.
Each level has a dedicated Generator.
The FabricGenerator allocates the fabric-level resources and creates the super-spine switches. It then triggers a PodGenerator for each pod. Those Generators create the spine switches, connect them to the super-spines, and trigger the rack layer. The RackGenerator creates the leaf switches and their connections to the spines.
One action at the fabric level starts the full sequence. Pod and rack Generators can run in parallel, while each Generator remains responsible for a defined part of the design.
A fourth Generator handles the EVPN/VXLAN overlay. Define a tenant, its VRFs, and its network segments as structured intent. The overlay Generator allocates the required VLANs, VNIs, ASNs, route targets, subnets, and anycast gateways, then determines which leaf switches should carry each segment.
The physical fabric and the services deployed on it remain separate but explicitly connected in the data model.
The reference solution applies this pattern to Cisco, Arista, and Dell fabrics. A Proposed Change triggers the CI pipeline, which renders the appropriate per-device configurations and generates a cabling plan. You can then pass those artifacts to an external deployment tool.
From a small set of design objects, the reference solution creates:
- Devices and interfaces
- Hierarchical IP allocations
- Point-to-point links and addressing
- BGP sessions
- OSPF underlay configuration
- EVPN/VXLAN overlay services
- Per-device startup configurations
- Interface descriptions
- Cabling documentation
Because Infrahub stores the design and implementation together, you can inspect both the resulting infrastructure and the inputs that produced it.
Day two starts with the same design
The same model supports incremental changes after the initial build.
Consider adding a rack. Create a rack object with its parent pod, rack type, number of leaf switches, and device template. The RackGenerator creates the required devices, interfaces, IP allocations, and links to the existing spine layer.
The rest of the fabric remains unchanged.
The Proposed Change shows the new objects and the artifacts affected by the additional connections, including the new leaf configurations, updated spine configurations, and revised cabling plan.
You do not need to run the entire fabric build again or create a separate process for expansion. The Generator used to build racks on day one is also used to add the next rack on day two.
The same principle applies to broader changes:
- Add a pod, and the pod-level Generator creates the new spine layer and triggers the rack Generators beneath it.
- Add a tenant or segment, and the overlay Generator updates the affected leaf switches.
- Update a shared standard, and the resulting changes can be reviewed across every object that uses it.
Every update follows the same branch → CI → diff review → merge process. You can see the proposed changes to both the infrastructure data and the generated artifacts before they enter the deployment pipeline.
This also supports multi-site delivery. Each site can use the same design model while capturing local requirements as explicit parameters rather than independent template forks. Engineers can work in separate branches and allocate resources from shared pools while maintaining consistent standards across sites.
Start from a working implementation
The AI Data Center reference solution packages this complete pattern into a working Infrahub project.
It includes:
- A pre-built schema for the physical fabric and EVPN/VXLAN overlay
- Four modular Generators
- Hierarchical IP allocation and overlay resource pools
- Event-driven Generator triggers
- Cisco, Arista, and Dell configuration templates
- Configuration and cabling-plan artifacts
- Demo fabric designs and tenant data
- A Docker Compose environment and setup tooling
- A guide covering the initial build and a scoped day-two change
You can use it in two ways.
First, run it as an evaluator. Load the example design, trigger the fabric build, inspect the generated objects, review the Proposed Change, and follow the day-two example without writing the implementation yourself.
Second, use it as a starting point for your own project. Adapt the schema, Generator boundaries, resource pools, event triggers, and artifact templates to your topology, vendors, and engineering standards.
The included topology is illustrative rather than prescriptive. The project is a reference implementation of the automation architecture, not a certified network design. Its purpose is to show how structured design intent, modular generation, resource allocation, configuration rendering, and controlled change work together in a complete AI data center workflow.
Run the AI Data Center reference solution
Explore the solution:
- Watch the walkthrough. See the Generators build a complete fabric from design inputs and then apply a scoped day-two change.
- Watch a webinar. Learn how AIDC can help you achieve consistent data center automation at speed and scale.
- Follow the demo guide. Run the workflow step by step and inspect the generated infrastructure, Proposed Changes, configurations, and cabling artifacts.
- Clone the repository. Run the project in your own environment and begin adapting the schema and Generators to your design.
Building an AI data center fabric and evaluating how design-driven automation could support it? Talk to the OpsMill team about your architecture and automation workflow.
