[Bug 1973276] Related fix merged to ovn-octavia-provider (stable/2025.2)

Tue May 26 11:13:21 UTC 2026

Reviewed:  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/988892
Committed: https://opendev.org/openstack/ovn-octavia-provider/commit/1c17bfe45fff4277165f9e580eb3f2f64c048a83
Submitter: "Zuul (22348)"
Branch:    stable/2025.2

commit 1c17bfe45fff4277165f9e580eb3f2f64c048a83
Author: enginrect <enginrect at gmail.com>
Date:   Thu Apr 30 09:27:52 2026 +0900

    [OVN] Protect LB VIP ports with device_id and device_owner

    VIP and additional-VIP ports created by the OVN Octavia provider were
    left with empty device_id and device_owner, allowing other workloads
    (e.g. Nova instances) to attach them. The historical reason for the
    empty device_owner was Bug #1973276 (an OVN port losing its
    "type: virtual" once device_owner was set), which was fixed in
    Neutron in 2022 (commit 4c37497e7c98). The Amphora driver has been
    protecting its own VIP port with device_id='lb-<lb_id>' and
    device_owner='Octavia' since the beginning, relying on Nova's
    _validate_requested_port_ids() rejecting any port attach with a
    non-empty device_id (PortInUse). The OVN provider was never updated
    to follow the same convention.

    This patch sets device_id='lb-<lb_id>' (the actual protection
    enforced by Nova) and device_owner='ovn-lb:vip' (an OVN-provider-
    specific identifier) on VIP and additional-VIP ports at creation
    time. The ":distributed" suffix used by OVN_LB_HM_PORT_DISTRIBUTED
    is deliberately *not* reused here: Neutron's OVN mech driver
    pattern-matches on that suffix (is_ovn_metadata_port /
    is_ovn_lb_hm_port in neutron/common/ovn/utils.py) to force the LSP
    to LSP_TYPE_LOCALPORT in ovn_client.py. HM ports really are
    localports; LB VIP ports are "virtual" (or unbound) LSPs and must
    not be turned into localports. A periodic maintenance task
    backfills the same fields on legacy ports.

    Conflicts:
      ovn_octavia_provider/tests/functional/test_driver.py

    Closes-Bug: #2150682
    Related-Bug: #1973276
    Change-Id: I5d4a823f2ba2f14df68f6c52ad0372cc9fd65c20
    Signed-off-by: enginrect <enginrect at gmail.com>

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

Title:
  OVN port loses its virtual type after port update

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive ussuri series:
  Fix Released
Status in Ubuntu Cloud Archive victoria series:
  Fix Released
Status in Ubuntu Cloud Archive wallaby series:
  Fix Released
Status in Ubuntu Cloud Archive xena series:
  Fix Released
Status in Ubuntu Cloud Archive yoga series:
  Fix Released
Status in Ubuntu Cloud Archive zed series:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Focal:
  Fix Released

Bug description:
  Bug found in Octavia (master)

  Octavia creates at least 2 ports for each load balancer:
  - the VIP port, it is down, it keeps/stores the IP address of the LB
  - the VRRP port, plugged into a VM, it has the VIP address in the allowed-address list (and the VIP address is configured on the interface in the VM)

  When sending an ARP request for the VIP address, the VRRP port should
  reply with its mac-address.

  In OVN the VIP port is marked as "type: virtual".

  But when the VIP port is updated, it loses its "port: virtual" status
  and that breaks the ARP resolution (OVN replies to the ARP request by
  sending the mac-address of the VIP port - which is not used/down).

  Quick reproducer that simulates the Octavia behavior:

  ===========================

  import subprocess
  import time

  import openstack

  conn = openstack.connect(cloud="devstack-admin-demo")

  network = conn.network.find_network("public")

  sg = conn.network.find_security_group('sg')
  if not sg:
      sg = conn.network.create_security_group(name='sg')

  vip_port = conn.network.create_port(
      name="lb-vip",
      network_id=network.id,
      device_id="lb-1",
      device_owner="me",
      is_admin_state_up=False)

  vip_address = [
      fixed_ip['ip_address']
      for fixed_ip in vip_port.fixed_ips
      if '.' in fixed_ip['ip_address']][0]

  vrrp_port = conn.network.create_port(
      name="lb-vrrp",
      device_id="vrrp",
      device_owner="vm",
      network_id=network.id)
  vrrp_port = conn.network.update_port(
      vrrp_port,
      allowed_address_pairs=[
          {"ip_address": vip_address,
           "mac_address": vrrp_port.mac_address}])

  time.sleep(1)

  output = subprocess.check_output(
      f"sudo ovn-nbctl show | grep -A2 'port {vip_port.id}'",
      shell=True)
  output = output.decode('utf-8')

  if 'type: virtual' in output:
      print("Port is virtual, this is ok.")
  print(output)

  conn.network.update_port(
      vip_port,
      security_group_ids=[sg.id])

  time.sleep(1)

  output = subprocess.check_output(
      f"sudo ovn-nbctl show | grep -A2 'port {vip_port.id}'",
      shell=True)
  output = output.decode('utf-8')

  if 'type: virtual' not in output:
      print("Port is not virtual, this is an issue.")
  print(output)

  ===========================

  In my env (devstack master on c9s):
  $ python3 /mnt/host/virtual_port_issue.py
  Port is virtual, this is ok.
      port e0fe2894-e306-42d9-8c5e-6e77b77659e2 (aka lb-vip)
          type: virtual
          addresses: ["fa:16:3e:93:00:8f 172.24.4.111 2001:db8::178"]

  Port is not virtual, this is an issue.
      port e0fe2894-e306-42d9-8c5e-6e77b77659e2 (aka lb-vip)
          addresses: ["fa:16:3e:93:00:8f 172.24.4.111 2001:db8::178"]
      port 8ec36278-82b1-436b-bc5e-ea03ef22192f

  In Octavia, the "port: virtual" is _sometimes_ back after other
  updates of the ports, but in some cases the LB is unreachable.

  (and "ovn-nbctl lsp-set-type <vip-port-id> virtual" fixes the LB)

  === Ubuntu SRU Details ===

  [Impact]
  This bug causes loadbalancer vip ports to lose their "virtual" type in ovn and results in broken connectivity to amphora vms after failover. There are two patches, one that fixes new ports and one that retroactively fixes existing ones. We are backporting the former since it is clean and simple but the latter does not apply cleanly so we will defer.

  [Test Case]
    * deploy openstack ussuri or victoria with neutron + ovn and octavia
    * create a loadbalancer
    * check ovn-nbctl for the vip port and check that type is virtual
    * failover the loadbalancer
    * check ovn-nbctl for the vip port and check that type is still virtual and that lb vip is reachable

  [Where things could go wrong]
  There are not anticipated to be any regressions from this backport.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1973276/+subscriptions