Enhancement summary
Add support to eos_designs for native support of an L3LS EVPN/VXLAN multi-pod fabric, with super spines, where the super spines are defined as EVPN gateway nodes.
Which component of AVD is impacted
eos_designs
Use case example
In some L3LS EVPN/VXLAN multi-pod fabrics, each pod could have between 1 and n edge gateways/border leafs, which connect up to a set of super spines. In this fabric, the super spines role is to act as an evpn route reflector either as part of the broader evpn domain, or for routes originated as an evpn gateway. In this instance, the super spines will be defined as an evpn gateway peer, but they will also be defined as an uplink_switch, since they are directly connected to the pod edge gateways. As such, AVD will error with a peer group overlap between putting the super spines in the EVPN-OVERLAY-PEERS vs EVPN-OVERLAY-CORE peer group.
A workaround for this error is to define the local pod spines as evpn_route_servers. This clears the error and builds the correct configs from the perspective of the pod edge gateway, however, it causes the reverse EVPN peering from the super spines to the pod edge gateway to not be configured.
Describe the solution you would like
I think the following would be a good solution to this issue:
- Not having to define the local pod spines as evpn_route_servers in the pod edge gateway data model.
- A check where if an uplink_switch is also defined in the evpn_gateway.remote_peers list:
- The uplink_switch/evpn gw remote peer is added to the correct bgp peer group [EVPN-OVERLAY-CORE]
- The uplink_switch/evpn gw renders the reverse EVPN peer config.
Describe alternatives you have considered
Currently using structured config to define a peer-filter and bgp listen range on the super spines.
Additional context
No response
Contributing Guide
Enhancement summary
Add support to eos_designs for native support of an L3LS EVPN/VXLAN multi-pod fabric, with super spines, where the super spines are defined as EVPN gateway nodes.
Which component of AVD is impacted
eos_designs
Use case example
In some L3LS EVPN/VXLAN multi-pod fabrics, each pod could have between 1 and n edge gateways/border leafs, which connect up to a set of super spines. In this fabric, the super spines role is to act as an evpn route reflector either as part of the broader evpn domain, or for routes originated as an evpn gateway. In this instance, the super spines will be defined as an evpn gateway peer, but they will also be defined as an uplink_switch, since they are directly connected to the pod edge gateways. As such, AVD will error with a peer group overlap between putting the super spines in the EVPN-OVERLAY-PEERS vs EVPN-OVERLAY-CORE peer group.
A workaround for this error is to define the local pod spines as evpn_route_servers. This clears the error and builds the correct configs from the perspective of the pod edge gateway, however, it causes the reverse EVPN peering from the super spines to the pod edge gateway to not be configured.
Describe the solution you would like
I think the following would be a good solution to this issue:
- The uplink_switch/evpn gw remote peer is added to the correct bgp peer group [EVPN-OVERLAY-CORE]
- The uplink_switch/evpn gw renders the reverse EVPN peer config.
Describe alternatives you have considered
Currently using structured config to define a peer-filter and bgp listen range on the super spines.
Additional context
No response
Contributing Guide