-
Bug
-
Resolution: Done
-
Major
-
4.19.0
-
Quality / Stability / Reliability
-
False
-
-
None
-
Important
-
None
-
None
-
None
-
None
-
In Progress
-
Known Issue
-
-
None
-
None
-
None
-
None
This is a clone of issue OCPBUGS-53248. The following is the description of the original issue:
—
This is a clone of issue OCPBUGS-52160. The following is the description of the original issue:
—
This is a clone of issue OCPBUGS-51015. The following is the description of the original issue:
—
This is a clone of issue OCPBUGS-50599. The following is the description of the original issue:
—
Hitting an OVN issue in openshift on openstack (RHOS-17.1-RHEL-9-20241030.n.1)
Affecting 4.18 openshift: On openshift-on-opentack we have a VIP moving between the 3 masters that is attached to a FIP.
The fist openshift deployment works, but when we run a recovery procedure that moves that VIP to other master that is located in other compute, the FIP<->VIP relationship stop working.
According to our checks, we think this is happening because the router and the VM reside on different compute:
- Given below FIP association:
(shiftstack) [stack@undercloud-0 ~]$ openstack floating ip show 10.46.44.120 +---------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +---------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | created_at | 2025-02-09T09:12:22Z | | description | API ostest.shiftstack.local | | dns_domain | | | dns_name | | | fixed_ip_address | 192.168.192.5 | | floating_ip_address | 10.46.44.120 | | floating_network_id | 5b9a7486-ad95-4e95-8653-1922a993af26 | | id | 20b1edcb-8f2f-4805-a40e-374ed60c1411 | | name | 10.46.44.120 | | port_details | admin_state_up='True', device_id='', device_owner='', mac_address='fa:16:3e:3d:1e:a3', name='api-dualstack', network_id='4a896f9a-44bf-45f9-895c-f7e08877b599', status='DOWN' | | port_id | b12ed35c-6014-405b-a6e2-1ba4d0c47975 | | project_id | 1797a40f09a24e4991fd990e1e55f225 | | qos_policy_id | None | | revision_number | 2 | | router_id | 27f9e563-7236-4c10-9fff-a577bc2d8002 | | status | ACTIVE | | subnet_id | None | | tags | [] | | updated_at | 2025-02-09T09:19:16Z | +---------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
- When the VM and the router are on different places:
- The ping send from the under to the FIP reaches the router in compute-2, and reply never comes back:
[root@compute-2 ~]# tcpdump -i any icmp 10:53:45.490472 enp6s0f0 P IP 10.46.44.66 > 10.46.44.120: ICMP echo request, id 20, seq 1496, length 64 10:53:45.490492 genev_sys_6081 Out IP 10.46.44.66 > 192.168.192.5: ICMP echo request, id 20, seq 1496, length 64
-
- And it reaches compute-0 where the VM resides:
10:28:18.706577 genev_sys_6081 P IP 10.46.44.66 > 192.168.192.5: ICMP echo request, id 20, seq 5, length 64 10:28:18.706593 tap2b133192-c6 Out IP 10.46.44.66 > 192.168.192.5: ICMP echo request, id 20, seq 5, length 64 10:28:18.706683 tap2b133192-c6 P IP 192.168.192.5 > 10.46.44.66: ICMP echo reply, id 20, seq 5, length 64
The reply is not resent to the geneve tunnel.
Linked sosreport for compute-2 and compute-0 on private comment.