L2LS Inband manamagement in non-default VRF with BGP

[dgonzalez85]

Enhancement summary

In L2LS deployments inband we are seeing customers looking to use a separate vrf for management traffic, however there are some limitations in eos_desings currently to achieve this. In the scenario we are running BGP in the Spines.

Example of config in the default vrf:

interface Vlan4092
   description Inband Management
   no shutdown
   mtu 1500
   ip address [192.168.10.2/24](http://192.168.10.2/24)
   **ip attached-host route export 19**
   ip virtual-router address 192.168.10.1

router bgp 65000.0
   bgp asn notation asdot
   router-id 192.168.100.1
   no bgp default ipv4-unicast
   distance bgp 20 200 200
   graceful-restart restart-time 300
   graceful-restart
   maximum-paths 128 ecmp 128
   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 route-map RM-MLAG-PEER-IN in
   neighbor MLAG-IPv4-UNDERLAY-PEER send-community
   neighbor MLAG-IPv4-UNDERLAY-PEER maximum-routes 12000
   neighbor 172.16.1.1 peer group MLAG-IPv4-UNDERLAY-PEER
   neighbor 172.16.1.1 description DC1-SP2_Vlan4093
   **redistribute connected**
   **redistribute attached-host**

When we configure "inband_mgmt_vrf: MGMT" the configuration changes to:

interface Vlan4092
   description Inband Management
   no shutdown
   mtu 1500
   vrf MGMT
   ip address [192.168.10.2/24](http://192.168.10.2/24)
   **ip attached-host route export 19**
   ip virtual-router address 192.168.10.1

router bgp 65000.0
   bgp asn notation asdot
   router-id 192.168.100.1
   no bgp default ipv4-unicast
   distance bgp 20 200 200
   graceful-restart restart-time 300
   graceful-restart
   maximum-paths 128 ecmp 128
   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 route-map RM-MLAG-PEER-IN in
   neighbor MLAG-IPv4-UNDERLAY-PEER send-community
   neighbor MLAG-IPv4-UNDERLAY-PEER maximum-routes 12000
   neighbor 172.16.1.1 peer group MLAG-IPv4-UNDERLAY-PEER
   neighbor 172.16.1.1 description DC1-SP2_Vlan4093
   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 inband MGMT network in BGP, as we do in the default VRF.

1. Enable routing for the created MGMT vrf
2. Redistribute connected and attached in the MGMT vrf. For example:

router bgp <asn>
  vrf MGMT
      redistribute connected
      redistribute attached-host

3. A peering in the MGMT vrf to the other Spine over the MLAG peer link for redundancy purposes (mlag peering over vlan4093 remains in the default VRF).

Which component of AVD is impacted

eos_designs

Use case example

PS customers using L2LS inband management and running BGP on the spines.

Describe the solution you would like

Add the previous points in BGP when using the inband over a non-default vrf.

Describe alternatives you have considered

Configure this using eos_cli_config_gen.

Additional context

No response

Contributing Guide

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