[Bug 1973276] [NEW] OVN port loses its virtual type after port update

[Launchpad Bug Tracker]

You have been subscribed to a public bug by Ubuntu Foundations Team Bug Bot (crichton):

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)

** Affects: cloud-archive
     Importance: Undecided
         Status: Fix Released

** Affects: cloud-archive/ussuri
     Importance: Undecided
         Status: New

** Affects: cloud-archive/victoria
     Importance: Undecided
         Status: New

** Affects: cloud-archive/wallaby
     Importance: Undecided
         Status: New

** Affects: cloud-archive/xena
     Importance: Undecided
         Status: New

** Affects: cloud-archive/yoga
     Importance: Undecided
         Status: Fix Released

** Affects: cloud-archive/zed
     Importance: Undecided
         Status: Fix Released

** Affects: neutron
     Importance: Medium
     Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez)
         Status: Fix Released

** Affects: neutron (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: in-stable-ussuri in-stable-victoria in-stable-wallaby in-stable-xena in-stable-yoga ovn patch
-- 
OVN port loses its virtual type after port update
https://bugs.launchpad.net/bugs/1973276
You received this bug notification because you are a member of Ubuntu Sponsors Team, which is subscribed to the bug report.