Bug 2268207

Summary:	[ML2/OVN] Floating IP commnunications are broken for Master octavia amphora HA VIP
Product:	Red Hat OpenStack	Reporter:	Alex Stupnikov <astupnik>
Component:	python-networking-ovn	Assignee:	Fernando Royo <froyo>
Status:	CLOSED MIGRATED	QA Contact:	Toni Freger <tfreger>
Severity:	high	Docs Contact:	Greg Rakauskas <gregraka>
Priority:	high
Version:	16.2 (Train)	CC:	apevec, bcafarel, cldavey, ebarrera, egarciar, ekuris, froyo, gthiemon, lhh, majopela, mariel, michjohn, mtomaska, scohen, tweining
Target Milestone:	z7	Keywords:	Triaged
Target Release:	16.2 (Train on RHEL 8.4)
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: Virtual ports created with a custom device_owner was loosing the type.virtual on OVN NB DB as soon traffic was sent/received over it. Consequence: The Port Binding associated to the VIP port is recreated as soon Virtual Port change the type. Loosing the Chassis and virtual-parents info. In DVR envs, with distributed Floating IP, traffic over the FIP attached to the VIP is not replied. Fix: Virtual ports that would be use to redirect traffic over VM ports needs to be created using device_owner value of 'virtual_port'. Special case for Octavia, that is creating VIP LB ports using device_owner 'Octavia' is also covered.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2025-01-10 10:37:02 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:	2317059
Bug Blocks:

Description Alex Stupnikov 2024-03-06 16:33:53 UTC

Description of problem:

One of our VIP customers is trying to use Floating IP address to enable external access to Octavia HA VIP. He followed steps described in https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/using_octavia_for_load_balancing-as-a-service/index#http-lb-float-ip_create-non-secure-http-lbs , but failed to get functional setup: real ha_ip is reachable for other instances and they can establish HTTPS connections to it, while communications are not established for floating IP address associated with real ha_ip.

During remote session we tried to isolate a root cause by using client VM connected to client tenant network with client FIP attached and running on client compute. Client VM was used to connect to FIP address associated with real ha_ip. Both floating IP addresses were in the same external network. We found out that client compute node sends ARP requests for destination floating IP address, they arrive at destination compute node, but there is no reply from OVN. So ARP is unresolved and communications are not established.

For some reason, ha_ip Neutron port had admin_state_up set to down because port was in disabled state. So Octavia setup is slightly different from our general recommendations at https://access.redhat.com/solutions/6629051. Nonetheless, enabling the port didn't help.

Customer is able to consistently reproduce this problem for Octavia amphora-based loadbalancers. Regular instances using floating IP addresses are not affected by anything
similar. Information about available data will be provided privately.

At this point this problem is not severe blocker for customer, but this may change in the future.

Version-Release number of selected component (if applicable):
Red Hat OpenStack Platform release 16.2.6 (Train)

How reproducible:
Follow recommendations from https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html-single/using_octavia_for_load_balancing-as-a-service/index#http-lb-float-ip_create-non-secure-http-lbs

Actual results:
FIP is not reachable for external entities

Expected results:
FIP is reachable for external entities and they can use it to communicate with ha_ip