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 onlyExecute 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 thespine
type of thel2ls
design.l3spine
copied from thel2ls
design.rr
,p
andpe
copied from thempls
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:
-
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 underport_channel
to the new keyendpoint_port_channel
for all<connected_endpoints_keys.key>
adapters: -
Move the value of the
description
key underport_channel
to the new keyendpoint_port_channel
for all network_ports:
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:
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:
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:
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:
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:
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:
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:
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
The default descriptions can be reverted manually if needed:
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?<_}"
MLAG peer-link ethernet interfaces¶
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 peer-link port-channel interfaces¶
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 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:
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:
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:
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:
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:
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:
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:
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:
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:
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 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
<...>
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 that are dual-homed to two MLAG switches.
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:
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
orvpn-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
:
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.
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
.
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.
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
:
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, 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
:
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.
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
:
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.
should be replaced with the following input variables:
and the following command line:
The test categories are listed in the role documentation