Closed theotherguy2175 closed 1 year ago
Converting this to a discussion since it is not a bug. I agree we could catch this and emit an error, but the behavior is documented.
See under vrf_id
in this table: https://avd.sh/en/stable/roles/eos_designs/docs/input-variables.html#network-services-vrfs-configuration.
And under mlag_ibgp_peering_vrfs
in this table: https://avd.sh/en/stable/roles/eos_designs/docs/input-variables.html#overlay-settings
Snip from the latter:
On mlag leafs, an SVI interface is defined per vrf, to establish iBGP peering (required when there are MLAG leafs in topology). The SVI id will be derived from the base vlan defined: mlag_ibgp_peering_vrfs.base_vlan + (vrf_id or vrf_vni) - 1. Depending on the values of vrf_id / vrf_vni it may be required to adjust the base_vlan to avoid overlaps or invalid vlan ids. The SVI ip address derived from mlag_l3_peer_ipv4_pool is re-used across all iBGP peerings.
So if your target config is to have the mlag vlan be 4093 for the VRF, you can either set
mlag_ibgp_peering_vrfs.base:
vlan: 0 # default is 3000
or just set the vlan id directly under the vrf:
tenants:
- name: mytenant
vrfs:
- name: myvrf
mlag_ibgp_peering_vlan: 4093
Issue Summary
I have looked through my entire AVD config and do not see anywhere where I am defining vlan 7093, which is obvious out of range. Is AVD 4.3 trying to generate 4093 but the python on the back end is doing 7093?
Which component(s) of AVD impacted
eos_cli_config_gen
How do you run AVD ?
Ansible CLI (with virtual-env or native python)
Steps to reproduce
Relevant log output
No response
Contributing Guide