Bug 2210903 - IPSec Tunnel breaking intermittently on vms with floating ips assigned at creation
Summary: IPSec Tunnel breaking intermittently on vms with floating ips assigned at cre...
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 16.2 (Train)
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Miro Tomaska
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-05-30 02:09 UTC by Dustin Ash
Modified: 2023-08-16 03:10 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-25449 0 None None None 2023-05-30 02:10:05 UTC

Comment 7 Simon Papa 2023-06-28 23:00:19 UTC
Hi All,

To further answer some of the queries posted here, there is a relatively recent sos report from one of the computes (mid May) attached to the case.

The CU has also just uploaded a vm coredump to the case to assist in troubleshooting.

Regards,

Simon

Comment 14 Dustin Ash 2023-07-27 19:01:19 UTC
The customer has provided the following requested information;

● What is the RHEL OS version in VM ?
This is custom image that is running kernel  - Linux version 4.14
● Is this issue observed on multiple computes or only in any specific compute ?
Multiple computes. 
● The same issue is observed only on any specific VM or on different VMs ? 
Specific VM 
● VM reboot is triggered from within the OS or from RHOSP end ?
We are rebooting the VM from RHOSP. 
● Please share all the technical details on how you check the unresponsiveness of port1 (public network) and port2 (internal network) is responsive.
After some time, port1 (external network) become unresponsive and we are not able to receive any traffic on this port. Meanwhile port2 is responsive and working properly. We are checking it with ping/ssh/nc tools. 

The customer acknowledges and I have notified the customer that the case will be in Waiting on Customer status until we receive the following additional information;

● The name of the VM on which this issue was last observed.
● Sosreport from the compute on which the affected VM was present at that time.
● Exact issue timestamp.
● Sosreports from all the three controllers.
● The involved ports and network details are also required.


Note You need to log in before you can comment on or make changes to this bug.