MPBGP remove AVD default of no neighbor for peers/peer groups in AF

[onurgashi]

Issue Type

• Template enhancement

Is your feature request related to a problem? Please describe. Checking the EOS CLI standard behaviour and AVD there is redundant knobs for MPBGP where we explicitly disable peers/peer groups that are not meant to be part of the particular address-family.

By default with MPBGP we will not negotiate capability for any address-family that the peer is not defined, thus there is no need for us to explicitly do this so.

AVD

   address-family evpn
      neighbor EVPN-OVERLAY-PEERS activate
      no neighbor IPv4-UNDERLAY-PEERS activate
      no neighbor MLAG-IPv4-UNDERLAY-PEER activate
   !
   address-family ipv4
      no neighbor EVPN-OVERLAY-PEERS activate
      neighbor IPv4-UNDERLAY-PEERS activate
      neighbor MLAG-IPv4-UNDERLAY-PEER activate

Describe the solution you'd like A clear and concise description of what you want to happen.

The following provides the exact same result

PE1(config)#show run sec bgp
router bgp 1
   no bgp default ipv4-unicast
   neighbor EVPN peer group
   neighbor EVPN remote-as 2
   neighbor EVPN send-community
   neighbor EVPN maximum-routes 12000
   neighbor IP peer group
   neighbor IP remote-as 2
   neighbor IP update-source Loopback0
   neighbor IP ebgp-multihop 2
   neighbor IP maximum-routes 12000
   neighbor 2.2.2.2 peer group IP
   neighbor 10.0.0.1 peer group EVPN
   !
   address-family evpn
      bgp next-hop-unchanged
      neighbor EVPN activate
   !
   address-family ipv4
      bgp next-hop-unchanged
      neighbor IP activate

PE1(config)#show ip bgp summ
BGP summary information for VRF default
Router identifier 10.0.0.0, local AS number 1
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  2.2.2.2          4  2                  7         7    0    0 00:02:43 Estab   0      0

PE1(config)#show bgp evpn summ
BGP summary information for VRF default
Router identifier 10.0.0.0, local AS number 1
Neighbor Status Codes: m - Under maintenance
  Neighbor         V  AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.0.0.1         4  2                 24        23    0    0 00:05:52 Estab   0      0

IPv4Neighbor Capabilities:
    Multiprotocol IPv4 Unicast: advertised and received and negotiated
    Four Octet ASN: advertised and received and negotiated
    Route Refresh: advertised and received and negotiated
    Enhanced route refresh: advertised and received and negotiated
    Send End-of-RIB messages: advertised and received and negotiated
    Additional-paths recv capability:
      IPv4 Unicast: advertised
    Additional-paths send capability:
      IPv4 Unicast: received

EVPNNeighbor Capabilities:
    Multiprotocol IPv4 Unicast: advertised and received and negotiated
    Four Octet ASN: advertised and received and negotiated
    Route Refresh: advertised and received and negotiated
    Enhanced route refresh: advertised and received and negotiated
    Send End-of-RIB messages: advertised and received and negotiated
    Additional-paths recv capability:
      IPv4 Unicast: advertised
    Additional-paths send capability:
      IPv4 Unicast: received

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

It's liveable but the more address-families we have the more no neighbours we will have which in the end the result is simpler with the above.

Additional context Add any other context or screenshots about the feature request here.

[ClausHolbechArista]

no bgp default ipv4-unicast is not hardcoded into the templates today, but is in the <type>_bgp_defaults. If we remove the explicit enable/disable, the configuration may fail if <type>_bgp_defaults was overridden without no bgp default ipv4-unicast.