Arista AVD gives network teams a proven way to generate consistent EOS configuration from structured inputs.
But if you’re using AVD, configuration generation is only one part of operating the data center network. You also need to standardize the engineering decisions behind those inputs, coordinate the network with the compute, storage, security, platforms, and services it supports, and control how changes move from design into production.
Those requirements become more important as AVD is used across more fabrics, sites, infrastructure domains, and teams. The question isn’t only how to generate the configuration. It’s how to make the network design itself reusable, connected to the rest of the data center, and governed as part of the automation workflow.
That is the role Infrahub adds around AVD.
The Infrahub + Arista AVD reference design is a working architecture for standardizing the design behind AVD, representing the fabric in the context of the infrastructure it supports, and reviewing changes before AVD generates the resulting EOS configuration.
Standardize the design behind AVD
AVD inputs contain the information AVD needs to generate a fabric. Behind those inputs is a broader set of engineering decisions: topology patterns, device roles, interface assignments, addressing conventions, routing standards, hardware-specific rules, and resource policies.
With Infrahub, those decisions can be represented as structured data and reusable automation. Engineers specify the requirements that legitimately vary—for example, the site, rack, capacity, hardware, or service requirements—and Infrahub Generators produce the devices, resources, relationships, and AVD inputs according to the established design.
That changes the level at which your team manages automation. Device variables remain important, but they’re no longer the only place the design is expressed. You can manage the architecture and standards that determine those variables, then reuse them across fabrics and sites.
For teams operating more than one environment, this creates a common engineering basis for each deployment while keeping the differences that genuinely belong to a particular site explicit.
Manage the Arista fabric as part of the data center
The network is one part of a larger data center design. A rack isn’t only a pair of leaf switches. It includes servers, interfaces, addressing, VLANs, cluster membership, applications, and services that depend on the network being designed correctly.
Infrahub can represent the relationships between the Arista fabric and the compute, GPU clusters, storage, security systems, Kubernetes platforms, circuits, applications, and services it connects. That gives network automation context about the infrastructure the fabric supports.
Those relationships make practical questions easier to answer from the data itself: Which servers connect through this leaf? Which services depend on this link? Which racks consume this address pool? What systems are affected by a planned network change?
They also create a basis for coordinating changes across infrastructure domains. A new rack, for example, can include network connectivity, interface assignments, addressing, VLANs, server relationships, and service requirements as parts of the same design instead of unrelated updates that need to be reconciled later.
The reference design demonstrates this pattern with a defined set of fabric and connected-endpoint models. Your organization can extend the Infrahub schema to represent additional data center domains as your automation scope grows.
The value goes beyond simply consolidating more inventory. By giving the network design the context of the infrastructure it supports, engineers and automation can understand relationships and dependencies before a change is deployed.
Control how the design changes before it becomes configuration
When structured design data drives production automation, security and governance need to apply to that data as well as to the final device configuration.
Infrahub branches let engineers change the design without changing the accepted state. Proposed Changes provide a review point where engineers and approvers can inspect changes to topology, addressing, shared resources, relationships, generated Artifacts, and validation results before the change is accepted.
The review can therefore happen at the level where the engineering decision was made, not only after that decision has been rendered as EOS CLI.
Infrahub also provides controls such as role-based access, SSO, approvals, and change history. In practical terms, your team can control who can change the data that drives automation, require review for the changes that matter, validate the result, and retain a traceable record afterward.
That record is useful beyond the approval itself. During an audit or incident review, you can see what changed, who changed it, who approved it, and when it became part of the accepted design.
Coordinate shared resources as part of the design
Network design also depends on finite shared resources: IP prefixes, addresses, VLAN IDs, ASNs, node identifiers, and other values that multiple engineers and workflows may need at the same time.
Infrahub Resource Manager and IPAM make those allocations part of the modeled change. Engineers working on separate branches can request values from managed pools while reservations remain coordinated across concurrent work.
That means resource allocation can follow the same workflow as the rest of the design. A change that creates or expands a fabric can allocate the required network resources and carry those decisions directly into the AVD inputs, rather than relying on a separate spreadsheet, ticket, or manual coordination step.
Give other teams controlled access to network data and services
The network is consumed by more than the network automation team. Compute, storage, platform, application, and operations teams need network information, and many of their workflows require connectivity, addressing, VLANs, or other network resources.
Infrahub can expose the modeled data through its web interface, GraphQL API, self-service workflows, and MCP-based AI workflows. Other teams can look up the information they need or initiate defined requests without becoming direct editors of the network design.
Network engineering continues to define the design standards, validation rules, resource policies, and approval requirements. A request can create a Proposed Change and follow the same review path as an engineer-authored network change.
The result is controlled access rather than unrestricted self-service. Other teams get a clearer way to consume network data and services, while network engineering keeps the standards and approvals that determine how the network changes.
Where Infrahub fits in the Arista stack
The reference design adds a layer upstream of the Arista tools that already generate, validate, deliver, and operate the network.
Infrahub manages the network and data center design, the relationships around the fabric, shared resources, and the process for reviewing changes to that design.
Arista AVD / pyAVD takes the resulting structured inputs and generates EOS configuration and documentation. ANTA validates the network. CloudVision delivers configuration and provides operational capabilities for the Arista environment.
AVD Studio remains Arista’s native experience for engineers working directly with AVD. Infrahub becomes relevant when the data behind AVD also needs to participate in a broader data center model, shared resource management, organization-specific review processes, or workflows used by other teams and automation systems.
In short: Infrahub manages and standardizes the design, AVD generates the Arista configuration, ANTA validates the network, and CloudVision delivers and operates it.
Run the architecture with the reference design
The Infrahub + Arista AVD reference design packages this architecture into a working implementation your team can clone, run, inspect, and adapt.
It includes AVD-oriented schemas, fabric topology and relationship models, resource-allocation patterns, Infrahub Generators and Transformations, pyAVD integration, generated configuration and documentation, ANTA test catalogs, seed data, example workflows, and a runnable environment.
From the modeled fabric, the reference design can create the network objects and resource assignments required by its supported design patterns, produce the AVD inputs for each device, render EOS configuration and documentation through pyAVD, and generate Artifacts such as cabling plans and ANTA test catalogs.
It intentionally covers a defined set of AVD capabilities. It’s a reference implementation, not a certified network design and not an attempt to reproduce every AVD setting in the Infrahub schema.
If you’re evaluating AVD, it provides a concrete architecture to start from.
If you’re already running AVD, Infrahub can be introduced incrementally by moving selected data (such as inventory, topology, addressing, VLANs, ASNs, or resource allocation) into Infrahub, while keeping the existing pyAVD, ANTA, Git, CI, orchestration, and CloudVision workflows in place.
From configuration generation to managed network design
This reference design is far more than another way to render configuration. It’s a way to manage the design and operating context that configuration automation depends on.
Using Infrahub and AVD together, you can:
- Standardize the engineering decisions behind AVD.
- Represent the fabric with the infrastructure it supports.
- Put access controls, review, validation, approvals, and history around the design.
- Coordinate shared resources as part of the same workflow.
- Give other teams controlled ways to consume network data and services.
AVD remains responsible for generating the Arista configuration, while Infrahub adds the design layer around it.
