[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
This bug was fixed in the package neutron - 2:16.4.2-0ubuntu4~cloud0 --- neutron (2:16.4.2-0ubuntu4~cloud0) bionic-ussuri; urgency=medium . * New update for the Ubuntu Cloud Archive. . neutron (2:16.4.2-0ubuntu4) focal; urgency=medium . [ Zhang Hua ] * d/p/defer-flow-deletion-in-openvswitch-firewall.patch: Defer flow deletion in openvswitch firewall (LP: #1975674) . [ Edward Hope-Morley ] * Ensure ovn virtual port type not removed (LP: #1973276) - d/p/ovn-allow-vip-ports-with-defined-device-owner.patch - d/p/set-type-virtual-for-ovn-lsp-with-parent-ports.patch ** Changed in: cloud-archive/ussuri Status: Fix Committed => Fix Released -- 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: 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 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
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
This bug was fixed in the package neutron - 2:16.4.2-0ubuntu4 --- neutron (2:16.4.2-0ubuntu4) focal; urgency=medium [ Zhang Hua ] * d/p/defer-flow-deletion-in-openvswitch-firewall.patch: Defer flow deletion in openvswitch firewall (LP: #1975674) [ Edward Hope-Morley ] * Ensure ovn virtual port type not removed (LP: #1973276) - d/p/ovn-allow-vip-ports-with-defined-device-owner.patch - d/p/set-type-virtual-for-ovn-lsp-with-parent-ports.patch -- Corey Bryant Thu, 15 Sep 2022 15:42:05 -0400 ** Changed in: neutron (Ubuntu Focal) Status: Fix Committed => Fix Released -- 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: Fix Committed 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 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
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
This bug was fixed in the package neutron - 2:17.4.1-0ubuntu1~cloud3 --- neutron (2:17.4.1-0ubuntu1~cloud3) focal-victoria; urgency=medium . [ Zhang Hua ] * d/p/defer-flow-deletion-in-openvswitch-firewall.patch: Defer flow deletion in openvswitch firewall (LP: #1975674) . [ Edward Hope-Morley ] * Ensure ovn virtual port type not removed (LP: #1973276) - d/p/ovn-allow-vip-ports-with-defined-device-owner.patch - d/p/set-type-virtual-for-ovn-lsp-with-parent-ports.patch ** Changed in: cloud-archive/victoria Status: Fix Committed => Fix Released -- 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: Fix Committed 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 Committed 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 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
[Yahoo-eng-team] [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
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
** Changed in: cloud-archive/zed Status: New => Fix Released ** Changed in: cloud-archive/yoga Status: New => Fix Released -- 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: New Status in Ubuntu Cloud Archive victoria series: New Status in Ubuntu Cloud Archive wallaby series: New Status in Ubuntu Cloud Archive xena series: New 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: New 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 virtual" fixes the LB) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1973276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/xena Importance: Undecided Status: New ** Also affects: cloud-archive/yoga Importance: Undecided Status: New ** Also affects: cloud-archive/zed Importance: Undecided Status: New ** Also affects: cloud-archive/ussuri Importance: Undecided Status: New ** Also affects: cloud-archive/victoria Importance: Undecided Status: New ** Also affects: cloud-archive/wallaby Importance: Undecided Status: New -- 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: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in Ubuntu Cloud Archive wallaby series: New Status in Ubuntu Cloud Archive xena series: New Status in Ubuntu Cloud Archive yoga series: New Status in Ubuntu Cloud Archive zed series: New Status in neutron: Fix Released Status in neutron package in Ubuntu: New 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 virtual" fixes the LB) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1973276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
** Also affects: neutron (Ubuntu) Importance: Undecided Status: New -- 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 neutron: Fix Released Status in neutron package in Ubuntu: New 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 virtual" fixes the LB) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1973276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
** Changed in: neutron Status: Invalid => In Progress ** Changed in: neutron Importance: High => Medium ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- 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 neutron: In Progress 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 virtual" fixes the LB) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1973276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1973276] Re: OVN port loses its virtual type after port update
The problem in the python reproducer is the VIP device_owner. The VIP must not have one. Once removed from the python reproducer code, the VIP never looses its type "virtual". ** Changed in: neutron Status: New => Invalid -- 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 neutron: Invalid 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 virtual" fixes the LB) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1973276/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp