INFRAHUB REFERENCE DESIGN

Deploy and update the Arista fabric from a model that records every change.

Q: Does this replace Arista AVD?

No. AVD still generates the configuration — PyAVD runs inside Infrahub and renders the EOS CLI. What changes is where the data behind it lives: modeled in Infrahub rather than maintained as per-device files.

From the first fabric through Day Two changes, run Arista AVD on a model your team can query, review, and audit.

Clone and run a complete Arista fabric build: Fabric → Pod → Rack with addressing pools, EVPN services, and per-device intent as queryable data. PyAVD runs inside Infrahub and renders the EOS configuration.

Add a source of truth under Arista AVD

Model the fabric in Infrahub and keep Arista AVD as the configuration engine. The same pipeline runs on structured data the whole team can query. The design is versioned like code, and every change is reviewable before it reaches a device.

Model the fabric once: The Generators produce the devices, interfaces, cabling, and addressing, then assemble each device’s AVD inputs from that data.
Change it as the fabric grows: Edit the design and regenerate only what changed. Branch-aware pools keep parallel work from allocating the same prefix, ASN, or node ID.
Open it to the rest of the organization: Compute, storage, and application teams look up a VLAN, prefix, port, or device configuration through the web UI, GraphQL API, self-service portal, or an AI assistant over MCP.

Evaluating Arista AVD and deciding how to feed it?

Run the reference design to see how the data layer works.

Already running Arista AVD?

Use it as the working reference for adding a source of truth to the pipeline you have.

What's included

From fabric design to EOS configuration

Start with the Arista data model and automation already built

Pre-built schemas for the Fabric → Pod → Rack hierarchy, devices and interfaces, IPAM, VLANs, and EVPN services, plus the Generators, resource pools, and device templates. You get all the code you'd otherwise write before a build can start.

Define the fabric, generate the devices and their configuration

Set the fabric's shape: pods, racks, device counts, addressing scheme, and the Generators produce the devices, cabling, IP and ASN allocations, each device's PyAVD inputs, and the rendered EOS configuration.

Add a segment, server, or tenant without writing code

Add a network segment, provision a server into a rack, or create an EVPN tenant through a guided form in the self-service portal. Each operation opens a branch and a Proposed Change so the work is reviewed like any other change.

How it works

Edit the design, review the rendered configuration, then deploy

Edit the fabric design in Infrahub and run the Generators to expand it into devices, interfaces, cabling, and addressing, then into each device’s PyAVD inputs.

PyAVD runs inside Infrahub's workers so rendering the EOS configuration needs no separate CI project or Ansible layer alongside the source of truth.

Query the design and what it produced, side by side

Work with the intent, devices, and rendered configuration through one API. The design persists as structured data, independent of what was generated from it.

Trace a computed value back to what produced it

AVD derives point-to-point addressing, BGP peerings, and prefix lists during rendering. Read those values in Infrahub next to the design, with their source recorded, instead of opening a rendered config to find them.

Add a rack without touching the rest

Add a rack or a VLAN by editing the design and running one Generator. Review the data diff and the rendered configuration in a branch before anything merges.

Working across mixed vendors rather than standardizing on Arista? The AI data center reference design covers Cisco, Arista, and Dell from one design model.

Get started

See it in action

Watch the Generators build a full fabric from a design. PyAVD renders the EOS configuration, and the change goes through a Proposed Change with the artifacts attached.

Then run it in your own environment

Clone the repository and run it locally.

Load the schemas and seed data, then generate your first fabric.

Adapt the schemas and Generators to your design.

This is a reference design covering a defined set of AVD capabilities. Read the supported capabilities before planning a deployment.

FAQ

Where AVD ends and Infrahub begins

Does this replace Arista AVD?

No. AVD still generates the configuration. PyAVD runs inside Infrahub and renders the EOS CLI. What changes is where the data behind it lives: modeled in Infrahub rather than maintained as per-device files.

Is Ansible still required?

Not for generation. PyAVD runs directly in Infrahub’s workers. Deployment runs through the bundled Ansible runner or through CloudVision, whichever fits your environment.

Do we still write host_vars by hand?

No. The generators assemble each device’s PyAVD inputs from the fabric model, so the inputs are produced from the design rather than maintained separately.

Can we onboard an existing fabric?

Modeling an existing fabric and importing its configuration is done today through a guided engagement rather than a self-serve path. Talk to the team about what that involves.

Is this Arista only?

The reference design covers Arista through AVD. Model non-Arista equipment in the same source of truth alongside it. For a design that spans Cisco, Arista, and Dell, see the AI data center reference design.

Does it cover every AVD feature?

No. This is a reference design covering a defined set of AVD capabilities. Read the supported capabilities before planning a deployment.

Get started  your way →

Infrahub Community

Open source and forever free. All the schema flexibility and Git-style version control you need to explore at your own pace.

Download on GitHub →

Infrahub Enterprise

Built for scale, complexity, and production reliability: HA, advanced integrations, and SLA-backed support.

Request a demo →