Skip to content

Porting Guide for Ansible AVD 5.x.x

Major releases of AVD can contain breaking changes. This porting guide addresses how to update your inventory and playbooks to be compatible with new default behaviors and changed data models when upgrading from AVD 4.x versions.

Note

To upgrade from AVD version 3.x, first upgrade to AVD 4.10 using the Porting Guide for Ansible AVD 4.x.x and then upgrade to 5.x with this guide.

Users of eos_designs need to consider the changes in eos_cli_config_gen when using structured configuration.

Common changes

Data model changes from “dict-of-dicts” to “list-of-dicts”

In AVD 4.0.0 and across both eos_designs and eos_cli_config_gen, all “dict-of-dicts” data models with user-defined keys were changed to “list-of-dicts”. In AVD 4.x inputs were auto-converted to the new data models.

As of AVD 5.0.0 the automatic conversion from dict-of-dicts has been removed, so it is required to update the input data to the new data models. The avd_data_conversion_mode key has also been removed.

Errors will be raised for each data model not conforming to the list type when running AVD:

$ ansible-playbook playbook.yml
<...>
ERROR! [host1]: 'Validation Error: access_lists': {'ACL-01': {'sequence_numbers': {10: {'actio<...abbreviated...>4 any'}}}} is not of type 'list'

As an example, ethernet_interfaces would be updated as follows:

ethernet_interfaces:
-  Ethernet1:   # <-- User defined key
+  - name: Ethernet1 # <-- "name" here is called the "primary_key" which must have a unique value across all list elements
    <...>

Removal of Ansible tags from AVD roles

Support for Ansible tags across AVD roles has been replaced with variables to control the execution of various parts of AVD.

The previous implementation of Ansible tags needed to be more consistent, and they were mostly undocumented. It often led to inconsistent behaviors depending on when the tags were used with --tags vs. --skip-tags.

AVD now supports several variables that provide detailed control over which areas of AVD should be executed. Variables are only added for the roles providing multiple optional functionalities.

Ansible Role Variable Default value Description
All avd_verify_requirements true Verify Ansible and Python requirements.
All avd_create_directories true Create required output directories if not present.
arista.avd.eos_designs avd_eos_designs_debug false Dump all vars and facts per device after generating avd_switch_facts.
arista.avd.eos_designs avd_eos_designs_structured_config true Generate structured configuration per device.
arista.avd.eos_designs eos_designs_documentation.enable true Generate fabric Markdown documentation.
arista.avd.eos_designs eos_designs_documentation.topology_csv false Generate Topology CSV with all interfaces towards other devices.
arista.avd.eos_designs eos_designs_documentation.p2p_links_csv false Generate P2P links CSV with all routed point-to-point links between devices.
arista.avd.eos_designs avd_eos_designs_unset_facts true Unset avd_switch_facts to gain a small performance improvement since Ansible needs to handle fewer variables.
arista.avd.eos_cli_config_gen eos_cli_config_gen_configuration.enable true Generate device EOS configurations.
arista.avd.eos_cli_config_gen eos_cli_config_gen_documentation.enable true Generate device Markdown documentation.
arista.avd.cvp_configlet_upload execute_tasks false Execute pending tasks on CloudVision after uploading configlets.
arista.avd.dhcp_provisioner avd_dhcp_provisioner_provision true Run arista.cvp.dhcp_configuration in either online or offline mode.
arista.avd.eos_config_deploy_cvp avd_eos_config_deploy_cvp_provision true Deploy/remove the generated configs and containers on CloudVision.
arista.avd.eos_config_deploy_cvp avd_eos_config_deploy_cvp_execute_existing_tasks or execute_tasks false cv_collection: v1 only
Execute existing tasks on CloudVision before uploading configlets.
arista.avd.eos_config_deploy_cvp avd_eos_config_deploy_cvp_execute_configlet_tasks or execute_tasks false Execute pending tasks on CloudVision after uploading configlets.
arista.avd.eos_config_deploy_cvp avd_eos_config_deploy_cvp_execute_container_tasks or execute_tasks false Execute pending tasks on CloudVision after creating containers.
arista.avd.eos_config_deploy_cvp avd_eos_config_deploy_cvp_execute_device_tasks or execute_tasks false Execute pending tasks on CloudVision after onboarding, moving or changing devices.
arista.avd.eos_validate_state - - See here for details on changes in eos_validate_state.

The tasks or functions mentioned will execute when the role is imported/included if the variable is set to true. Otherwise, it will not.

This change may require updates to playbooks, “Makefiles” or scripts, to execute the same parts of AVD. It is still possible to skip importing a role by using Ansible tags in the playbook. The tags will be applied to match all tasks in the imported/included AVD role.

The default behavior is the same as for previous versions of AVD, except for the CSV files, which are no longer generated by default.

For example, to run AVD without generating documentation, the playbook can be updated like this:

 - name: Build Configurations and Documentation
   hosts: FABRIC
   gather_facts: false
   tasks:

     - name: Generate AVD Structured Configurations without Fabric Documentation
       ansible.builtin.import_role:
         name: arista.avd.eos_designs
       vars:
         eos_designs_documentation:
           enable: false

     - name: Generate Device Configurations without Documentation
       ansible.builtin.import_role:
         name: arista.avd.eos_cli_config_gen
       vars:
         eos_cli_config_gen_documentation:
           enable: false

Removal of Ansible components

The following Ansible components have been removed from the arista.avd Ansible collection in version 5.0.0.

Component type Name Replacement
Filter arista.avd.convert_dicts The internal arista.avd.convert_dicts filter plugin is no longer used by AVD. The plugin is released as open source, so it can be copied and reused according to the license and copyright.
Filter arista.avd.hash_passphrase Use arista.avd.snmp_hash instead.
Filter arista.avd.generate_esi Use Jinja string concatenation instead like {{ <esi_prefix> ~ <short_esi> }}.
Filter arista.avd.generate_lacp_id Use the builtin replace filter instead like {{ <short_esi> \| replace(':', '.') }}.
Filter arista.avd.generate_route_target Use the builtin ansible.builtin.regex_replace filter instead like {{ <short_esi> \| ansible.builtin.regex_replace('(\\d{2})(\\d{2}):(\\d{2})(\\d{2}):(\\d{2})(\\d{2})', '\\1:\\2:\\3:\\4:\\5:\\6') }}.
Action plugin/Module arista.avd.deploy_to_cv Use arista.avd.cv_workflow instead.
Action plugin/Module arista.avd.batch_template The internal arista.avd.batch_template action plugin is no longer used by AVD. The plugin is released as open source, so it can be copied and reused according to the license and copyright.
Action plugin/Module arista.avd.validate_and_template The internal arista.avd.validate_and_template action plugin is no longer used by AVD. The plugin is released as open source, so it can be copied and reused according to the license and copyright.
Action plugin/Module arista.avd.yaml_templates_to_facts The internal arista.avd.yaml_templates_to_facts action plugin is no longer used by AVD. The plugin is released as open source, so it can be copied and reused according to the license and copyright.
Action plugin/Module arista.avd._emit_warning The internal arista.avd._emit_warning action plugin is no longer used by AVD. The plugin is released as open source, so it can be copied and reused according to the license and copyright.
Role arista.avd.deploy_to_cv Use arista.avd.cv_deploy instead.

Changes to role arista.avd.eos_designs

Removal of deprecated eos_designs data models

The following data model keys have been removed from eos_designs in AVD 5.0.0.

Removed key New key
cvp_instance_ip cvp_instance_ips
<connected_endpoints_key>[].adapters[].port_channel.short_esi <connected_endpoints_key>[].adapters[].ethernet_segment.short_esi
network_ports[].port_channel.short_esi network_ports[].ethernet_segment.short_esi
port_profiles[].port_channel.short_esi port_profiles[].ethernet_segment.short_esi
<node_type_key>.defaults.inband_management_subnet <node_type_key>.defaults.inband_mgmt_subnet
<node_type_key>.defaults.inband_management_vlan <node_type_key>.defaults.inband_mgmt_vlan
<node_type_key>.node_groups[].nodes[].inband_management_subnet <node_type_key>.node_groups[].nodes[].inband_mgmt_subnet
<node_type_key>.node_groups[].nodes[].inband_management_vlan <node_type_key>.node_groups[].nodes[].inband_mgmt_vlan
<node_type_key>.node_groups[].inband_management_subnet <node_type_key>.node_groups[].inband_mgmt_subnet
<node_type_key>.node_groups[].inband_management_vlan <node_type_key>.node_groups[].inband_mgmt_vlan
<node_type_key>.nodes[].inband_management_subnet <node_type_key>.nodes[].inband_mgmt_subnet
<node_type_key>.nodes[].inband_management_vlan <node_type_key>.nodes[].inband_mgmt_vlan
<network_services_key>[].vrfs[].svis[].ipv6_address_virtual <network_services_key>[].vrfs[].svis[].ipv6_address_virtuals
svi_profiles[].ipv6_address_virtual svi_profiles[].ipv6_address_virtuals
ptp ptp_settings

Deprecation of design.type

The variable design.type is used to select between different variants of default values for node_type_keys. In AVD 5.0.0 the default values of node_type_keys for the default design.type l3ls-evpn has been updated to combine all the default node type from all designs. This means it is no longer needed to set the design.type.

The default node_type_keys for the default design l3ls-evpn has been extended with the following node types:

  • l2spine copied from the spine type of the l2ls design.
  • l3spine copied from the l2ls design.
  • rr, p and pe copied from the mpls design.

The leaf type used by the l2ls design is already covered by the l2leaf type in the l3ls-evpn design.

To migrate an existing inventory using the l2ls design, the following changes are needed:

# Remove the design.type setting
- design:
-   type: l2ls

# Replace the type 'spine' with 'l2spine'
- type: spine
+ type: l2spine

- spine:
+ l2spine:
    ...

# Replace type the 'leaf' with 'l2leaf'
- type: leaf
+ type: l2leaf

- leaf:
+ l2leaf:
    ...

Default interface descriptions are changed for more consistency

With AVD version 5.0.0, the default interface descriptions have been changed to improve consistency. The detailed changes are described in the subsections below.

To revert all descriptions to 4.x syntax, follow the following steps:

  1. Add the following custom description template variables to the relevant group variable(s):

    router_id_loopback_description: "EVPN_Overlay_Peering"
vtep_loopback_description: "VTEP_VXLAN_Tunnel_Source"
default_underlay_p2p_ethernet_description: "P2P_LINK_TO_{peer!u}_{peer_interface}{vrf?<_vrf_}"
default_underlay_p2p_port_channel_description: "P2P_LINK_TO_{peer}_{peer_interface}"
underlay_l2_ethernet_description: "{peer!u}_{peer_interface}"
underlay_l2_port_channel_description: "{peer_node_group_or_uppercase_peer}_Po{peer_port_channel_id}"
mgmt_interface_description: "oob_management"
default_vrf_diag_loopback_description: "{vrf}_VTEP_DIAGNOSTICS"
default_connected_endpoints_description: "{endpoint}{endpoint_port?<_}"
default_connected_endpoints_port_channel_description: "{adapter_description_or_endpoint}{endpoint_port_channel?<_}"
default_network_ports_description: ""
default_network_ports_port_channel_description: "{adapter_description_or_endpoint}{endpoint_port_channel?<_}"
mlag_member_description: "MLAG_PEER_{mlag_peer}_{interface}"
mlag_port_channel_description: "MLAG_PEER_{mlag_peer}_Po{mlag_port_channel_id}"
mlag_peer_svi_description: "MLAG_PEER"
mlag_peer_l3_svi_description: "MLAG_PEER_L3_PEERING"
mlag_peer_l3_vrf_svi_description: "MLAG_PEER_L3_iBGP: vrf {vrf}"
mlag_peer_vlan_name: "MLAG_PEER"
mlag_peer_l3_vlan_name: "LEAF_PEER_L3"
mlag_peer_l3_vrf_vlan_name: "MLAG_iBGP_{vrf}"
mlag_bgp_peer_description: "{mlag_peer}"
overlay_bgp_peer_description: "{peer}"

  2. Move the value of the description key under port_channel to the new key endpoint_port_channel for all <connected_endpoints_keys.key> adapters:

    servers:
  - name: server01
    adapters:
      - <...>
        description: My adapter description
        port_channel:
-          description: My description that was added after the adapter description
+          endpoint_port_channel: My description that was added after the adapter description

  3. Move the value of the description key under port_channel to the new key endpoint_port_channel for all network_ports:

    network_ports:
  - <...>
    description: My ports description
    port_channel:
-      description: My description that was added after the adapter description
+      endpoint_port_channel: My description that was added after the adapter description

Router ID Loopback

The default interface description for Loopback0 has changed to ROUTER_ID for all designs. Previously, this description varied depending on the network design and chosen protocols.

The router_id_loopback_description or the deprecated overlay_loopback_description settings still takes precedence, so no changes will be seen if either of these are set.

The description can be reverted manually if needed:

  # Using the new 'router_id_loopback_description' which replaces the deprecated 'overlay_loopback_description'
+ router_id_loopback_description: "EVPN_Overlay_Peering"

VTEP Loopback

The default interface description for Loopback1 (or the interface set with vtep_loopback) has changed to VXLAN_TUNNEL_SOURCE. Previously, the description was VTEP_VXLAN_Tunnel_Source.

The description can be reverted manually if needed:

+ vtep_loopback_description: "VTEP_VXLAN_Tunnel_Source"

Underlay point-to-point L3 ethernet interfaces

The interface description for the L3 point-to-point interfaces has changed to P2P_<peer>_<peer_interface>_VRF_<vrf>. Previously the description was P2P_LINK_TO_<peer | upper>_<peer_interface>_vrf_<vrf>. The VRF suffix is only added when using uplink_type: p2p-vrfs.

The interfaces using this are routed uplinks and p2p_links defined under l3_edge or core_interfaces.

Setting the description directly on p2p_links defined under l3_edge or core_interfaces still takes precedence.

The default descriptions can be reverted manually if needed:

+ default_underlay_p2p_ethernet_description: "P2P_LINK_TO_{peer!u}_{peer_interface}{vrf?<_vrf_}"

The description fields support templates. See the input variables documentation for available fields.

Underlay point-to-point L3 port-channel interfaces

The interface description for the L3 point-to-point port-channels has changed to P2P_<peer>_<peer_interface>. Previously the default description was P2P_LINK_TO_<peer>_<peer_interface>.

The port-channels using this are p2p_links defined under l3_edge or core_interfaces.

Setting the description directly on p2p_links defined under l3_edge or core_interfaces still takes precedence.

In AVD 5.0.0 it is also possible to control the port-channel description separately by setting the description key under port_channel. It will replace the full port-channel interface description.

The default descriptions can be reverted manually if needed:

+ default_underlay_p2p_port_channel_description: "P2P_LINK_TO_{peer}_{peer_interface}"

The description fields support templates. See the input variables documentation for available fields.

Underlay L2 ethernet interfaces

The interface description for the L2 uplink/downlink interfaces has changed to L2_<peer>_<peer_interface>. Previously the description was <peer | upper>_<peer_interface>.

The interfaces using this are the member interfaces of port-channel uplinks.

The descriptions can be reverted manually if needed:

+ underlay_l2_ethernet_description: "{peer!u}_{peer_interface}"

The description field support templates. See the input variables documentation for available fields.

Underlay L2 port-channel interfaces

The interface description for the L2 uplink/downlink port-channels has changed to L2_<peer_node_group_or_peer>_<peer_interface>. Previously the default description was <peer_node_group_or_uppercase_peer>_Po<peer_port_channel_id>. The field peer_node_group_or_peer will contain the peer’s node group name for MLAG pairs or EVPN A/A nodes or the peer’s hostname for a single switch.

The port-channels using this are port-channel uplinks.

The descriptions can be reverted manually if needed:

+ underlay_l2_port_channel_description: "{peer_node_group_or_uppercase_peer}_Po{peer_port_channel_id}"

The description field support templates. See the input variables documentation for available fields.

Out-of-band management interface

The default interface description for the management interface has changed to OOB_MANAGEMENT. Previously, the description was oob_management.

The description can be reverted manually if needed:

+ mgmt_interface_description: "oob_management"

VRF diagnostic loopback interfaces

The default interface description for VRF diagnostic loopbacks has changed to DIAG_VRF_<vrf>. Previously the default description was <vrf>_VTEP_DIAGNOSTICS.

Setting the description directly on loopback_description defined under vtep_diagnostic still takes precedence.

The default descriptions can be reverted manually if needed:

+ default_vrf_diag_loopback_description: "{vrf}_VTEP_DIAGNOSTICS"

The description fields support templates. See the input variables documentation for available fields.

Connected Endpoints ethernet interfaces

The default interface description for the connected endpoints has changed to <endpoint_type>_<endpoint>_<endpoint_port>. Previously, the description was <endpoint>_<endpoint_port>.

Setting the description directly on the connected endpoint adapter still takes precedence. The description fields support templates. See the input variables documentation for available fields.

The default descriptions can be reverted manually if needed:

+ default_connected_endpoints_description: "{endpoint}{endpoint_port?<_}"

Connected Endpoints port-channel interfaces

The default interface description for the connected endpoints has changed to <endpoint_type>_<endpoint>_<endpoint_port_channel>. Previously the description was <adapter_description or endpoint>_<port_channel_description>, so the description field set under port_channel was always added after the adapter description or name of the endpoint.

In AVD 5.0.0 setting the description key under port_channel of the adapter will replace the full port-channel interface description. The description fields support templates. See the input variables documentation for available fields.

To retain the previous descriptions, the value of the description key under port_channel must be moved to the new key endpoint_port_channel for all adapters. Also, the default description template must be updated.

 servers:
   - name: server01
     adapters:
       - <...>
         description: My adapter description
         port_channel:
-          description: My description that was added after the adapter description
+          endpoint_port_channel: My description that was added after the adapter description

+ default_connected_endpoints_port_channel_description: "{adapter_description_or_endpoint}{endpoint_port_channel?<_}"

Network Ports ethernet interfaces

The default interface description for the network_ports data model has changed to <endpoint>, adding a new endpoint key under network_ports similar to the endpoint name under connected endpoints. Previously, there was no default description.

Setting the description directly under network_ports still takes precedence. The description fields support templates. See the input variables documentation for available fields.

Example
network_ports data
network_ports:
  - switches: [ s1-leaf1 ]
    switch_ports: [ Ethernet10-11 ]
    endpoint: printers
    mode: access
    vlans: "10"
Rendered configuration
interface Ethernet10
  description printers
  no shutdown
  switchport access vlan 10
  switchport mode access
  switchport
!
interface Ethernet11
  description printers
  no shutdown
  switchport access vlan 10
  switchport mode access
  switchport
!

The default descriptions can be reverted manually if needed:

+ default_network_ports_description: ""

Network Ports port-channel interfaces

The default interface description for port-channels under the network_ports data model has changed to <endpoint>_<endpoint_port_channel>, adding a new endpoint key under network_ports, which is used similarly to the endpoint name under connected endpoints. Previously the description was <network_port_description>_<port_channel_description>, so the description field set under port_channel was always added after the description set directly under the network_ports.

In AVD 5.0.0, setting the description key under port_channel of the network port will replace the full port-channel interface description. The description fields support templates. See the input variables documentation for available fields.

To retain the previous descriptions, the value of the description key under port_channel must be moved to the new key endpoint_port_channel for all network_ports. Also, the default description template must be updated.

 network_ports:
   - <...>
     description: My ports description
     port_channel:
-      description: My description that was added after the adapter description
+      endpoint_port_channel: My description that was added after the adapter description

+ default_network_ports_port_channel_description: "{adapter_description_or_endpoint}{endpoint_port_channel?<_}"

The interface description for the MLAG peer-link ethernet interfaces has changed to MLAG_{mlag_peer}_{peer_interface}. Previously, the description was MLAG_PEER_{mlag_peer}_{interface} so using the local interface instead of the peer’s. The MLAG interfaces are often the same, so this is a minor issue.

The description can be reverted manually if needed:

+ mlag_member_description: "MLAG_PEER_{mlag_peer}_{interface}"

The interface description for the MLAG peer-link port-channel interfaces has changed to MLAG_{mlag_peer}_{peer_interface}. Previously, the description was MLAG_PEER_{mlag_peer}_Po{mlag_port_channel_id}, so using the local port-channel ID instead of the peer’s. The MLAG interfaces are often the same, so this is a minor issue.

The description can be reverted manually if needed:

+ mlag_port_channel_description: "MLAG_PEER_{mlag_peer}_Po{mlag_port_channel_id}"

MLAG peer VLAN interface

The interface description for the MLAG peer SVI has changed to MLAG. Previously, it was MLAG_PEER.

The description can be reverted manually if needed:

+ mlag_peer_svi_description: "MLAG_PEER"

The description setting supports a template. See the input variables documentation for available fields.

MLAG L3 peering VLAN interface

The interface description for the MLAG L3 peering SVI has changed to MLAG_L3. Previously, it was MLAG_PEER_L3_PEERING.

The description can be reverted manually if needed:

+ mlag_peer_l3_svi_description: "MLAG_PEER_L3_PEERING"

The description setting supports a template. See the input variables documentation for available fields.

MLAG L3 VRF peering VLAN interface

The interface description for the MLAG L3 VRF peering SVI has changed to MLAG_L3_VRF_{vrf}. Previously, the description was MLAG_PEER_L3_iBGP: vrf {vrf}.

The description can be reverted manually if needed:

+ mlag_peer_l3_vrf_svi_description: "MLAG_PEER_L3_iBGP: vrf {vrf}"

The description setting supports a template. See the input variables documentation for available fields.

Default VLAN names are changed for more consistency

MLAG peer VLAN

The name of the MLAG peer VLAN (VLAN 4094 by default) has changed to MLAG. Previously, the name was MLAG_PEER.

The name can be reverted manually if needed:

+ mlag_peer_vlan_name: "MLAG_PEER"

The setting supports a template. See the input variables documentation for available fields.

MLAG L3 peering VLAN

The name of the MLAG L3 peering VLAN (VLAN 4093 by default) has changed to MLAG_L3. Previously, the name was LEAF_PEER_L3.

The name can be reverted manually if needed:

+ mlag_peer_l3_vlan_name: "LEAF_PEER_L3"

The setting supports a template. See the input variables documentation for available fields.

MLAG L3 VRF peering VLAN

The name of the MLAG L3 VRF peering VLAN has changed to MLAG_L3_VRF_{vrf}. Previously, the name was MLAG_iBGP_{vrf}.

The name can be reverted manually if needed:

+ mlag_peer_l3_vrf_vlan_name: "MLAG_iBGP_{vrf}"

The setting supports a template. See the input variables documentation for available fields.

Default BGP peer descriptions are changed for more consistency

MLAG L3 peering

The description of the MLAG L3 BGP peers, including those in VRFs, has changed to {mlag_peer}_{peer_interface}. Previously, the description was {mlag_peer}.

The description can be reverted manually if needed:

+ mlag_bgp_peer_description: "{mlag_peer}"

The setting supports a template. See the input variables documentation for available fields.

Overlay peerings

The description of the overlay BGP peers (EVPN, MPLS, WAN) has changed to {peer}{peer_interface?<_}. Previously, the description was {peer}.

The description can be reverted manually if needed:

+ overlay_bgp_peer_description: "{peer}"

The setting supports a template. See the input variables documentation for available fields.

Combine the VLAN trunk groups used for MLAG

With AVD version 5.0.0 a single MLAG trunk group is used for MLAG and MLAG L3 peerings, including the peerings in VRFs. Previously, MLAG L3 peerings used a separate LEAF_PEER_L3 trunk group.

The trunk group for MLAG L3 peerings can be reverted if needed:

+ trunk_groups:
+   mlag_l3:
+     name: LEAF_PEER_L3

With AVD version 5.0.0, the subnet of VRF L3 peering VLANs between MLAG peers is no longer redistributed into BGP by default. Previously, all connected routes were redistributed to BGP.

To retain the previous behavior, set redistribute_mlag_ibgp_peering_vrfs to true per tenant or VRF:

tenants:
  - name: Tenant_A
+   redistribute_mlag_ibgp_peering_vrfs: true
    <...>
    vrfs:
      - name: Tenant_A_OP
+       redistribute_mlag_ibgp_peering_vrfs: true
        <...>

The default value true of data model mlag_on_orphan_port_channel_downlink has been changed to false, so it is now required to set mlag_on_orphan_port_channel_downlink: true to configure the MLAG ID on a downlink Port-Channel even if the downlink is only on one node in the MLAG pair. By default, an MLAG ID will only be configured on Port-Channel downlinks that are dual-homed to two MLAG switches.

+ mlag_on_orphan_port_channel_downlink: true

MLAG L3 Peering VLAN 4093 is no longer created when underlay_routing_protocol: 'none'

AVD versions below 5.0.0 created an MLAG L3 peering on VLAN 4093, even when no L3 MLAG peering was created using an underlay routing protocol. This happened in cases where underlay_routing_protocol was set to none.

In AVD version 5.0.0 the MLAG L3 peering VLAN 4093 is not longer created when underlay_routing_protocol is 'none'. Instead, an MLAG peering VLAN will be created for VRF default, if it is defined under network services, using the same MLAG peer VLAN logic as for other VRFs; <mlag_ibgp_peering_vrfs.base_vlan - default 3000> - 1 + <vrf_id>.

The peer VLAN config can be retained by setting mlag_ibgp_peering_vlan: 4093 under the VRF, by using custom_structured_configuration or by setting underlay_routing_protocol to a valid option besides none.

Structured Configuration merged from SVI profiles is now deep merged instead of replaced

When merging structured_config from SVI profiles and parent profiles, AVD versions below 5.0.0 replaced the entire structured_config object with the most specific definition of structured_config.

With AVD version 5.0.0, structured_config is now deep-merged, the same as for other profiles in AVD. This allows the user to contribute different parts of the structured_config from profiles or parent profiles.

Example:

svi_profiles:
  - name: TEST1
    parent_profile: TEST2
    structured_config:
      no_autostate: true
  - name: TEST2
    structured_config:
      description: foo

tenants:
  - name: mytenant
    vrfs:
      - name: myvrf
        svis:
          - id: 10
            profile: TEST1
            structured_config:
              no_autostate: false

With AVD versions below 5.0.0 this produced an effective structured_config for SVI 10 of:

no_autostate: false

Only the most specific entry got applied.

With AVD version 5.0.0, the same inputs will produce an effective structured_config for SVI 10 of:

description: foo      # <-- Inherited from profile which inherited from parent_profile
no_autostate: false   # <-- Set on SVI, overriding the setting from svi_profile

Depending on the complexity of the deployment, changes to the SVI and profiles may be required to retain the previous configuration output.

vrf_id is used instead of vrf_vni to calculate the IP address of EVPN underlay multicast group for a VRF

AVD versions below 5.0.0 use vrf_vni in the algorithm to set the offset in order to get the IP address of the EVPN underlay multicast group.

In AVD version 5.0.0, vrf_id is used instead of vrf_vni to calculate the offset for IP address of EVPN underlay multicast group for a VRF when evpn_l3_multicast is enabled. The configurations will only change in case vrf_id and vrf_vni are set to different values or evpn_l3_multicast.evpn_underlay_l3_multicast_group is set under vrfs.

To retain the previous configuration, set the group IP directly under the vrfs using evpn_l3_multicast.evpn_underlay_l3_multicast_group.

tenants:
  - name: Tenant_C
    evpn_l3_multicast:
      enabled: true
    vrfs:
      - name: TEN_C_L3_MULTICAST_ENABLED_130_131
        evpn_l3_multicast:
          enabled: true
+         evpn_underlay_l3_multicast_group: 232.0.64.2
        <...>

Removed redistribute igmp from BGP VLAN config belonging to a VRF with EVPN Multicast

AVD versions below 5.0.0 configure redistribute igmp under BGP for all SVIs when evpn_l2_multicast is true, but configuring redistribute igmp with both L2 and L3 EVPN Multicast enabled will take up additional control-plane and data-plane resources.

In AVD version 5.0.0, the redistribute igmp is configured by default only when evpn_l2_multicast is set to true and evpn_l3_multicast for the VRF is set to false. To retain the previous behavior for SVIs under BGP, where both evpn_l2_multicast and evpn_l3_multicast are enabled, set the always_redistribute_igmp key to true for either all SVIs within the Tenant or for each SVI individually.

tenants:
  - name: Tenant_B
    evpn_l3_multicast:
      enabled: true
      <...>
    evpn_l2_multicast:
      enabled: true
+     always_redistribute_igmp: true
      <...>
  - name: Tenant_C
    evpn_l3_multicast:
      enabled: true
      <...>
    evpn_l2_multicast:
      enabled: true
      <...>
    vrfs:
      - name: TEN_C_L3_MULTICAST_ENABLED
        svis:
          - id: 136
            name: "L3_L2_MULTICAST_ENABLED_136"
            evpn_l2_multicast:
+             always_redistribute_igmp: true

Only render IGMP snooping querier version and address when enabled

In AVD 4.0.0, the ip igmp snooping vlan command for version and address was rendered even when the IGMP snooping querier was not enabled. Starting from AVD 5.0.0, the ip igmp snooping vlan command for version and address is rendered only when the IGMP snooping querier is enabled.

To retain the previous configuration, use custom structured configuration.

custom_structured_configuration_ip_igmp_snooping:
  vlans:
  - id: 1
    querier:
      enabled: false
      address: 192.168.255.1
      version: 3

Connected endpoints and network ports now render PoE and 802.1x configuration for port-channel members and ignore PoE and 802.1x from LACP fallback individual profile

With AVD version 5.0.0, port-channel members generated from connected endpoints or network_ports will now include 802.1x (dot1x) and PoE (poe) configuration. Previously, the member interface configuration only included dot1x or poe if it was defined under the port profile set in lacp_fallback.individual.profile. The LACP fallback individual profiles now ignores any dot1x or poe settings.

It may be required to move the dot1x and poe settings from the fallback profile to the adapter profile:

 port_profiles:
   - name: MY_LACP_INDIVIDUAL_FALLBACK_PROFILE
     <...>
-    poe:
-      <...>
-    dot1x:
-      <...>
   - name: MY_SERVER_PROFILE
     <...>
+    poe:
+      <...>
+    dot1x:
+      <...>

servers:
  - name: MYSERVER1
    adapters:
      - <...>
        profile: MY_SERVER_PROFILE
        port_channel:
          <...>
          lacp_fallback:
            mode: individual
            individual:
              profile: MY_LACP_INDIVIDUAL_FALLBACK_PROFILE

No changes are needed if the LACP fallback individual profile is the same as the adapter profile.

The default platform settings for R3-series now have the TCAM profile “vxlan-routing”

Starting AVD 5.0.0, the default platform settings for 7280R3, 7500R3 and 7800R3 platforms now contain tcam_profile: vxlan-routing This change is based on a new Arista best practice for VXLAN deployments with the R3-series. Not using this TCAM profile can lead to incorrect handling of VXLAN IPv6 NS packets.

Warning

Since applying a TCAM profile will cause reprogramming of the forwarding processor, it can lead to disturbances to the network services.

Please work with your Arista account team to decide if the new default is the right choice for your network and how to apply it.

To retain the previous configuration with no TCAM profile, the default platform settings can be overridden with the new custom_platform_settings key:

custom_platform_settings:
  - platforms:
      - 7280R3
    reload_delay:
      mlag: 900
      non_mlag: 1020
  - platforms:
      - 7500R3
      - 7800R3
    management_interface: Management0
    reload_delay:
      mlag: 900
      non_mlag: 1020

Shutdown interfaces and BGP towards undeployed peers by default

In AVD 4.0.0, the default value of shutdown_bgp_towards_undeployed_peers and shutdown_interfaces_towards_undeployed_peers was false. In AVD 5.0.0, the default value of shutdown_bgp_towards_undeployed_peers and shutdown_interfaces_towards_undeployed_peers is changed to true.

To retain the previous behavior, set the value to false:

+ shutdown_bgp_towards_undeployed_peers: false
+ shutdown_interfaces_towards_undeployed_peers: false

BGP is now configured for Network services VRFs even if ‘evpn’ is not part of the address-families

AVD versions below 5.0.0 did not generate BGP configuration for VRFs unless the node type included evpn, vpn-ipv4 or vpn-ipv6 under default_overlay_address_families and the VRF had the same evpn, vpn-ipv4 or vpn-ipv6 defined under address_families (default is ['evpn']).

AVD version 4.6.0 introduced the toggle new_network_services_bgp_vrf_config: <bool; default=false> to change this behavior by no longer requiring evpn in the address-families, but instead it always configured BGP for all VRFs. This toggle has been removed in AVD 5.0.0 since this is now part of the default behavior.

With AVD version 5.0.0, the logic of whether to configure BGP for a network services VRF has been improved with the following rules:

  • New: Always/never configure BGP for the VRF according to the new optional bgp.enabled setting. This takes precedence over all other rules.
  • Existing: If the VRF is part of an overlay (evpn, vpn-ipv4 or vpn-ipv6), BGP will be configured for the VRF.
  • New: If any BGP peers are configured under the VRF, BGP will be configured for the VRF. This is useful for L2LS designs with VRFs.
  • Improved: If uplink type is p2p-vrfs and the VRF is included in the uplink VRFs, BGP will be configured for the VRF.

It is possible to forcefully add or remove BGP configuration per VRF by setting:

<network_services_key e.g. tenants>:
  - name: mytenant
    vrfs:
      - name: myvrf
        bgp:
          enabled: <bool>  # <-- New optional setting to either always or never configure BGP for the VRF

default_overlay_address_families and overlay_address_families no longer accepts a string

Starting AVD 5.0.0, node_type_keys[].default_overlay_address_families and <node_type_key>.defaults.overlay_address_families only accept a list of strings. Previously, they also accepted a string, which was automatically converted to a list.

  node_type_keys:
    - key: my_node_type
      type: my_node_type
-     default_overlay_address_families: "evpn"
+     default_overlay_address_families: ["evpn"]

  <node_type_key - ex. l3leaf>:
    defaults:
-     overlay_address_families: "vpn-ipv4"
+     overlay_address_families: ["vpn-ipv4"]
    node_groups:
      - group: mygroup
-       overlay_address_families: "vpn-ipv4"
+       overlay_address_families: ["vpn-ipv4"]
        nodes:
          - name: leaf1
-           overlay_address_families: "vpn-ipv6"
+           overlay_address_families: ["vpn-ipv6"]
    nodes:
      - name: leaf2
-       overlay_address_families: "vpn-ipv6"
+       overlay_address_families: ["vpn-ipv6"]

mpls_route_servers no longer accepts a string

Starting AVD 5.0.0, <node_type_key>.defaults.mpls_route_servers only accepts a list of strings. Previously, it also accepted a string, which was automatically converted to a list.

  node_type_keys:
    - key: my_node_type
      type: my_node_type
-     mpls_route_servers: "10.10.10.10"
+     mpls_route_servers: ["10.10.10.10"]

  <node_type_key - ex. l3leaf>:
    defaults:
-     mpls_route_servers: "10.10.10.10"
+     mpls_route_servers: ["10.10.10.10"]
    node_groups:
      - group: mygroup
-       mpls_route_servers: "10.10.10.10"
+       mpls_route_servers: ["10.10.10.10"]
        nodes:
          - name: leaf1
-           mpls_route_servers: "20.20.20.20"
+           mpls_route_servers: ["20.20.20.20"]
    nodes:
      - name: leaf2
-       mpls_route_servers: "10.10.10.10"
+       mpls_route_servers: ["20.20.20.20"]

Default value for OSPF area has been updated to 0.0.0.0

With AVD version 5.0.0, the default value for the OSPF area has been updated to “0.0.0.0” to align with EOS’s interpretation of the value “0”.

To revert this behavior, please update your inventory as follows:

tenants:
  - name: TENANT_A
    vrfs:
      - name: TENANT_B_INTRA
        vrf_id: 19
        ospf:
          enabled: true
          router_id: 10.123.1.0
        l3_interfaces:
          - description: TENANT_A_SITE_3_INTRA_L3VPN
            enabled: true
            interfaces:
              - Ethernet6.10
            ip_addresses:
              - 10.123.1.0/31
            nodes:
              - SITE1-LER1
            ospf:
              enabled: true
+             area: 0
              cost: 10
        loopbacks:
          - loopback: 123
            ip_address: 10.1.53.0/32
            node: DC1-LEAF2A
            description: Test-Loopback
            enabled: true
            ospf:
              enabled: true
+             area: 0
        svis:
          - id: 113
            name: Tenant_A_OP_Zone_4
            tags: [ DC1_LEAF1 ]
            enabled: True
            ospf:
              enabled: true
+             area: 0

Default value of isis_system_id_format is changed to underlay_loopback

In AVD 4.0.0, node_id was the default value of isis_system_id_format. In AVD 5.0.0, this default value has changed to underlay_loopback.

To retain the previous behavior, set the value back to node_id:

+ isis_system_id_format: node_id

custom_structured_configuration_prefix no longer accepts a string

Starting AVD 5.0.0, custom_structured_configuration_prefix only accepts a list of strings. Previously it also accepted a string, which was autoconverted to a list.

- custom_structured_configuration_prefix: myprefix
+ custom_structured_configuration_prefix: ["myprefix"]

An error is raised if sFlow is enabled on an interface but sflow_settings.destinations is not set

In AVD 4.0.0, if sflow was enabled on an interface but sflow_settings.destinations was not defined, the sFlow configuration was still generated for interfaces. However, it would not work without “custom structured configuration”.

As of AVD 5.0.0, if sflow is enabled on an interface but sflow_settings.destinations is not set, an error is raised and the execution stops.

In AVD 4.0.0, the default MTU for Dps1, WAN HA, and WAN p2p uplink interfaces was 9214. AVD 5.0.0, changed the default MTU for Dps1, WAN HA, and WAN p2p uplink interfaces to 9194.

To retain the previous MTU on the WAN HA interfaces, set <node_type>.defaults/node_groups[]/node_groups[].nodes[]/nodes[].wan_ha.mtu as 9214.

wan_router:
  node_groups:
    - group: SITE_HA_ENABLED
      wan_ha:
        enabled: true
        ha_interfaces: [Ethernet52]
+       mtu: 9214

To retain the previous MTU on the Dps1 interface, use custom structured configuration.

custom_structured_configuration_dps_interfaces:
  - name: Dps1
+   mtu: 9214

To retain the previous MTU on the WAN p2p uplink interfaces, use custom_platform_settings.

custom_platform_settings:
  - feature_support:
      bgp_update_wait_for_convergence: true
      bgp_update_wait_install: false
      interface_storm_control: false
      queue_monitor_length_notify: false
    management_interface: Management1/1
+   p2p_uplinks_mtu: 9214
    platforms:
      - AWE-5310
      - AWE-5510
      - AWE-7250R
      - AWE-7230R
  - feature_support:
      bgp_update_wait_for_convergence: true
      bgp_update_wait_install: false
      interface_storm_control: false
      poe: true
      queue_monitor_length_notify: false
    management_interface: Management1
+   p2p_uplinks_mtu: 9214
    platforms:
      - AWE-7220R

Default encapsulation for WAN EVPN iBGP peerings changed to path-selection

With AVD version 5.0.0, the default encapsulation used for EVPN iBGP peering between WAN routers is path-selection. Previously, it was vxlan.

Danger

The path-selection encapsulation is only supported on EOS above 4.33.0F.

It is critical that all WAN devices use the same encapsulation. For existing deployments, it is recommended to set the encapsulation back to vxlan until a migration can be done across the entire WAN network.

Contact your Arista account team for guidance on migration.

To retain the vxlan encapsulation on WAN EVPN iBGP peerings, use wan_encapsulation:

+ wan_encapsulation: vxlan

For WAN direct HA, AVD will now configure a port-channel by default. This feature was introduced in EOS 4.33.0F.

To retain the previous configuration, leverage custom_platform_settings and set use_port_channel_for_direct_ha: false under wan_ha.

  wan_router:
    node_groups:
      - group: Site42
        cv_pathfinder_region: AVD_Land_West
        cv_pathfinder_site: Site42
        wan_ha:
          enabled: true
+         use_port_channel_for_direct_ha: false
          ha_interfaces: [Ethernet52]
          ha_ipv4_pool: 10.10.10.0/24

The base class for custom interface descriptions AvdInterfaceDescriptions was moved

The AvdInterfaceDescriptions class and the associated InterfaceDescriptionData data class were moved from the Ansible collection to pyavd.api.interface_descriptions. Import statements must be updated.

- from ansible_collections.arista.avd.roles.eos_designs.python_modules.interface_descriptions import AvdInterfaceDescriptions, InterfaceDescriptionData
+ from pyavd.api.interface_descriptions import AvdInterfaceDescriptions, InterfaceDescriptionData

Some methods of the AvdInterfaceDescriptions class were collapsed. The following table indicates the removed methods and the replacement ones to adjust the code. Note that the new method signatures are different.

Removed method signature Replacement method signature
underlay_ethernet_interfaces(self, link_type: str, link_peer: str, link_peer_interface: str) -> str underlay_ethernet_interface(self, data: InterfaceDescriptionData) -> str
underlay_port_channel_interfaces(self, link_peer: str, link_peer_channel_group_id: int, link_channel_description: str) -> str: underlay_port_channel_interface(self, data: InterfaceDescriptionData) -> str
mlag_ethernet_interfaces(self, mlag_interface: str) -> str: mlag_ethernet_interface(self, data: InterfaceDescriptionData) -> str
mlag_port_channel_interfaces(self) -> str: mlag_ethernet_interface(self, data: InterfaceDescriptionData) -> str
connected_endpoints_ethernet_interfaces(self, peer: str = None, peer_interface: str = None, adapter_description: str = None) -> str: connected_endpoint_ethernet_interface(self, data: InterfaceDescriptionData) -> str
connected_endpoints_port_channel_interfaces(self, peer: str = None, adapter_description: str = None, adapter_port_channel_description: str = None) -> str: connected_endpoint_port_channel_interface(self, data: InterfaceDescriptionData) -> str
overlay_loopback_interface(self, overlay_loopback_description: str = None) -> str router_id_loopback_interface(self, data: InterfaceDescriptionData) -> str
vtep_loopback_interface(self) -> str vtep_loopback_interface(self, data: InterfaceDescriptionData) -> str

For any method that was not previously overwritten, there should be no output change as compared to AVD 4.10.x.

Base class for custom IP addressing AvdIpAddressing was moved

The AvdIpAddressing class was moved from the Ansible collection to pyavd.api.ip_addressing. Import statements must be updated.

- from ansible_collections.arista.avd.roles.eos_designs.python_modules.ip_addressing import AvdIpAddressing
+ from pyavd.api.ip_addressing import AvdIpAddressing

Changes to role arista.avd.eos_cli_config_gen

Removal of deprecated eos_cli_config_gen data models

The following data model keys have been removed from eos_cli_config_gen in AVD 5.0.0.

Removed key New key
cvcompression -
event_handlers.action event_handlers.actions.bash_command
event_handlers.action_type event_handlers.actions
event_handlers.regex event_handlers.trigger_on_logging.regex
flow_trackings flow_tracking
management_api_gnmi.enable_vrfs management_api_gnmi.transport.grpc
management_api_gnmi.octa management_api_gnmi.provider
management_security.entropy_source management_security.entropy_sources
name_server ip_name_servers
port_channel_interfaces.esi port_channel_interfaces.evpn_ethernet_segment.identifier
port_channel_interfaces.rt port_channel_interfaces.evpn_ethernet_segment.route_target
radius_servers radius_server.hosts
router_bgp.peer_groups[].peer_filter router_bgp.listen_ranges[].peer_filter
router_bgp.peer_groups[].bgp_listen_range_prefix router_bgp.listen_ranges[].prefix
router_bgp.address_family_ipv4.peer_groups[].next_hop.address_family_ipv6_originate router_bgp.address_family_ipv4.peer_groups[].next_hop.address_family_ipv6
router_bgp.vrfs[].neighbors[].prefix_list_in router_bgp.vrfs[].address_family_ipv4.neighbors[].prefix_list_in or router_bgp.vrfs[].address_family_ipv6.neighbors[].prefix_list_in
router_bgp.vrfs[].neighbors[].prefix_list_in router_bgp.vrfs[].address_family_ipv4.neighbors[].prefix_list_out or router_bgp.vrfs[].address_family_ipv6.neighbors[].prefix_list_out
router_bgp.vrfs[].address_families router_bgp.vrfs[].address_family_*
router_isis.address_family router_isis.address_family_ipv4.enabled or router_isis.address_family_ipv6.enabled
router_isis.isis_af_defaults router_isis.address_family_ipv4 or router_isis.address_family_ipv6
snmp_server.views.MIB_family_name snmp_server.views.mib_family_name
stun.server.local_interface stun.server.local_interfaces
vlan_interfaces[].ipv6_address_virtual vlan_interfaces[].ipv6_address_virtuals
vlan_interfaces[].ipv6_virtual_router_address vlan_interfaces[].ipv6_virtual_router_addresses
vlan_interfaces[].vrrp vlan_interfaces[].vrrp_ids

No auto-conversion of old data model for router_bgp.redistribute_routes and router_bgp.vrfs[].redistribute_routes

The change has been incorporated into eos_designs, so action is only required when defining new interfaces with structured_config, custom_structured_configuration_, or when using eos_cli_config_gen directly.

The data models for router_bgp.redistribute_routes and router_bgp.vrfs[].redistribute_routes previously supported either a list of strings or a dict-of-dicts. In AVD 4.0.0, this was changed to a list-of-dicts with automatic conversion from any previous models into the new one.

As of AVD 5.0.0, the automatic conversion from both of the previous models has been removed, so the input data must be updated to the new data models.

# Previous list data model
router_bgp:
  redistribute_routes:
    - connected
    - static
  vrfs:
    - name: test
      redistribute_routes:
        - connected
        - static

# Previous dict-of-dicts data model
router_bgp:
  redistribute_routes:
    connected:
      route_map: connected-to-bgp
    static:
      route_map: static-to-bgp
  vrfs:
    - name: test
      redistribute_routes:
        connected:
          route_map: connected-to-bgp
        static:
          route_map: static-to-bgp

# New data model
router_bgp:
  redistribute_routes:
    - source_protocol: connected
    - source_protocol: static
  vrfs:
    - name: test
      redistribute_routes:
        - source_protocol: connected
        - source_protocol: static

# New data model
router_bgp:
  redistribute_routes:
    - source_protocol: connected
      route_map: connected-to-bgp
    - source_protocol: static
      route_map: static-to-bgp
  vrfs:
    - name: test
      redistribute_routes:
        - source_protocol: connected
          route_map: connected-to-bgp
        - source_protocol: static
          route_map: static-to-bgp

!RANCID-CONTENT-TYPE: arista is no longer at the top of the generated configurations

As of AVD 5.0.0, the !RANCID-CONTENT-TYPE: arista line at the top of the configuration has been removed.

It can be added if required by using config_comment:

+ config_comment: "RANCID-CONTENT-TYPE: arista"

Default EOS configuration is no longer automatically generated

The generate_default_config setting controls the generation of some default EOS configurations. This was previously set to true by default.

As of AVD 5.0.0, the default value of generate_default_config has been changed to false to prevent the generation of any configuration not specified by the inputs to eos_cli_config_gen (structured configuration).

The following commands will be generated when generate_default_config is set to true:

  • RANCID Content Type
  • Hostname
  • Default configuration no aaa root
  • Default configuration no enable password
  • Transceiver qsfp default mode
  • End of configuration delimiter

The setting generate_default_config will be removed in AVD 6.0.0.

The following eos_cli_config_gen inputs can be defined as needed to generate the same configuration:

- generate_default_config: true
+ aaa_root:
+   disabled: true
+ config_comment: "RANCID-CONTENT-TYPE: arista"
+ config_end: true
+ enable_password:
+   disabled: true
+ hostname: "{{ inventory_hostname }}"
+ transceiver_qsfp_default_mode_4x10: true

All changes except "RANCID-CONTENT-TYPE: arista" have been incorporated into eos_designs. Action is only required when using eos_cli_config_gen directly, or if the RANCID-CONTENT-TYPE: arista is required.

monitor_sessions no longer requires both monitor_sessions.sources and monitor_sessions.destinations to be defined for generating configuration

In AVD 4.0.0, monitor_sessions required both monitor_sessions.sources and monitor_sessions.destinations for configuration to be generated, but EOS does not require this.

As of AVD 5.0.0, monitor_sessions configuration will be generated even if monitor_sessions.sources or monitor_sessions.destinations are not defined. To revert this behavior update your inventory to remove the configuration.

router_isis.address_family_ipv4/6.enabled is now required to generate the configuration and documentation for router_isis address-families

AVD 4.0.0 generated the ISIS address-family configuration and documentation independently of the router_isis.address_family_ipv4/6.enabled key.

As of AVD 5.0.0, router_isis.address_family_ipv4/6.enabled must be set to generate the configuration and documentation for router_isis address-families.

 router_isis:
   address_family_ipv4:
+    enabled: true
     <...>
   address_family_ipv6:
+    enabled: true
     <...>

ip_security.sa_policies[].esp.integrity and .encryption null option has been replaced with disabled

In AVD 4.0.0 we had “null” as a valid value for esp integrity and encryption to apply the null security profile and encryption under the ip-security configuration.

As of AVD 5.0.0 “null” option for esp integrity and encryption has been replaced with “disabled” to apply the null security profile and encryption under the ip-security configuration.

 ip_security:
   sa_policies:
     name: Disabled
     esp:
-      integrity: "null"
-      encryption: "null"
+      integrity: disabled
+      encryption: disabled

router_ospf.redistribute.bgp/connected/static data model has been updated to require the enabled key

To avoid ambiguous YAML data input, the data model for router_ospf.redistribute.bgp/connected/static has been updated to require the enabled key.

router_ospf:
  process_ids:
    - id: 400
      redistribute:
-       bgp: {}
-       connected: {}
-       static: {}
+       bgp:
+         enabled: True
+       connected:
+         enabled: True
+       static:
+         enabled: True

The change has been incorporated into eos_designs, so action is only required when directly defining structured_configuration.

router_traffic_engineering.enabled is required

In AVD 4.0.0, setting enabled: true under router_traffic_engineering was not required.

As of AVD 5.0.0, the enabled keyword is required under router_traffic_engineering:

router_traffic_engineering:
+ enabled: true

Removal of type key dependency for rendering ethernet/port-channel interfaces configuration and documentation

In AVD 4.0.0, the default value for ethernet_interfaces[].type and port_channel_interfaces[].type was “switched”, configuring the interfaces as switchports unless another type was set.

With AVD 5.0.0 the type in ethernet_interfaces and port_channel_interfaces is no longer required and does not control the rendered configuration, when using the new models described below.

vlan_id configuration

In AVD 4.0.0, the configuration for vlan_id in ethernet interfaces and port-channel interfaces was rendered only if ethernet_interfaces[].type or port_channel_interfaces[].type was set to l2dot1q.

With AVD 5.0.0, the dependency on the type key for rendering the configuration of vlan_id in ethernet and port-channel interfaces has been removed.

 ethernet_interfaces:
   - name: Ethernet1.10
-    type: l2dot1q
     vlan_id: 10
!
 port_channel_interfaces:
   - name: Port-Channel1.10
-    type: l2dot1q
     vlan_id: 10

switchport configuration and documentation

In AVD 4.0.0, the configuration and documentation for switchport in ethernet and port-channel interfaces were rendered only if ethernet_interfaces[].type or port_channel_interfaces[].type was set to switched along with the keys mode, vlans, native_vlan, native_vlan_tag, trunk_groups, phone, vlan_translations, trunk_private_vlan_secondary, pvlan_mapping. The no switchport command was rendered if ethernet_interfaces[].type or port_channel_interfaces[].type was set to routed.

With AVD 5.0.0, a new key for switchport has been introduced under the ethernet and port-channel interfaces data model. This key generates the configuration and documentation for switchport independent of the type key. The keys mode, vlans, native_vlan, native_vlan_tag, trunk_groups, phone, vlan_translations, trunk_private_vlan_secondary, and pvlan_mapping are deprecated. They will be removed in AVD 6.0.0.

 ethernet_interfaces:
  - name: Ethernet10
-   type: switched
-   mode: trunk
-   vlans: '1-5'
-   native_vlan: 20
-   native_vlan_tag: true
-   trunk_groups: ['group1', 'group2']
-   trunk_private_vlan_secondary: true
-   pvlan_mapping: 20-30
-   phone:
-     vlan: 35
-     trunk: tagged
-   vlan_translations:
-     - from: 10
-       to: 20
-       direction: in
-     - from: 23
-       to: 30
-       direction: out
-     - from: 1
-       to: 5
-       direction: both
+   switchport:
+     mode: trunk
+     trunk:
+       allowed_vlan: 1-5
+       native_vlan: 20
+       native_vlan_tag: true
+       groups:
+         - group1
+         - group2
+       private_vlan_secondary: true
+     pvlan_mapping: 20-30
+     access_vlan: 15
+     phone:
+       vlan: 35
+       trunk: tagged
+     vlan_translations:
+       direction_in:
+         - from: 10
+           to: 20
+       direction_out:
+         - from: 23
+           to: 30
+       direction_both:
+         - from: 1
+           to: 5
!
port_channel_interfaces:
  - name: Port-Channel10
-   type: switched
-   mode: trunk
-   vlans: '1-5'
-   native_vlan: 20
-   native_vlan_tag: true
-   trunk_groups: ['group1', 'group2']
-   trunk_private_vlan_secondary: true
-   pvlan_mapping: 20-30
-   phone:
-     vlan: 35
-     trunk: tagged
-   vlan_translations:
-     - from: 10
-       to: 20
-       direction: in
-     - from: 23
-       to: 30
-       direction: out
-     - from: 1
-       to: 5
-       direction: both
+   switchport:
+     mode: trunk
+     trunk:
+       allowed_vlan: 1-5
+       native_vlan: 20
+       native_vlan_tag: true
+       groups:
+         - group1
+         - group2
+       private_vlan_secondary: true
+     pvlan_mapping: 20-30
+     access_vlan: 15
+     phone:
+       vlan: 35
+       trunk: tagged
+     vlan_translations:
+       direction_in:
+         - from: 10
+           to: 20
+       direction_out:
+         - from: 23
+           to: 30
+       direction_both:
+         - from: 1
+           to: 5

The change has been incorporated into eos_designs, so action is only required when directly defining structured_configuration.

encapsulation configuration and documentation

In AVD 4.0.0, the configuration and documentation for encapsulation in ethernet and port-channel interfaces were rendered only if ethernet_interfaces[].type or port_channel_interfaces[].type was set to l2dot1q/l3dot1q along with the keys encapsulation_dot1q_vlan and encapsulation_vlan.

With AVD 5.0.0, a new key for encapsulation_dot1q has been introduced, and the schema for encapsulation_vlan has been modified under the ethernet and port-channel interfaces data model. This generates the configuration and documentation for encapsulation independent of the type key. The keys encapsulation_dot1q_vlan, encapsulation_vlan.client.dot1q, encapsulation_vlan.client.unmatched, encapsulation_vlan.network.dot1q and encapsulation_vlan.network.client are deprecated. They will be removed in AVD 6.0.0.

ethernet_interfaces:
  - name: Ethernet1.20
-   type: l3dot1q
-   encapsulation_dot1q_vlan: 20
+   encapsulation_dot1q:
+     vlan: 20
+     inner_vlan: 12
    encapsulation_vlan:
      client:
-       dot1q:
-         outer: 10
-         inner: 12
+       encapsulation: dot1q
+       outer_vlan: 10
+       inner_vlan: 12
      network:
-       dot1q:
-         outer: 20
-         inner: 22
+       encapsulation: dot1q
+       outer_vlan: 20
+       inner_vlan: 22
  - name: Ethernet1.30
    encapsulation_vlan:
      client:
-       unmatched: true
+       encapsulation: unmatched

!
port_channel_interfaces:
  - name: Port-Channel1.20
-   type: l3dot1q
-   encapsulation_dot1q_vlan: 20
+   encapsulation_dot1q:
+     vlan: 20
+     inner_vlan: 12
    encapsulation_vlan:
      client:
-       dot1q:
-         vlan: 50
+       encapsulation: dot1q
+       vlan: 50
      network:
-       client: true
+       encapsulation: client
  - name: Port-Channel1.30
    encapsulation_vlan:
      client:
-       unmatched: true
+       encapsulation: unmatched

Data models for BGP additional-paths under router_bgp has been changed

In AVD 5.0.0, the following data models have been changed and will require updates to the inventory:

  • router_bgp.vrfs[].address_family_ipv4.bgp.additional_paths
  • router_bgp.vrfs[].address_family_ipv6.bgp.additional_paths
  • router_bgp.address_family_evpn.bgp.peer_groups[].additional_paths
  • router_bgp.address_family_evpn.bgp_additional_paths
  • router_bgp.address_family_path_selection.bgp.additional_paths
  • router_bgp.address_family_path_selection.neighbors[].additional_paths

The key additional_paths.send is now a string instead of a dictionary, and extra keys have been added for the various related arguments.

The difference shown below keeps the previous configurations.

router_bgp:
  address_family_path_selection:
    bgp:
      additional_paths:
-        send:
-          any: true
+        send: any
  <...>
  vrfs:
    address_family_ipv4:
      bgp:
        additional_paths:
-          send:
-            ecmp_limit: 100
+          send: ecmp
+          send_limit: 100
  <...>
    address_family_ipv6:
      bgp:
        additional_paths:
-         send:
-           limit: 100
+         send: limit
+         send_limit: 100
  <...>
    address_family_evpn:
      bgp_additional_paths:
        receive: true
-       send:
-         ecmp
+       send: ecmp
      peer_groups:
        additional_paths:
-         send:
-           any: false
+         send: disabled

Changes to role arista.avd.eos_validate_state

Input for hardware tests have been updated

The inputs for the hardware test have changed.

validation_role:
  xcvr_own_manufacturers:
    - Manufacturer 1
    - Manufacturer 2
  pwr_supply_states:
     - ok
     - notInserted
  fan_states:
     - ok
     - notInserted

Should be replaced with:

accepted_xcvr_manufacturers:
  - Manufacturer 1
  - Manufacturer 2
accepted_pwr_supply_states:
  - ok
  - notInserted
accepted_fan_states:
  - ok
  - notInserted

Filtering tests using Ansible tags support was removed

The filtering of tests using Ansible tags has been removed, The skip_tests variable should be used instead. The skip_tests mechanism is much more granular and allows filtering at the test level.

ansible-playbook playbooks/fabric-validate.yaml --skip-tags ntp,bgp_checks

should be replaced with the following input variables:

skip_tests:
 - category: AvdTestNTP
 - category: AvdTestBGP

and the following command line:

ansible-playbook playbooks/fabric-validate.yaml

The test categories are listed in the role documentation