In L2LS deployments we are seeing customers looking to use a separate vrf for tenant traffic, however there are some limitations in eos_desings currently to achieve this. In the scenario below VRF RED is used for tenant traffic and we are running BGP on the Spines.
Example of config in generated for the VRF RED:
vlan 10
name V10-T-A-VRF-RED
!
vrf instance RED
!
interface Vlan10
description V10-T-A-VRF-RED
no shutdown
vrf RED
ip address 10.10.10.252/24
ip virtual-router address 10.10.10.254
!
ip virtual-router mac-address 00:1c:73:00:dc:01
!
ip routing vrf RED
!
router bgp 65000.0
bgp asn notation asdot
router-id 192.168.100.1
distance bgp 20 200 200
graceful-restart restart-time 300
graceful-restart
maximum-paths 128 ecmp 128
no bgp default ipv4-unicast
timers bgp 5 15
neighbor default send-community
neighbor IPv4-UNDERLAY-PEERS peer group
neighbor IPv4-UNDERLAY-PEERS password 7 $1c$G8BQN0ezkiJOX2cuAYpsEA==
neighbor IPv4-UNDERLAY-PEERS send-community
neighbor IPv4-UNDERLAY-PEERS maximum-routes 12000
neighbor MLAG-IPv4-UNDERLAY-PEER peer group
neighbor MLAG-IPv4-UNDERLAY-PEER remote-as 65000.0
neighbor MLAG-IPv4-UNDERLAY-PEER next-hop-self
neighbor MLAG-IPv4-UNDERLAY-PEER description DC1-SP2
neighbor MLAG-IPv4-UNDERLAY-PEER send-community
neighbor MLAG-IPv4-UNDERLAY-PEER maximum-routes 12000
neighbor MLAG-IPv4-UNDERLAY-PEER route-map RM-MLAG-PEER-IN in
neighbor 172.16.1.1 peer group MLAG-IPv4-UNDERLAY-PEER
neighbor 172.16.1.1 description DC1-SP2
redistribute connected
!
address-family ipv4
neighbor IPv4-UNDERLAY-PEERS activate
neighbor MLAG-IPv4-UNDERLAY-PEER activate
We are missing few additions to be able to advertise the VRF RED network in BGP.
Redistribute connected in the RED vrf. For example:
router bgp <asn>
vrf RED
redistribute connected
SVI in VRF RED for the iBGP session between the spine switches.
A iBGP peering in VRF RED to the other Spine over the MLAG peer link for redundancy purposes.
Which component of AVD is impacted
eos_designs
Use case example
PS customers that require L2LS with tenants in non-default VRF and running BGP on the spines.
Describe the solution you would like
We are missing few additions to be able to advertise the VRF RED network in BGP.
Redistribute connected in the RED vrf. For example:
router bgp <asn>
vrf RED
redistribute connected
SVI in VRF RED for the iBGP session between the spine switches.
A iBGP peering in VRF RED to the other Spine over the MLAG peer link for redundancy purposes.
Describe alternatives you have considered
No response
Additional context
No response
Contributing Guide
[X] I agree to follow this project's Code of Conduct
Enhancement summary
In L2LS deployments we are seeing customers looking to use a separate vrf for tenant traffic, however there are some limitations in eos_desings currently to achieve this. In the scenario below VRF RED is used for tenant traffic and we are running BGP on the Spines.
Example of config in generated for the VRF RED:
We are missing few additions to be able to advertise the VRF RED network in BGP.
Which component of AVD is impacted
eos_designs
Use case example
PS customers that require L2LS with tenants in non-default VRF and running BGP on the spines.
Describe the solution you would like
We are missing few additions to be able to advertise the VRF RED network in BGP.
Describe alternatives you have considered
No response
Additional context
No response
Contributing Guide