We would like utilize the lxd ovn support to manage our internal networking.
The plan is to use a lxdbr0 as the UPLINK and create multiple OVN subnets based on that.
In a 3-node-cluster test environment, I’ve managed to successfully advertise the OVN subnet as well as the UPLINK network to the BGP peer.
- only one member of the cluster is used as the active chassis for the subnet. (I think this is expected)
- But BGP does not know which one is active, just randomly pick one cluster member
In my case,
# lxd cluster members 10.56.123.150 10.56.123.151 (Chassis) 10.56.123.152
lxc network info of my ovn network shows:
config: bridge.mtu: "1442" ipv4.address: 10.77.21.1/24 ipv4.nat: "false" ipv6.address: none network: lxdbr0 volatile.network.ipv4.address: 10.34.56.11
In my router (I’m using FRR on a VM as a virtual router),
show ip bgp gives
Network Next Hop Metric LocPrf Weight Path *= 10.34.56.0/24 10.56.123.152 0 65101 i *= 10.56.123.150 0 65101 i *> 10.56.123.151 0 65101 i * 10.77.21.0/24 10.34.56.11 0 65101 i *> 10.34.56.11 0 65101 i * 10.34.56.11 0 65101 i
When I want to access the OVN network (10.77.21.0/24), I guess the route goes like this:
external machine -> 10.34.56.11 -> Randomly pick one of 10.56.123.[150-152] # Only 151 should be picked?
My experiments also show similar result: all the pings go to 10.56.123.152, but 10.56.123.151 is the correct chassis.
I created several more ovn networks and it sometimes work, if the routed one is luckily the same as the active chassis.
What am I missing here, or is this the supposed behavior? Thanks for advice!
lxc network info lxdbr0:
config: bgp.peers.my-bgp.address: 10.56.123.11 bgp.peers.my-bgp.asn: "7675" ipv4.address: 10.34.56.1/24 ipv4.dhcp.ranges: 10.34.56.5-10.34.56.10 ipv4.nat: "false" ipv4.ovn.ranges: 10.34.56.11-10.34.56.20 ipv4.routes: 10.77.21.0/24 ipv6.address: none tunnel.lan.interface: enp5s0 tunnel.lan.protocol: vxlan tunnel.lan.ttl: "1"