Bug 2210903

Summary: IPSec Tunnel breaking intermittently on vms with floating ips assigned at creation
Product: Red Hat OpenStack Reporter: Dustin Ash <duash>
Component: openstack-neutronAssignee: Miro Tomaska <mtomaska>
Status: NEW --- QA Contact: Eran Kuris <ekuris>
Severity: high Docs Contact:
Priority: high    
Version: 16.2 (Train)CC: apverma, chrisw, cmuresan, dhill, fgadkano, knakai, mtomaska, scohen, spapa, twilson
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:

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.