Feat(eos_designs): Add knob for underlay and overlay to have loop protection in case of different AS numbers on the uplink switches

[bjmeuer]

Enhancement summary

In case you have an l3leaf attached to uplink switches with different AS numbers you would advertise routes learned by one uplink switch to the other uplink switch and it would accept it because the BGP AS is different. This might cause a routing loop. This is applicable for the underlay and for the overlay.

Which component of AVD is impacted

eos_designs

Use case example

l3leaf attached to l3leafs which are working in multihoming (different AS).

l3leaf attached to spines with different AS numbers.

Describe the solution you would like

Today we have the following knobs which are working for the case when the uplink switches have the same AS number:

evpn_prevent_readvertise_to_server: true
underlay_filter_peer_as: true

When these knobs are enabled it will generate config like this (which will not be sufficient for the case of different AS on the uplink switches):

route-map RM-BGP-AS65000.1002-OUT deny 10
   match as 65000.1002
route-map RM-BGP-AS65000.1002-OUT permit 20
!
route-map RM-BGP-AS65000.1003-OUT deny 10
   match as 65000.1003
route-map RM-BGP-AS65000.1003-OUT permit 20
!
!
route-map RM-EVPN-FILTER-AS65000.1002 deny 10
   match as 65000.1002
route-map RM-EVPN-FILTER-AS65000.1002 permit 20
!
route-map RM-EVPN-FILTER-AS65000.1003 deny 10
   match as 65000.1003
route-map RM-EVPN-FILTER-AS65000.1003 permit 20
!
router bgp 65000.1012
   ...
   neighbor 10.25.1.2 remote-as 65000.1002
   neighbor 10.25.1.2 route-map RM-EVPN-FILTER-AS65000.1002 out
   ...
   neighbor 10.25.1.3 remote-as 65000.1003
   neighbor 10.25.1.3 route-map RM-EVPN-FILTER-AS65000.1003 out
   ...
   neighbor 10.25.20.44 remote-as 65000.1002
   neighbor 10.25.20.44 route-map RM-BGP-AS65000.1002-OUT out
   ...
   neighbor 10.25.20.46 remote-as 65000.1003
   neighbor 10.25.20.46 route-map RM-BGP-AS65000.1003-OUT out

I image two new knobs like this:

evpn_prevent_readvertise_to_server_as_include_all: true
underlay_filter_peer_as_include_all: true

The outcome of this should be something like this:

route-map RM-FILTER-LOOP-PROTECTION deny 10
   match as 65000.1002
!
route-map RM-FILTER-LOOP-PROTECTION deny 20
   match as 65000.1003
!
...
route-map RM-FILTER-LOOP-PROTECTION permit 1000
!
router bgp 65000.1012
   ...
   neighbor 10.25.1.2 remote-as 65000.1002
   neighbor 10.25.1.2 route-map RM-FILTER-LOOP-PROTECTION out
   ...
   neighbor 10.25.1.3 remote-as 65000.1003
   neighbor 10.25.1.3 route-map RM-FILTER-LOOP-PROTECTION out
   ...
   neighbor 10.25.20.44 remote-as 65000.1002
   neighbor 10.25.20.44 route-map RM-FILTER-LOOP-PROTECTION out
   ...
   neighbor 10.25.20.46 remote-as 65000.1003
   neighbor 10.25.20.46 route-map RM-FILTER-LOOP-PROTECTION out

or it should be also possible to assign this new route-map to the BGP peer-groups:

router bgp 65000.1012
   neighbor EVPN-OVERLAY-PEERS route-map RM-FILTER-LOOP-PROTECTION out
   ...
   neighbor IPv4-UNDERLAY-PEERS route-map RM-FILTER-LOOP-PROTECTION out

Describe alternatives you have considered

I worked around it with structured_config:

evpn_prevent_readvertise_to_server: false
underlay_filter_peer_as: false

l3leaf:
  defaults:
    ...
    structured_config:
      route_maps:
        - name: RM-FILTER-LOOP-PROTECTION
          sequence_numbers:
            - sequence: 10
              type: deny
              match:
                - "as 65000.1002"
            - sequence: 20
              type: deny
              match:
                - "as 65000.1003"
            - sequence: 1000
              type: permit
      router_bgp:
        peer_groups:
          - name: EVPN-OVERLAY-PEERS
            route_map_out: RM-FILTER-LOOP-PROTECTION
          - name: IPv4-UNDERLAY-PEERS
            route_map_out: RM-FILTER-LOOP-PROTECTION

Additional context

No response

Contributing Guide

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