yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #89691
[Bug 1973276] Re: OVN port loses its virtual type after port update
New versions of neutron with this fix have been uploaded to victoria-
staging and the ubuntu unapproved queue.
** Changed in: cloud-archive/xena
Status: New => Fix Released
** Changed in: cloud-archive/wallaby
Status: New => Fix Released
** Changed in: cloud-archive/victoria
Status: New => Triaged
** Changed in: cloud-archive/ussuri
Status: New => Triaged
** Changed in: cloud-archive/victoria
Importance: Undecided => High
** Changed in: cloud-archive/ussuri
Importance: Undecided => High
** Also affects: neutron (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: neutron (Ubuntu)
Status: New => Fix Released
** Changed in: neutron (Ubuntu Focal)
Importance: Undecided => High
** Changed in: neutron (Ubuntu Focal)
Status: New => Triaged
** Description changed:
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')
-
+ 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)
-
+ 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]
-
+ 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)
+ 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}])
-
+ 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)
+ 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("Port is virtual, this is ok.")
print(output)
-
+
conn.network.update_port(
- vip_port,
- security_group_ids=[sg.id])
-
+ 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)
+ 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("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 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
+ 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)
- In Octavia, the "port: virtual" is _sometimes_ back after other updates of the ports, but in some cases the LB is unreachable.
+ === Ubuntu SRU Details ===
- (and "ovn-nbctl lsp-set-type <vip-port-id> virtual" fixes the LB)
+ [Impact]
+ See above
+
+ [Test Case]
+ See above
+
+ [Where things could go wrong]
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
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:
Triaged
Status in Ubuntu Cloud Archive victoria series:
Triaged
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:
Triaged
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]
See above
[Test Case]
See above
[Where things could go wrong]
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1973276/+subscriptions
References
