Arista AVD Documentation

The eos_designs role provides an abstracted data model to deploy various network designs and use cases. It is designed to enable consistent deployment of Arista Leaf & Spine fabrics with both underlay and overlay network services.

Key Characteristics

• Stackable Template Architecture: The role is designed to be easily extended using the eos_designs_custom_templates data model.
• Offline Configuration Generation: It generates the intended configuration offline without needing to query the current state of the switches.
• Integration Workflow:
  • Use eos_designs to generate the structured data model.
  • Use eos_cli_config_gen to transform that data into EOS CLI configuration.
  • Deploy the configuration using eos_config_deploy_eapi or cv_deploy (config replace strategy).
  • Validate the configuration post-deployment with anta_runner or pre-deployment with tools like Batfish.

PyAVD is a Python package that serves as the foundation for the Arista AVD project and the arista.avd Ansible collection. It is co-versioned with the Ansible collection.

Key Capabilities:

• Input Validation: Validates inputs against AVD Design data models.
• Fact Generation: Generates avd_facts and structured config for use in subsequent PyAVD functions.
• Config Validation: Validates structured config against EOS Config data models.
• Configuration Generation: Generates device configuration and device documentation.

Important Constraints:

• Data Mutation: Input data and structured_configs are updated in-place by various functions. If you need to preserve the original data, perform a deep copy before calling PyAVD functions.
• Thread Safety: The functions get_device_structured_config(), get_device_config(), and get_device_doc() are not thread-safe. Avoid running these for the same device across multiple threads.
• Identity: The logic uses the hostname as the unique identifier for each device. Overlapping hostnames are not supported.
• Fabric Logic: For get_avd_facts(), the fabric_name is not used or verified; all devices in the provided input are treated as a single fabric.
• Hostname Requirement: hostname must be set in structured_config for each device (though get_structured_config() will set this correctly automatically).

Arista AVD supports several pre-defined network topologies. You can extend AVD to support custom topologies by using node_type_keys to create your own node types.

Supported designs include:

• 3-stage Clos (Leaf & Spine): Supports layer 3 leaf and spine deployments, optionally with overlay controllers. Can represent spines, L3 leafs, and L2 leafs (often called a "POD").
• 5-stage Clos (Super Spine): Supports larger deployments where multiple leaf-spine PODs are interconnected by super-spines. Super-spines can be single or multiple planes.
• Layer 2 Leaf Spine: Supports L2 leaf and spine deployments where routing may terminate at the spine or an external L3 device.
• MPLS: Supports arbitrary physical mesh topologies using core_interfaces settings.
  • Underlay protocols: ISIS-SR (default), ISIS + LDP, ISIS-SR + LDP, OSPF + LDP.
  • Overlay protocols: IBGP (default).
  • Note: MPLS does not support MLAG, VXLAN, or Inband Management. EVPN settings use mpls_overlay_role and mpls_route_reflectors instead of standard EVPN keys.
• WAN (AutoVPN and CV Pathfinder): Uses node types wan_rr and wan_router. Default underlay is none, but eBGP is supported. Overlay is IBGP (default).

The wan_route_servers key allows WAN routers to establish connectivity to AutoVPN RRs or CV Pathfinder nodes. This is useful when WAN routers and route servers reside in different inventories.

• wan_router: A router configured with wan_route_servers will establish BGP peering to all listed servers if they share a common path-group.
• wan_rr: A route server configured with wan_route_servers will establish BGP peerings to every other server in the list if they share a common path-group.

Best Practices:

• Always use at least 2 WAN route servers for redundancy.
• Ensure at least one WAN route server exists in each path group.
• If route servers are in a different inventory, you must provide full configuration details under the wan_route_servers key, as AVD cannot derive them automatically. This configuration takes precedence over derived data.

BGP Peer Group Note: When configuring passwords for wan_overlay_peers, you may also need to set a password for wan_rr_overlay_peers if Pathfinders use the same VTEP IP range as edge routers. Failure to do so may prevent static BGP peerings between Pathfinders from coming up.

wan_route_servers:
  - hostname: pf1
  - hostname: pf2

AVD uses variables to generate EOS configuration files. While variables can be placed in the main inventory.yml, it is best practice to use dedicated folders for organization:

1. group_vars/: Contains YAML files named after the groups defined in your inventory. For example, group_vars/DC1.yml will apply variables to all hosts in the DC1 group. This allows you to set broad network settings (like mgmt_gateway) at a high level and specific settings (like bgp_as) at a lower level.
2. host_vars/: Contains YAML files named after specific hosts to override group-level settings.

Variable Precedence

When a conflict occurs, the order of precedence (from lowest to highest) is:

1. all group
2. Parent group
3. Child group
4. Host

Example Group Variable Configuration

In group_vars/DC1.yml, you can define both group-wide defaults and specific node configurations:

---
# Default gateway for management
mgmt_gateway: 172.16.1.1

# Spine switch group configuration
spine:
  defaults:
    platform: vEOS-lab
    loopback_ipv4_pool: 10.255.1.0/27
    bgp_as: 65100
    bgp_defaults:
      - distance bgp 20 200 200

  nodes:
    dc1-spine1:
      id: 1
      mgmt_ip: 172.16.1.11/24
    dc1-spine2:
      id: 2
      mgmt_ip: 172.16.1.12/24