Fix(eos_design): eos_designs_shared_utils module routing.py does not render bgp vrf configuration if vtep is disabled for the node_type

[philippebureau]

Issue Summary

When configuring VRF BGP configuration in tenants, configuration is not rendred if the vtep key is set to false for the node_type.

The issue seems to be here: https://github.com/aristanetworks/ansible-avd/blob/devel/ansible_collections/arista/avd/roles/eos_designs/python_modules/network_services/router_bgp.py#L125

The module checks if the device in an overlay device and if not, bypass the render of router bgp vrf config

If I disable the overlay check in the module, the rendered output has evpn relevant configuration because the module set evpn as default (see line 135 in the module)

   vrf INTERCONNECT_VRF
      rd 10.112.10.2:15
      route-target import evpn 15:15
      route-target export evpn 15:15
      router-id 10.112.10.2
      neighbor 172.23.0.24 remote-as 65101
      neighbor 172.23.0.24 description ISP FW Peer2
      redistribute connected
      !
      address-family ipv4
         neighbor 172.23.0.24 activate

if I change the "address_families" to vpn-ipv4 under the vrf, no bgp vrf configuration is rendered

Which component(s) of AVD impacted

eos_desings Network services VRF BGP configuration

How do you run AVD ?

AVD 4.1.0, ansible-core 2.14.6

Steps to reproduce

Create a node_type that disable vtep:

  - key: interconnect_leaf
    type: interconnect-leaf
    connected_endpoints: true
    mlag_support: true
    network_services:
      l2: true
      l3: true
    vtep: false

configure eos_designs network services VRF BGP configuration :

tenants:
  - name: INTERCONNECT
    vrfs:
      - name: INTERCONNECT_VRF
        description: INTERCONNECT
        
  # L3 BGP Configuration
        bgp_peers:
          - ip_address: 172.23.0.34
            remote_as: 65100
            nodes:
              - NY-TCC1-0102-EX-DMZ-SW01

no configuration is rendred under 'router bgp xxx' for the VRF

### Relevant log output

_No response_

### Contributing Guide

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

[ClausHolbechArista]

Correct, today we don't support overlays / VRFs outside of VTEPs for VXLAN or LERs for MPLS.
This support should be covered as part of #2399.

[gmuloc]

Can you please share your expected configuration for the device?

[philippebureau]

I just noticed that this piece of code is also rendered and should not

ip prefix-list PL-LOOPBACKS-EVPN-OVERLAY
seq 10 permit 10.115.196.0/24 eq 32
!
route-map RM-CONN-2-BGP permit 10
match ip address prefix-list PL-LOOPBACKS-EVPN-OVERLAY
!

[ClausHolbechArista]

I just noticed that this piece of code is also rendered and should not

ip prefix-list PL-LOOPBACKS-EVPN-OVERLAY seq 10 permit 10.115.196.0/24 eq 32 ! route-map RM-CONN-2-BGP permit 10 match ip address prefix-list PL-LOOPBACKS-EVPN-OVERLAY !

I am not sure that is correct, and I don't think it should not be included in this change.

The name LOOPBACKS-EVPN-OVERLAY actually covers the Loopback0 IPs, so it is a bit of an unfortunate naming since day-1. We still want to control the redistribution from connected to BGP, even it is not a VTEP.

[github-actions]

This issue is stale because it has been open 90 days with no activity. The issue will be reviewed by a maintainer and may be closed

[ClausHolbechArista]

Please take a look at #4358 which should address this case (and others)