[question] improvements for bgp configuration

[mslocrian]

I would like to propose some improvements to the bgp configuration, in order to take some advantages of features available within FRR.

There are two main features which I feel would be beneficial to get support for:

1. bgp ipv6 peer auto configuration
2. use of bgp instances in vrf

Let's note, I'm very green with how to configure a lot of this, so I've had to do some manual configuration outside of the ConfigDB, since documentation is sparse and I'm trying to get up to speed on some things.

First let's take a look at the interface configuration:

root@sonic:/# ip -d link show Ethernet0
123: Ethernet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9100 qdisc pfifo_fast master vrf-private state UP mode DEFAULT group default qlen 1000
    link/ether 8c:ea:1b:d9:87:d8 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    vrf_slave table 10 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
root@sonic:/# ip -d address show Ethernet0
123: Ethernet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9100 qdisc pfifo_fast master vrf-private state UP group default qlen 1000
    link/ether 8c:ea:1b:d9:87:d8 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    vrf_slave table 10 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 
    inet6 fe80::8eea:1bff:fed9:87d8/64 scope link 
       valid_lft forever preferred_lft forever
root@sonic:/# 

As you can see, there is really nothing going on here. I manually created the vrf via:

  392  ip link add name vrf-private type vrf table 10
  393  ip link set dev vrf-private up
  394  ip link set dev Ethernet0 master vrf-private

Really, this is all you would need for a spine<->leaf connection.

Here's a quick example of what the final configuration could look like using frr:

root@sonic:/# docker exec -ti bgp /bin/bash
root@sonic:/# vtysh 

Hello, this is FRRouting (version 4.0).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

sonic# show run
Building configuration...

Current configuration:
!
frr version 4.0
frr defaults traditional
hostname sonic
!
service integrated-vtysh-config
!
password zebra
!
log syslog informational
!
log facility local4
!
interface Ethernet0 vrf vrf-private
 ipv6 nd ra-interval 10
 no ipv6 nd suppress-ra
!
router bgp 4201011001 vrf vrf-private
 bgp router-id 1.2.3.4
 coalesce-time 1000
 bgp bestpath as-path multipath-relax
 neighbor fabric peer-group
 neighbor fabric remote-as external
 neighbor fabric bfd 3 50 50
 neighbor fabric capability extended-nexthop
 neighbor Ethernet0 interface v6only peer-group fabric
 !
 address-family ipv4 unicast
  redistribute connected
  redistribute static
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor fabric activate
 exit-address-family
!
line vty
!
end
sonic# 

And, just to show it's working:

IPv4 Unicast Summary:
BGP router identifier 1.2.3.4, local AS number 4201011001 vrf-id 143
BGP table version 322
RIB entries 120, using 18 KiB of memory
Peers 1, using 19 KiB of memory
Peer groups 1, using 64 bytes of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
Ethernet0       4 4201012001      90      94        0    0    0 00:00:36           64

Total number of neighbors 1
sonic# 

This could seriously simplify configuration, and save a bunch of ip addressing as not having to dole out /31's for each p2p interface on the device.

Now with regards to how that would look in the json configuration, I'm not quite sure. But here's a stab in the dark.

root@sonic:/# show run all
{
    "BGP_PEER_GROUP": {
        "fabric": {
          "remote-as": "external",
          "capability": "extended-nexthop",
          "bfd": {
            "multiplier": "3"
            "receive": "50",
            "transmit": "50"
          },
        },
    },
    "BGP_NEIGHBOR": {
        "10.0.0.1": {
            "rrclient": "0", 
            "name": "ARISTA01T2", 
            "local_addr": "10.0.0.0", 
            "nhopself": "0", 
            "holdtime": "180", 
            "asn": "65200", 
            "keepalive": "60"
        }, 
        "10.0.0.3": {
            "rrclient": "0", 
            "name": "ARISTA02T2", 
            "local_addr": "10.0.0.2", 
            "nhopself": "0", 
            "holdtime": "180", 
            "asn": "65200", 
            "keepalive": "60"
        }, 
    "Ethernet0": {
      "asn": "4201011001",
      "vrf": "vrf-private",
      "peer-group": "fabric"
    },

But it gets a bit interesting in that you would need to identify that the peer is an interface, verify that the peer group is an extended-nexthop (vs dynamic or none) type of capability, and notate the vrf if necessary. If so, then you need to create the interface Ethernet0 vrf <VRF> ! (if there's a vrf) \n ipv6 nd ra-interval 10 \n no ipv6 nd suppress-ra section, then the neighbor Ethernet0 interface v6only peer-group <PEER_GROUP>, then finally activate the peer group.

Anyway, I would love to know where I should properly create this type of proposal. I would also love some pointers in the right direction on where I could help contribute to some of these changes.

Thank you,
stegen

[nikos-github]

I'd be happy to take the time and understand better what your goals are and explain what I'm doing on my side for sonic. I think you may find useful what I'm working on. Feel free to ping me and we can chat informally or setup a meeting.

[mslocrian]

Closing this issue. @nikos-github has done some awesome bgp stuff which takes care of my ask here. Thanks @nikos-github !