Closed smeo83 closed 2 years ago
Which version of AVD are you using?
Which previous version of AVD are you referring to here?
In the previous AVD version, below is the formula used:
mlag_ibgp_peering_vrfs.base_vlan + vrf_vni
Both formulas constraint users to a maximum value of 1093 to be used for the VRF VNI which should be a 24bits value.
In the Network Services documentation we write 1-1024
as valid values for vrf_id
and vrf_vni
, with some notes about why - specifically mentioning this usage of the id.
I suggest that you set vrf_id
to a number between 1 and 1024, since it will then render MLAG iBGP vlan numbers 3000-4023.
Thanks @ClausHolbechArista tested version is 2.2.1. I do note the constrain you put in the network service documentation, but this is limiting the enterprise to using certain value for the vrf_vni to be able to leverage AVD. Is there no way to change this formula to be based on other algorithm instead that would provide better flexibility?
Hello @smeo83,
There was a modification made that should lift this limitation: https://github.com/aristanetworks/ansible-avd/pull/1488 (in AVD 3.3.0) with the introdiction of a vrf_id
. Indeed in 2.2.1 you are not able to achieve this.
Basically the formula would now work as described in the doc:
The SVI id will be derived from the base vlan defined: mlag_ibgp_peering_vrfs.base_vlan + (vrf_id or vrf_vni) - 1
Where the vrf_id
takes precedence over the vrf_vni
for the computation of the VLAN which gives you some freedom to set the vrf_vni
you want.
# The VRF VNI range is not limited, but if vrf_id is not set, "vrf_vni" is used for calculating MLAG IBGP peering vlan id.
As an example, if you want vrf_vni = 50000
is the following (using AVD 3.4.0 in my case):
# mlag_ibgp_peering_vrfs.base_vlan is the default 3000
tenants:
TENANT_GREEN:
mac_vrf_vni_base: 1000
vrfs:
green:
vrf_id: 42
vrf_vni: 50000
[...]
Renders on a leaf with the VRF:
[...]
# Notice this is 3000 + 42 (vrf_id) -1
vlan 3041
name MLAG_iBGP_green
trunk group LEAF_PEER_L3
!
[...]
# Notice the VRF green VNI is 50000 (vrf_vni)
interface Vxlan1
description DC1-LEAF1A_VTEP
vxlan source-interface Loopback0
vxlan virtual-router encapsulation mac-address mlag-system-id
vxlan udp-port 4789
vxlan vlan 10 vni 1010
vxlan vlan 100 vni 1100
vxlan vrf green vni 50000
vxlan mlag source-interface Loopback1
!
[...]
router bgp xxx
[...]
# the vrf_id is used in the rts
vrf green
rd 192.168.100.1:42
evpn multicast
route-target import evpn 42:42
route-target export evpn 42:42
router-id 192.168.100.1
neighbor 10.255.251.1 peer group MLAG-IPv4-UNDERLAY-PEER
redistribute connected
!
Thanks @ClausHolbechArista tested version is 2.2.1. I do note the constrain you put in the network service documentation, but this is limiting the enterprise to using certain value for the vrf_vni to be able to leverage AVD. Is there no way to change this formula to be based on other algorithm instead that would provide better flexibility?
Thank you for the details @smeo83.
To add to the answer from @gmuloc, I don't think we can write an algorithm that will suite everyone. Instead we chose to document this limitation, and expose a direct per-vrf setting, to allow you to set the vlan id yourself. I Checked v2.2.1, and this knob is also available in that version. Check under the network-services documentation.
tenants:
<tenant>:
vrfs:
<vrf>:
# Manually define the VLAN used on the MLAG pair for the iBGP session. | Optional
# By default this parameter is calculated using the following formula: <mlag_ibgp_peering_vrfs.base_vlan> + <vrf_id> - 1
mlag_ibgp_peering_vlan: <1-4096>
HTH.
I belive this has been answered in the dialogue above, so closing this issue.
Issue Summary
The issue appears to be a day one BUG in the VLAN-ID calculation done in the MLAG VLAN jinja template.
Below is the current formula used to derive the iBGP MLAG VLAN in the latest AVD:
From above you are using the Base VLAN = 3000, then add it to the VRF VNI ID (this is customer configurable value and as per rfc a 24bits value), then you subtract 1, meaning if VRF VNI ID is set to
5001
as an example, the allocated VLAN ID for the mlag BGP peering would be3000 + 5001 -1 =8000
, which breaks the maximum supported VLAN number of 4094.The above formula is wrong and it is bug in AVD.
In the previous AVD version, below is the formula used:
Both formulas constraint users to a maximum value of
1093
to be used for the VRF VNI which should be a 24bits value.Can this formulas be changed please?
Cheers, jide
Which component(s) of AVD impacted
No response
How do you run AVD ?
No response
Steps to reproduce
Relevant log output
Contributing Guide