[Bug 2166984] Re: OVN Mac_Binding table not refreshed after keepalived VIP failover between virtual port parents

[Guillaume Boutry]

Hey @peppepetra, can you confirm the environment if it's under Noble or Jammy? Can we know more about kernel versions (HWE?)?
I don't see a `~cloudX` so I guess it's Caracal.

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to ovn in Ubuntu.
https://bugs.launchpad.net/bugs/2166984

Title:
  OVN Mac_Binding table not refreshed after keepalived VIP failover
  between virtual port parents

Status in ovn package in Ubuntu:
  New

Bug description:
  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?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ovn/+bug/2166984/+subscriptions