Arista AVD Bug -MLAG iBGP VLAN ID Allocation Issue - Day One Bug

[smeo83]

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:

  {{ vrf.mlag_ibgp_peering_vlan | arista.avd.default(mlag_ibgp_peering_vrfs.base_vlan + (vrf.vrf_vni - 1)) }}:

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 be 3000 + 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:

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.

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

set VRF VNI value to any value greater than 1093 in the tenant template file in AVD.

Relevant log output

Leaf config output:

!
vlan 8000
   name MLAG_iBGP_xxx
   trunk group LEAF_PEER_L3
!

Contributing Guide

• [X] I agree to follow this project's Code of Conduct

[ClausHolbechArista]

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.

[smeo83]

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?

[gmuloc]

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
   !

[ClausHolbechArista]

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.

[ClausHolbechArista]

I belive this has been answered in the dialogue above, so closing this issue.