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 do not have to consider the changes in eos_cli_config_gen, since those adaptions are built into eos_designs.

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 was changed from:

ethernet_intefaces:
  Ethernet1:   # <-- User defined key
    <...>

to:

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

Removal Ansible tags from AVD roles¶

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

The previous implementation of Ansible tags was not consistent and mostly undocumented. It often lead to inconsistent behaviors depending when the tags were used with --tags vs. --skip-tags.

AVD now supports a number of variables which allow detailed control of 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 # (1)!
   hosts: FABRIC
   gather_facts: false
   tasks:

     - name: Generate AVD Structured Configurations and Fabric Documentation # (2)!
       ansible.builtin.import_role:
         name: arista.avd.eos_designs
       vars:
         eos_designs_documentation:
           enabled: false

     - name: Generate Device Configurations and Documentation # (3)!
       ansible.builtin.import_role:
         name: arista.avd.eos_cli_config_gen
       vars:
         generate_device_documentation: false

Removal of Ansible plugins¶

The following ansible plugins have been removed from the arista.avd Ansible collection in v5.0.0.

Plugin type	Plugin 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.

Changes to role arista.avd.eos_designs¶

TODO: Level 3 sections for each change with details on how to migrate

Removed `redistribute igmp` from BGP vlan config belonging to a VRF with evpn multicast¶

AVD versions below 5.0.0 configures 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 by default redistribute igmp is only configured when evpn_l2_multicast is True and evpn_l3_multicast for the VRF is False. In order to retain the previous behavior for SVIs under BGP where both evpn_l2_multicast and evpn_l3_multicast are enabled set always_redistribute_igmp key to True either for all SVIs within the Tenant or for each SVIs 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

`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 uses vrf_vni in the algorithm to set the offset in order to get the IP address of 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 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
        <...>

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

Base class for custom interface descriptions `AvdInterfaceDescriptions` breaking changes¶

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.0.

Removal of deprecated data models¶

The following data model keys have been removed from eos_designs in v5.0.0.

Removed key	New key
cvp_instance_ip	cvp_instance_ips
[].adapters[].port_channel.short_esi	[].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
.defaults.inband_management_subnet	.defaults.inband_mgmt_subnet
.defaults.inband_management_vlan	.defaults.inband_mgmt_vlan
.node_groups[].nodes[].inband_management_subnet	.node_groups[].nodes[].inband_mgmt_subnet
.node_groups[].nodes[].inband_management_vlan	.node_groups[].nodes[].inband_mgmt_vlan
.node_groups[].inband_management_subnet	.node_groups[].inband_mgmt_subnet
.node_groups[].inband_management_vlan	.node_groups[].inband_mgmt_vlan
.nodes[].inband_management_subnet	.nodes[].inband_mgmt_subnet
.nodes[].inband_management_vlan	.nodes[].inband_mgmt_vlan
[].vrfs[].svis[].ipv6_address_virtual	[].vrfs[].svis[].ipv6_address_virtuals
svi_profiles[].ipv6_address_virtual	svi_profiles[].ipv6_address_virtuals
ptp	ptp_settings

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 old 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

Default value for OSPF area has been updated to `0.0.0.0`¶

With AVD version 5.0.0, the default value for 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

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, 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, it may require changes to the SVI and profiles to retain the previous configuration output.

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

AVD versions below 5.0.0 created the MLAG L3 peering 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 something else than none.

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 or mpls under default_address_families and the VRF had the same evpn or mpls 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 or mpls), 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 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 sub-sections below.

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

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}"

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

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 changes 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) changes 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 changes 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 changes 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 changes 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 changes 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 changes 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 changes 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 changes 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 changes 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 old descriptions, the value of the description key under port_channel must be moved to the new key endpoint_port_channel for all connected endpoint 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 changes to <endpoint>, allowing to use new endpoint key under network_ports which is used 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.

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 changes to <endpoint>_<endpoint_port_channel>, allowing to use 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 old 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?<_}"

MLAG peer-link ethernet interfaces¶

The interface description for the MLAG peer-link ethernet interfaces changes 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. Most often the MLAG interfaces are the same, so this is a minor issue.

The description can be reverted manually if needed:

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

MLAG peer-link port-channel interfaces¶

The interface description for the MLAG peer-link port-channel interfaces changes 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. Most often the MLAG interfaces are 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 changes to MLAG. Previously the description 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 changes to MLAG_L3. Previously the description 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 changes 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) changes 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) changes 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 changes 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, changes 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) changes 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

`wan_mode: autovpn` renamed to `wan_mode: legacy-autovpn`¶

With AVD version 5.0.0 the valid values for wan_mode key have changed. If using the autovpn mode in AVD 4.x, the wan_mode key needs to be updated to legacy-autovpn.

-  wan_mode: autovpn
+  wan_mode: legacy-autovpn

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"]

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 autoconverted 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 autoconverted 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"]

`!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 value of `mlag_on_orphan_port_channel_downlink` is changed to `false`¶

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 dual-homed to two MLAG switches.

+ mlag_on_orphan_port_channel_downlink: true

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, although 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.

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 is changed to underlay_loopback.

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

+isis_system_id_format: node_id

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 behaviour, set the value to false:

+shutdown_bgp_towards_undeployed_peers: false
+shutdown_interfaces_towards_undeployed_peers: false

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 old configuration use custom structured configuration.

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

Default MTU value changed from `9214` to `9194` for Dps1, WAN HA and WAN p2p uplink interfaces¶

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

To retain the old MTU on WAN HA interfaces use <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 old MTU on Dps1 interface use custom structured configuration

custom_structured_configuration_dps_interfaces:
  - name: Dps1
+   mtu: 9214

To retain the old MTU on 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

PREVIEW WAN HA Direct Link now uses Port-Channel by default¶

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 use custom_platform_settings use 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

Prevent redistributing the MLAG peer link subnets into BGP for all VRFs by default¶

With AVD version 5.0.0 the subnet of VRF L3 peering VLANs between MLAG peers are 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
        <...>

Changes to role `arista.avd.eos_cli_config_gen`¶

TODO: Level 3 sections for each change with details on how to migrate

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 of the previous models into the new model.

As of AVD 5.0.0 the automatic conversion from both of the previous models has been removed, so it is required to update the input data to the new data models.

Old data modelsNew data model

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

# Old 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

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 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 given 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 this is not required by EOS.

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¶

In AVD 4.0.0, the ISIS address-family configuration and documentation were generated 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.

4.x

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

5.x

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

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

`router_traffic_engineering.enabled` is required¶

In AVD 4.0.0, setting enabled: true under router_traffic_engineering was not required and it was possible to render

router traffic-engineering

using the following input

router_traffic_engineering:

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

router_traffic_engineering:
  enabled: true

Removal of default type `switched` from ethernet interfaces and port-channel interfaces¶

In AVD 4.0.0, we had “switched” as the default value for ethernet_interfaces[].type and port_channel_interfaces[].type.

With AVD 5.0.0, the default value for type in ethernet_interfaces and port_channel_interfaces is no longer supported. The type key must now be explicitly defined in the input variables if it is needed in the configuration and documentation.

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

`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 renderend 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 renderend 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 ethernet and port-channel interfaces data-model, which 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, pvlan_mapping are deprecated, to 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 defining structured_configuration directly.

`encapsulation` configuration and documentation¶

In AVD 4.0.0, the configuration and documentation for encapsulation in ethernet and port-channel interfaces were renderend 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 ethernet and port-channel interfaces data-model, which 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, to 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.vrf[].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 a now a string instead of 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

Fix issues with flags, source/destination ports, and field set for TCP/UDP protocol under traffic-policies¶

The change has been incorporated into traffic-policies.j2 eos template.

In AVD 4.0.0, configuring the flags for UDP protocol under traffic-policies was allowed and the configuration for source/destination port and source/destination field-set together was not generated for TCP/UDP protocol.

As of AVD 5.0.0, the configuration of flags in UDP protocol under traffic-policies is not generated and the configuration for source/destination port and field set can be generated together for TCP/UDP protocol. Also, the configuration order has been fixed as per the EOS running-config.

Removal of deprecated data models¶

The following data model keys have been removed from eos_cli_config_gen in v5.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

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 allow to filter 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

Porting Guide for Ansible AVD 5.x.x¶

Common changes¶

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

Removal Ansible tags from AVD roles¶

Removal of Ansible plugins¶

Changes to role arista.avd.eos_designs¶

Removed redistribute igmp from BGP vlan config belonging to a VRF with evpn multicast¶

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

Base class for custom IP addressing AvdIpAddressing was moved¶

Base class for custom interface descriptions AvdInterfaceDescriptions breaking changes¶

Removal of deprecated data models¶

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

Default value for OSPF area has been updated to 0.0.0.0¶

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

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

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

Default interface descriptions are changed for more consistency¶

Router ID Loopback¶

VTEP Loopback¶

Underlay point-to-point L3 ethernet interfaces¶

Underlay point-to-point L3 port-channel interfaces¶

Underlay L2 ethernet interfaces¶

Underlay L2 port-channel interfaces¶

Out-of-band management interface¶

VRF diagnostic loopback interfaces¶

Connected Endpoints ethernet interfaces¶

Connected Endpoints port-channel interfaces¶

Network Ports ethernet interfaces¶

Network Ports port-channel interfaces¶

MLAG peer-link ethernet interfaces¶

MLAG peer-link port-channel interfaces¶

MLAG peer VLAN interface¶

MLAG L3 peering VLAN interface¶

MLAG L3 VRF peering VLAN interface¶

Default VLAN names are changed for more consistency¶

MLAG peer VLAN¶

MLAG L3 peering VLAN¶

MLAG L3 VRF peering VLAN¶

Default BGP peer descriptions are changed for more consistency¶

MLAG L3 peering¶

Overlay peerings¶

Combine the VLAN trunk groups used for MLAG¶

wan_mode: autovpn renamed to wan_mode: legacy-autovpn¶

custom_structured_configuration_prefix no longer accepts a string¶

default_overlay_address_families and overlay_address_families no longer accepts a string¶

mpls_route_servers no longer accepts a string¶

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

Default value of mlag_on_orphan_port_channel_downlink is changed to false¶

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

Default value of isis_system_id_format is changed to underlay_loopback¶

Shutdown interfaces and BGP towards undeployed peers by default¶

Only render IGMP snooping querier version and address when enabled¶

Default MTU value changed from 9214 to 9194 for Dps1, WAN HA and WAN p2p uplink interfaces¶

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

PREVIEW WAN HA Direct Link now uses Port-Channel by default¶

Prevent redistributing the MLAG peer link subnets into BGP for all VRFs by default¶

Changes to role arista.avd.eos_cli_config_gen¶

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

Default EOS configuration is no longer automatically generated¶

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

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

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

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

router_traffic_engineering.enabled is required¶

Removal of default type switched from ethernet interfaces and port-channel interfaces¶

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

vlan_id configuration¶

switchport configuration and documentation¶

encapsulation configuration and documentation¶

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

Fix issues with flags, source/destination ports, and field set for TCP/UDP protocol under traffic-policies¶

Removal of deprecated data models¶

Changes to role arista.avd.eos_validate_state¶

Input for hardware tests have been updated¶

Filtering tests using Ansible tags support was removed¶

Removed `redistribute igmp` from BGP vlan config belonging to a VRF with evpn multicast¶

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

Base class for custom IP addressing `AvdIpAddressing` was moved¶

Base class for custom interface descriptions `AvdInterfaceDescriptions` breaking changes¶

Default value for OSPF area has been updated to `0.0.0.0`¶

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

`wan_mode: autovpn` renamed to `wan_mode: legacy-autovpn`¶

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

Default value of `mlag_on_orphan_port_channel_downlink` is changed to `false`¶

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

Default value of `isis_system_id_format` is changed to `underlay_loopback`¶

Default MTU value changed from `9214` to `9194` for Dps1, WAN HA and WAN p2p uplink interfaces¶

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

Changes to role `arista.avd.eos_cli_config_gen`¶

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

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

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

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

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

`router_traffic_engineering.enabled` is required¶

Removal of default type `switched` from ethernet interfaces and port-channel interfaces¶

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

`vlan_id` configuration¶

`switchport` configuration and documentation¶

`encapsulation` configuration and documentation¶

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

Changes to role `arista.avd.eos_validate_state`¶