Skip to content

Release Notes for Ansible AVD 4.x.x

Release 4.1.0

Fixed issues in eos_designs

Other Fixed issues

New features and enhancements in eos_cli_config_gen

New features and enhancements in eos_designs

Other new features and enhancements

Other Changes

Release 4.0.0

Changes to requirements

  • AVD now requires ansible-core from 2.12.6 to 2.14.x excluding 2.13.0

Note

Excluded version 2.13.0 has an issue in ansible-core, which is fixed in 2.13.1. Plugin loader will now load config data for plugin by name instead of by file to avoid issues with the same file being loaded under different names (Fully-Qualified-Collection-Name + short-name).

If Ansible is installed using pip, a supported version can be installed with pip3 install "ansible-core>=2.12.6,<2.15.0,!=2.13.0".

  • The arista.avd collection no longer depends directly on ansible.netcommon. ansible.netcommon is still a depedency of arista.eos and arista.cvp, which are both dependencies of arista.avd.
  • AVD now requires the minumum versions of the following Ansible collections:
    • arista.cvp version 3.6.1 or later.
    • arista.eos version 6.0.1 or later.
    • ansible.utils version 2.10.3 or later.
  • AVD now requires cvprac python library to be version 1.3.1 or higher.

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 have been changed to “list-of-dicts”.

As an example ethernet_interfaces has been 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
    <...>

The old data models are still supported, but support will be removed in AVD 5.0.0.

In AVD 4.0.0, inputs will be auto-converted as part of the new built-in schema-based type conversion, but the variable files will not be changed.

See details on how to migrate to the new data models in the Porting guide for AVD 4.x.x.

All eos_designs and eos_cli_config_gen variables are validated by schemas

In AVD 4.0.0, all eos_designs and eos_cli_config_gen keys are validated by schemas. If additional custom keys are desired, a key starting with an underscore _, will be ignored.

Breaking or behavioral changes in eos_cli_config_gen

Breaking changes may require modifications to the inventory or playbook. See the Porting guide for AVD 4.x.x for details.

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.

With AVD 4.0.0 port-channel member interfaces defined under ethernet_interfaces will no longer ignore the type setting which defaults to switched. Other switchport or IP related features are also no longer ignored.

For interfaces with LACP fallback, this may be the intended behavior, and this is the reason for this change.

See details in the Porting guide for AVD 4.x.x.

Pull request:

Require queue_monitor_length.enabled

To avoid ambiguous YAML data input, the data model for queue_monitor_length has been updated to require the enabled key to be set.

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

See details in the Porting guide for AVD 4.x.x.

Pull request:

Disabling IGMP Snooping globally no longer blocks other IGMP snooping configuration

The eos_cli_config_gen role previously blocked IGMP snooping configuration if ip_igmp_snooping.globally_enabled was set to false. With AVD version 4.0.0 this changes to align closer to EOS behavior, where globally disabling IGMP snooping still allows for underlying configuration to be present.

See details in the Porting guide for AVD 4.x.x.

Pull request:

New required vlan_interfaces.[].ip_attached_host_route_export.enabled key

To avoid ambiguous YAML data input, the data model for vlan_interfaces.[].ip_attached_host_route_export has been updated to require an enabled: true key to be added.

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

See details in the Porting guide for AVD 4.x.x.

Pull request:

New data model for BGP VRF address-families

New data models to replace the now deprecated router_bgp.vrfs[].address_families keys have been added to eos_cli_config_gen.

The change has been incorporated into eos_designs so no action is necessary to retain the same functionality.

See details in the Porting guide for AVD 4.x.x

Replacement data model for next_hop.address_family_ipv6_originate under router_bgp.address_family_ipv4.peer_groups[]

The data model to turn on ipv4 routing over ipv6 next-hops has been replaced with a new extended one, the old data model has been deprecated and will be removed in AVD version 5.0.0.

The change has been incorporated into eos_designs so no action is necessary to retain the same functionality.

See details in the Porting guide for AVD 4.x.x

Improved hardware_counters.features data model

The hardware_counters.features model has been improved to allow more options.

See details in the Porting guide for AVD 4.x.x.

Pull requests:

eos_cli_config_gen sanitized device documentation

  • Starting AVD 4.0.0, the eos_cli_config_gen role replaces sensitive values in the device documentation by the string <removed> by default, similar to the output of show run sanitized on EOS.
  • It is also possible to generate the intended configurations by replacing the sensitive data by <removed> but this is not the case by default
  • This behavior can be controlled using the following variables:
    eos_cli_config_gen_documentation:
  hide_passwords: <bool> # default true
eos_cli_config_gen_configuration:
  hide_passwords: <bool> # default false

NOTE: The structured_config generated by eos_designs role cannot be sanitized.

Breaking or behavioral changes in eos_designs

Breaking changes may require modifications to the inventory or playbook. See the Porting guide for AVD 4.x.x for details.

Custom structured configuration behavioral change

Related to the data model changes mentioned above, the behavior of custom_structured_configuration_* and structured_config keys has also changed:

  1. The default list merge strategy set with custom_structured_configuration_list_merge is now append_rp meaning “Append unique items”. Changed from replace.
  2. Unless list merge is set to replace, the merge of custom structured configuration will now merge list-of-dicts based on the “primary_key” set in the schema of the data model, falling back to the list merge strategy.

The custom structured configuration feature is not able to remove individual items from a list. This is not a new limitation, but since more data models are now lists, this limitation may affect the ability to remove certain elements from the generated configurations.

mlag_peer_link_allowed_vlans no longer has a default value of “2-4094”.

See details in the Porting guide for AVD 4.x.x.

IP routing is no longer configured on pure L2 devices

For node types like l2leaf where underlay_router is set to false under node_type_keys AVD versions below 4.0.0 still rendered ip routing in the configuration. With AVD version 4.0.0 ip routing is no longer configured for l2leaf or other node types with underlay_router: false.

See details in the Porting guide for AVD 4.x.x.

Pull request:

BGP is no longer configured on irrelevant nodes

An example of an “irrelevant node” is a pure L3 Spine in L3LS running ISIS or OSPF in the underlay. As long as the spine is not set as route-server for any overlay BGP protocol, there is no need for router bgp <asn> to be configured on this device.

See details in the Porting guide for AVD 4.x.x.

Pull request:

Per Arista best practice, all SVIs configured with ipv6 address virtual should also have ipv6 enable configured, to use link-local IPv6 addresses for NDv6 operations.

With AVD version 4.0.0 this best practice is now implemented by default.

See details in the Porting guide for AVD 4.x.x.

Removed eos_designs variables

  • evpn_rd_type has been removed and replaced with overlay_rd_type.
  • evpn_rt_type has been removed and replaced with overlay_rt_type.
  • vxlan_vlan_aware_bundles has been removed and replaced with evpn_vlan_aware_bundles

See details in the Porting guide for AVD 4.x.x.

  • bgp_peer_groups.IPv4_UNDERLAY_PEERS has been removed and replaced with bgp_peer_groups.ipv4_underlay_peers to avoid upper-case variables.
  • bgp_peer_groups.MLAG_IPv4_UNDERLAY_PEER has been removed and replaced with bgp_peer_groups.mlag_ipv4_underlay_peer to avoid upper-case variables.
  • bgp_peer_groups.EVPN_OVERLAY_PEERS has been removed and replaced with bgp_peer_groups.evpn_overlay_peers to avoid upper-case variables.
  • connected_endpoints_key.[].adapters.[].server_ports has been removed and replaced with connected_endpoints_key.[].adapters.[].endpoint_ports.

See details in the Porting guide for AVD 4.x.x.

Change in defaults in underlay ISIS variables

  • isis_default_circuit_type default changed from level-1-2 (EOS default) to level-2.

See details in the Porting guide for AVD 4.x.x.

Change in defaults in BGP variables

  • bgp_default_ipv4_unicast: <bool> -> default false was introduced to implement the best practice of disabling the default activation of IPv4 unicast address-family.
  • bgp_update_wait_install: <bool> -> default true was introduced to implement the best practice of enable router bgp update wait-install under router bgp and BGP VRF definitions for VRFs containing BGP peerings.

See details in the Porting guide for AVD 4.x.x.

Pull requests:

Change in default MTU for point-to-point ethernet interfaces

The default value for p2p_uplinks_mtu has changed from 9000 to 9214.

See details in the Porting guide for AVD 4.x.x.

Pull request:

Change in behavior in core_interfaces variables

  • core_interfaces.p2p_links.[].ptp_enable changed to core_interfaces.p2p_links.[].ptp.enabled to create syntax consistency when configuring PTP.
  • core_interfaces.p2p_links.[].ptp.enabled requires the ptp.enabled: true to be set at the fabric level.

See details in the Porting guide for AVD 4.x.x.

Change in defaults and behavior in l3_edge variables

  • l3_edge.p2p_links.[].qos_profile default changed from null to now leverage p2p_uplinks_qos_profile as its default value.
  • l3_edge.p2p_links.[].include_in_underlay_protocol default changed from false to true.
  • l3_edge.p2p_links.[].isis_circuit_type -> default changed from level-1-2 (EOS default) set by isis_default_circuit_type to level-2.
  • l3_edge.p2p_links.[].isis_hello_padding default changed from false to true (EOS default).
  • l3_edge.p2p_links.[].ptp_enable changed to l3_edge.p2p_links.[].ptp.enabled to create syntax consistency when configuring PTP.

See details in the Porting guide for AVD 4.x.x.

Changes to inband management for L2 switches

With AVD version 4.0.0 some of the default values for inband management are changing:

  • The SVI MTU was derived from p2p_uplinks_mtu with a default value of 9000. Now the SVI MTU defaults to 1500 and is configurable with inband_mgmt_mtu.
  • The SVI description was hardcoded to L2LEAF_INBAND_MGMT. Now the default SVI description is Inband Management and is configurable with inband_mgmt_description.
  • The VLAN name was hardcoded to L2LEAF_INBAND_MGMT. Now the default VLAN name is INBAND_MGMT and is configurable with inband_mgmt_vlan_name.

The inband management interfaces are now documented and configured as vlan_interfaces instead of management_interfaces.

See details in the Porting guide for AVD 4.x.x.

Pull request:

Several internal switch.* facts and avd_switch_facts have been removed

As part of optimizing performance and code reuse, the amount of switch.* facts has been limited.

The switch.* and avd_switch_facts are internal datamodels used for sharing data between various stages of eos_designs. They should not be used in custom templates for interface descriptions or IP addressing, since they are subject to change without notice.

See the porting guide for suggestions on how to leverage AVD logic in combination with Ansible inline Jinja2.

The following facts have been removed from switch.* and avd_switch_facts.<hostname>.switch.*:

switch.always_configure_ip_routing
switch.always_include_vrfs_in_tenants
switch.bgp
switch.bgp_cluster_id
switch.bgp_defaults
switch.connected_endpoints
switch.default_downlink_interfaces
switch.default_overlay_routing_protocol
switch.default_underlay_routing_protocol
switch.enable_trunk_groups
switch.evpn_gateway_remote_peers
switch.evpn_gateway_vxlan_l2
switch.evpn_gateway_vxlan_l3
switch.evpn_gateway_vxlan_l3_inter_domain
switch.filter_only_vlans_in_use
switch.filter_tags
switch.filter_tenants
switch.hostname
switch.inband_management_gateway
switch.inband_management_interface
switch.inband_management_ip
switch.inband_management_parents
switch.inband_management_role
switch.igmp_snooping_enabled
switch.ipv6_mgmt_ip
switch.ipv6_router_id
switch.ipvpn_gateway
switch.isis_instance_name
switch.isis_net
switch.is_type
switch.lacp_port_id
switch.link_tracking_groups
switch.loopback_ipv4_offset
switch.loopback_ipv6_offset
switch.loopback_ipv6_pool
switch.mlag
switch.mlag_dual_primary_detection
switch.mlag_ibgp_origin_incomplete
switch.mlag_interfaces_speed
switch.mlag_l3
switch.mlag_peer_ip
switch.mlag_peer_ipv4_pool
switch.mlag_peer_l3_ip
switch.mlag_peer_l3_ipv4_pool
switch.mlag_peer_l3_vlan
switch.mlag_peer_l3_vlan_structured_config
switch.mlag_peer_link_allowed_vlans
switch.mlag_peer_mgmt_ip
switch.mlag_peer_vlan
switch.mlag_peer_vlan_structured_config
switch.mlag_port_channel_structured_config
switch.mlag_role
switch.mlag_support
switch.multi_vtep
switch.network_services_l1
switch.network_services_l2
switch.network_services_l3
switch.node_sid
switch.only_local_vlan_trunk_groups
switch.overlay_address_families
switch.overlay_rd_type_admin_subfield
switch.overlay_routing_protocol
switch.overlay_routing_protocol_address_family
switch.platform_settings
switch.rack
switch.raw_eos_cli
switch.short_esi
switch.spanning_tree_mode
switch.spanning_tree_priority
switch.spanning_tree_root_super
switch.struct_cfg
switch.system_mac_address
switch.trunk_groups
switch.underlay
switch.underlay_ipv6
switch.underlay_multicast
switch.underlay_router
switch.uplink_bfd
switch.uplink_interfaces
switch.uplink_interface_speed
switch.uplink_macsec
switch.uplink_ptp
switch.uplink_structured_config
switch.uplink_switches
switch.uplink_switch_interfaces
switch.uplink_type
switch.virtual_router_mac_address
switch.vtep
switch.vtep_loopback

Other breaking or behavioral changes

Breaking changes may require modifications to the inventory or playbook. See the Porting guide for AVD 4.x.x for details.

Roles cvp_configlet_upload and eos_config_deploy_cvp default to cv_collection: v3

The roles arista.avd.cvp_configlet_upload and arista.avd.eos_config_deploy_cvp leverage modules from the arista.cvp collection to perform actions on the CloudVision platform. These modules are currently available in v1 and v3 variants, but v1 modules have been deprecated and will be removed from the arista.cvp collection in version 4.0.0.

With AVD version 4.0.0 the default cv_collection is set to v3.

The v3 modules are mostly compatible with the v1 modules with a few known gaps:

  • v3 is missing support for hostnames with dots like leaf1.dc2.
  • The implementation of v3 in eos_config_deploy_cvp is missing support for the absent option.

v1 modules can still be used by setting cv_collection: v1, as long as the arista.cvp collection is not upgraded to 4.0.0 or above.

Pull request:

Change upper case CVP roles and module vars to lower case

Potentially breaking in rare cases where custom logic relies on the registered vars or content of files. The custom scripts must be updated to use the lowercase variable instead.

Component(s) name Roles:

  • arista.avd.eos_config_deploy_cvp
  • arista.avd.cvp_configlet_upload

Modules:

  • arista.avd.inventory_to_container
  • arista.avd.configlet_build_config

The following vars are changed from uppercase to lowercase, to conform with Ansible linting requirements.

CVP_CONFIGLETS -> cvp_configlets
CVP_CONFIGLETS_STATUS -> cvp_configlets_status
CVP_CONTAINERS -> cvp_containers
CVP_CONTAINER_RESULTS -> cvp_container_results
CVP_DEVICES -> cvp_devices
CVP_DEVICES_RESULTS -> cvp_devices_results
CVP_FACTS -> cvp_facts
CVP_TOPOLOGY -> cvp_topology
CVP_VARS -> cvp_vars

Pull request:

Changes to inventory to CloudVision containers

In AVD 4.0.0, the role arista.avd.eos_config_deploy_cvp gets support for dynamic Ansible inventories. This means the CloudVision containers’ basis will no longer be the inventory.yml file. Instead, the role reads the loaded Ansible inventory. This inventory can be loaded from dynamic inventory plugins like Ansible Automation Platform, AWX, etc.

The new inventory parsing is stricter than the previous method, so all Ansible inventory groups must be laid out as a regular tree structure starting from the container_root.

See details in the Porting guide for AVD 4.x.x.

Pull request:

Fixed issues in eos_cli_config_gen

Fixed issues in eos_designs

Other Fixed issues

Documentation

New features and enhancements in eos_cli_config_gen

New features and enhancements in eos_designs

Other new features and enhancements

Last update: June 16, 2023