Allow for configurable routing table instance

[samoehlert]

When we move to having one translator talking to multiple gobgp instances, we may want to allow translator to be aware of different routing tables and send routes only to the gobgp instance in the routing instance we want.

[grigorescu]

Ok, so I think the model would be this?

                          -> [ gobgp1 ] -> [ rtr1 ]
                        /
[ scram ] -> [ xlator ] ---> [ gobgp2 ] -> [ rtr2 ]
                        \
                          ...
                          -> [ gobgpN ] -> [ rtrN ]

Which I think begs a few questions:

1. How does this fit into the compose file?
   a) Do the different gobgp instances run in the same container?
2. How can xlator find the needed gobgp instances?
3. Where is the configuration for the various gobgp instances stored?
4. What does the WUI need to know about the various gobgp instances?
   a) I think we have the model that each xlator implements 1 actiontype. So, would we have block_wan with 1 xlator, and block_lan with another one?

[samoehlert]

We think that's actually even overkill. We're currently playing with figuring out the right syntax here (where we call AddPathRequest:

    def add_path(self, ip, event_data):
        """Announce a single route."""
        logger.info("Blocking %s", ip)
        try:
            path = self._build_path(ip, event_data)
            logger.info(f"PAAAAATH: {path}")

            self.stub.AddPath(
                gobgp_pb2.AddPathRequest(table_type=gobgp_pb2.VRF, vrf_id=b"1", path=path),
                _TIMEOUT_SECONDS,
            )
        except ASNError as e:
            logger.warning("ASN assertion failed with error: %s", e)

obviously this would just hardcode another thing that would be wrong sometimes, so we would have to deal with the configurable version of this, but it seems likely we can have one gobgp instance handle all of this with multiple peerings.

[crankynetman]

The TL;DR of how what sam mentioned works is (this is gonna be a long TL;DR) that essentially we can install routes into different VRFs into GoBGP (though figuring out how to do that on the API has been a journey so far) then we announce those out via the VPNv4/VPNv6 AFs instead of the IPv4/IPv6 AFs. We add a list (for us, it’s just one) of route targets to each prefix and we add a unique route distinguisher per VRF in GoBGP. Then on the network side we should be able (fighting nokiaisms presently) to just install that into the correct VRF/VPRN on the network based off of the route target. So from a GoBGP config standpoint, it would look like mostly like this (one v6 peering advertising all of the prefixes for all of the VRFs and AFs):

[global.config]
  as = 64666
  router-id = "192.0.2.0"
[[vrfs]]
    [vrfs.config]
        name = "my-fancy-vpn"
        rd = "123:64666"
	 export-rt-list = ["123:123]
[[neighbors]]
  [neighbors.config]
      peer-as = 123
      neighbor-address = "2001:db8::1"
      local-as = 64666
  [[neighbors.afi-safis]]
    [neighbors.afi-safis.config]
      afi-safi-name = "l3vpn-ipv4-unicast"
  [[neighbors.afi-safis]]
      [neighbors.afi-safis.config]
      afi-safi-name = "l3vpn-ipv6-unicast"

You can then install routes to that VPN like so:

docker compose exec gobgp gobgp vrf ipt rib add 10.0.0.1/32
docker compose exec gobgp gobgp vrf ipt rib add 2001:db8:1::123/128

So thankfully, from the GoBGP side it's pretty easy and quite straightforward!

[grigorescu]

Ok, that makes sense. So then, it'd be more like this?

                                      --> [ vrf1 ] -> [ rtr1 ]
                                     /
[ scram ] -> [ xlator ] -> [ gobgp ] ---> [ vrf2 ] -> [ rtr2 ]
                                     ...
                                      --> [ vrfN ] -> [ rtrN ] 
                        
                         

[crankynetman]

Yeah, pretty much! But more like this:

                                      --> [ vrf1 ] -> [ rtr1-vrf1]
                                     /
[ scram ] -> [ xlator ] -> [ gobgp ] ---> [ vrf2 ] -> [rtr1-rtr2 ]
                                     ...
                                      --> [ vrfN ] -> [ rtr1-vrfN ]                          

There would only have to be one peering session for all of these routes. And you wouldn't peer with extra routers _unless _ for any reason I can think of off the top of my head. Maybe if you had a SCRAM instance working with multiple administrative domains? In which case, we'd have to make more changes to SCRAM in addition to the VRF changes to support things like "multitenancy". I could see the value of that though. For ESnet's use case, maybe you'd want one SCRAM instance to rule them all and have it talk to the production WAN and the datacenters, but you don't want the blocks to be the same across all of them.