Bug 2135270

Summary:	Detach OVN-LB LS from the LR breaks OVN-LB connectivity
Product:	Red Hat OpenStack	Reporter:	Luis Tomas Bolivar <ltomasbo>
Component:	python-ovn-octavia-provider	Assignee:	Luis Tomas Bolivar <ltomasbo>
Status:	CLOSED ERRATA	QA Contact:	Bruna Bonguardo <bbonguar>
Severity:	high	Docs Contact:
Priority:	high
Version:	17.0 (Wallaby)	CC:	erpeters, gregraka, oschwart
Target Milestone:	z1	Keywords:	Triaged
Target Release:	17.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	python-ovn-octavia-provider-1.0.1-0.20221122190308.bbf881f.el9ost	Doc Type:	Bug Fix
Doc Text:	Before this update, when you re-added a logical switch (LS) to a logical router (LR) the OVN load balancer would lose connectivity. This problem would occur to OVN load balancers on OpenStack Networking service (neutron) networks that contained IPv4 and IPv6 subnets and were connected to an LR. When a subnet was first removed from the network, the load balancer would improperly lose its association to the datapath, because it was incorrectly assumed that all router ports that belong to all subnets were being removed and the load balancer was removed from the OVN southbound database. + In Red Hat OpenStack Platform 17.0.1, the IP version is checked so that router ports that belong to other subnets are not considered, and the OVN load balancer is not removed from the LS. This results in the load balancer having proper connectivity when a subnet is removed from the router and resolves the issue.	Story Points:	---
Clone Of:
Clones:	2135271 (view as bug list)		Environment:
Last Closed:	2023-01-25 12:29:56 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2135271, 2136017

Description Luis Tomas Bolivar 2022-10-17 07:25:17 UTC

If an OVN-LB is in a LS connected to a LR, upon removal of the LS from the LR the loadbalancer should be removed from the LR but should be kept at the LS, and still provide connectivity within that LS.

However, this is not the case and the loadbalancer is also removed from the LS, leading to the removal of the LB from the OVN SB DB, and consequently beaking the connectivity as the flows for the LB are not installed

Comment 19 Omer Schwartz 2022-12-20 09:29:46 UTC

After running the following commands:

# Networking resources for Octavia
openstack router create bz-router
openstack network create bz-net
openstack subnet create --subnet-range 192.168.1.0/24 --network bz-net --dns-nameserver 10.35.28.28 bz-sub
openstack router add subnet bz-router bz-sub
openstack router set --external-gateway public bz-router

# inst-1 will be the member server, inst-2 will be the other vm
openstack server create --wait --flavor c1 --image cirros-0.4.0-x86_64-disk.img --network bz-net inst-1
openstack server create --wait --flavor c1 --image cirros-0.4.0-x86_64-disk.img --network bz-net inst-2

openstack server list-f value
718ad435-f9bc-4dde-9ba8-b3f0b59d2637 inst-1 ACTIVE {'bz-net': ['192.168.1.144']} cirros-0.4.0-x86_64-disk.img c1
6a621fce-eb26-4361-8bd0-9b15842c6921 inst-2 ACTIVE {'bz-net': ['192.168.1.199']} cirros-0.4.0-x86_64-disk.img c1


openstack security group create bz-sg
(openstack) security group rule create --protocol tcp --dst-port 22 bz-sg
(openstack) security group rule create --protocol tcp --dst-port 80 bz-sg
(openstack) security group rule create --protocol tcp --dst-port 8080 bz-sg
(openstack) security group rule create --protocol icmp bz-sg

openstack server add security group inst-1 bz-sg
openstack server add security group inst-2 bz-sg

# I create the FIP to scp the Octavia testing server to the member
openstack floating ip create public
openstack server add floating ip inst-1 10.0.0.200
scp -O -o StrictHostKeyChecking=no /home/stack/test_server.bin cirros.0.200:/home/cirros/
openstack floating ip delete 10.0.0.200

# Octavia resources
openstack loadbalancer create --wait --vip-subnet-id bz-sub --provider ovn --name bz-lb-ovn
openstack loadbalancer listener create --name listener1 --protocol TCP --protocol-port 80 bz-lb-ovn
openstack loadbalancer pool create --name pool1 --lb-algorithm SOURCE_IP_PORT --listener listener1 --protocol TCP
openstack loadbalancer member create --name member1 --address 192.168.1.144 --subnet-id bz-sub --protocol-port 80 pool1

# Running the Octavia's testing server on the backend member
ssh compute-0.ctlplane
[tripleo-admin@compute-0 ~]$ sudo -i
[root@compute-0 ~]# podman exec -it nova_virtqemud /bin/bash
[root@compute-0 /]# virsh console 718ad435-f9bc-4dde-9ba8-b3f0b59d2637
Connected to domain 'instance-00000023'
Escape character is ^] (Ctrl + ])
  
login as 'cirros' user. default password: 'gocubsgo'. use 'sudo' for root.
inst-1 login: cirros
Password: 
$ sudo ./test_server.bin -id 1 -port 80


# On another terminal, I am SSHing with virsh console to the other vm which is in the same subnet.
# I curl the LB VIP:
$ curl 192.168.1.95
1$

# I could curl successfully.


# When I remove the subnet from the router:
openstack router remove subnet bz-router bz-sub

# I get
$ curl 192.168.1.95
curl: (7) Failed to connect to 192.168.1.95 port 80: No route to host

# That is because without a router connected to the subnet, nobody is replying to the arp request
# Whenever I am re-adding the subnet to the router
openstack router add subnet bz-router bz-sub

# I get connectivity again
$ curl 192.168.1.95
$ curl 192.168.1.95
1$


After verifying with assignee, that is the expected behavior for the fix of the BZ. I am moving the BZ status to VERIFIED.

Comment 27 errata-xmlrpc 2023-01-25 12:29:56 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenStack Platform 17.0.1 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:0271