Public bug reported:
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)
- 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`)
- 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`
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`.
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).
3. Confirm via `ovn-sbctl find port_binding logical_port=<vip-port>` that the
virtual port's
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).
5. Query `ovn-sbctl find Mac_Binding ip=<vip>` — observe it still shows the
previous owner's
MAC, not the current one.
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
$ 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?
** Affects: openvswitch (Ubuntu)
Importance: Undecided
Status: New
--
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_Bidning 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/openvswitch/+bug/2166984/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
