** Summary changed: - OVN Mac_Bidning table not refreshed after keepalived VIP failover between virtual port parents + OVN Mac_Binding table not refreshed after keepalived VIP failover between virtual port parents
** Description changed: On an OpenStack (Caracal) deployment using OVN 24.03.2-0ubuntu0.24.04.1, a keepalived-managed VIP (implemented as an OVN "virtual port" with `virtual-parents`) fails over correctly at the OVN port-binding / chassis-claim level, but the OVN Southbound Mac_Binding table entry for the VIP's IP is not updated to the new owning MAC address. This causes connectivity loss to the VIP until keepalived is restarted on the affected unit (which appears to force re-resolution). Env - OpenStack: Caracal - OVN: 24.03.2-0ubuntu0.24.04.1 - Deployment: 3x keepalived units providing a VIP, each backed by an OVN "allowed address pair" - port that is a virtual parent of a single virtual port (the VIP port) + port that is a virtual parent of a single virtual port (the VIP port) - Underlay fabric: Cumulus Linux 5.10.1, EVPN/VXLAN, MLAG pairs, `arp-nd-suppress: on` Topology - VIP: `10.152.44.43` — virtual port `8c621518-9cb9-49d3-b060-0199255bc027` - (Neutron port name: `vip_reservation_10_152_44_43`, mac_address `fa:16:3e:da:c6:b4`) + (Neutron port name: `vip_reservation_10_152_44_43`, mac_address `fa:16:3e:da:c6:b4`) - Virtual parents (3 keepalived backend ports): - - host-A: port `4a58d95c-8fbd-4ebd-8349-0fadb2284ded` — `10.152.44.40` — `fa:16:3e:26:a0:b0` - - host-B: port `55eb9e19-075b-4e48-8d0b-daa236319b41` — `10.152.44.42` — `fa:16:3e:09:45:d1` - - host-C: port `e5be32e4-ea0e-4e13-afc7-ad98dcbf6b0e` — `10.152.44.41` — `fa:16:3e:2d:99:59` - + - host-A: port `4a58d95c-8fbd-4ebd-8349-0fadb2284ded` — `10.152.44.40` — `fa:16:3e:26:a0:b0` + - host-B: port `55eb9e19-075b-4e48-8d0b-daa236319b41` — `10.152.44.42` — `fa:16:3e:09:45:d1` + - host-C: port `e5be32e4-ea0e-4e13-afc7-ad98dcbf6b0e` — `10.152.44.41` — `fa:16:3e:2d:99:59` Steps to Reproduce 1. Deploy 3 keepalived units on OpenStack/OVN, each with the VIP as an allowed-address-pair on its - port, and a corresponding OVN virtual port with all 3 ports as `virtual-parents`. + port, and a corresponding OVN virtual port with all 3 ports as `virtual-parents`. 2. Trigger a VRRP failover (keepalived master election) so the VIP moves from one backend to - another (in this case, from host-C to host-A, and later to host-B). + another (in this case, from host-C to host-A, and later to host-B). 3. Confirm via `ovn-sbctl find port_binding logical_port=<vip-port>` that the virtual port's - claiming chassis has updated correctly. + claiming chassis has updated correctly. 4. Confirm via `ovn-controller.log` on each backend that the correct chassis claimed the virtual - port with the correct `virtual_parent` at the expected time (see logs below). + port with the correct `virtual_parent` at the expected time (see logs below). 5. Query `ovn-sbctl find Mac_Binding ip=<vip>` — observe it still shows the previous owner's - MAC, not the current one. + MAC, not the current one. - - On ovn-controller logs we see + On ovn-controller logs we see host-A: 2026-09-10T11:39:52.060Z ... Claiming virtual lport 8c621518-... for this chassis with the virtual parent 4a58d95c-8fbd-4ebd-8349-0fadb2284ded host-C: 2026-09-10T11:39:56.986Z ... Claiming virtual lport 8c621518-... for this chassis with the virtual parent e5be32e4-ea0e-4e13-afc7-ad98dcbf6b0e host-B: 2026-09-10T13:03:49.822Z ... Claiming virtual lport 8c621518-... for this chassis with the virtual parent 55eb9e19-075b-4e48-8d0b-daa236319b41 - - So host-B was the last one to claim but the MAC_Binding is stale + So host-B was the last one to claim but the MAC_Binding is stale $ ovn-sbctl find Mac_Binding ip=10.152.44.43 | grep mac mac : "fa:16:3e:2d:99:59" - While neutron confirms that the binding_host_id is host-B - Expected Behavior When the VIP moves to a new virtual parent and that new parent sends gratuitous ARP for the VIP with its own MAC, OVN's Southbound `mac_binding` table entry for that IP should be refreshed to reflect the new MAC - Impact Traffic destined to the VIP is directed to the wrong MAC/chassis, causing an outage until manual intervention (restarting keepalived on the affected backend) restores connectivity. - - Is ovn-controller expected to update MAC_Binding from observed GARP traffic for virtual ports with multiple `virtual-parents? + Is ovn-controller expected to update MAC_Binding from observed GARP + traffic for virtual ports with multiple virtual-parents? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166984 Title: OVN Mac_Binding table not refreshed after keepalived VIP failover between virtual port parents To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/networking-ovn/+bug/2166984/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
