BGP session redundancy, cluster w/ OVN

LXD
, ,
1

Hi!

I have a bare-metal cluster of 3 servers deployed w/ Juju. I have an OVN overlay configured and a routed subnet configured across the cluster. The OVN Uplink is attached to br0, which is connected to the 10.0.208.0/24 subnet. BGP is configured, and the first LXD node is advertising routes via BGP to the rest of the network via the IP assigned by the OVN uplink.

Uplink:
  bgp.peers.rr01.address: 10.0.208.212
  bgp.peers.rr01.asn: "65000"
  ipv4.gateway: 10.0.208.254/24
  ipv4.ovn.ranges: 10.0.208.224-10.0.208.239
  ipv4.routes: 10.0.209.0/26

OVN network:
  ipv4.address: 10.0.209.1/26
  ipv4.nat: "false"
  network: UPLINK-control-plane
  volatile.network.ipv4.address: 10.0.208.224

Testing the most obvious failure mode by powering off the 1st cluster node causes BGP to time out as expected. I was hoping one of the other nodes would pick up where it left off but this doesn’t seem to be the case, whether by re-using the dead node’s IP address or the other cluster node’s IPs.

Is there some way to configure BGP redundancy such that BGP will restart on a different cluster node should the active BGP node fail?

Thanks!
Greg

2

You should have all 3 servers listen on BGP and have a session between your router and each of the servers. All 3 servers will announce the exact same route, so BGP on your router will then only lose the route should all 3 go away.

3

This is what I was hoping. I believe I found the problem.

Specifically, the core.bgp* configurations need to be applied to each of the cluster members. I’d made the mistake of thinking this was cluster wide. From there I restarted lxd on each server and the bgp sessions established.

Thanks!
Greg

1 Like
4

Yeah the thinking is that you might have different peer addresses for each member.

5

Makes sense. Might be nice to tie it to an interface on the node. Example:

lxc set config core.bgp_address eth0
lxc set config core.bgp_routerid eth0

Seems like a feature request.