Hide Forgot
This bug was initially created as a copy of Bug #2053609 I am copying this bug because: Description of problem: If an SCTP LoadBalancer service is deleted and re-created later with the same load balancer IP but different cluster IP, there is an old conntrack entry that causes packets to be still dnatted to the old cluster IP instead of the new one. The iptables rules are correct, it is just the entry in the conntrack table what seems to wreak havoc. If that entry is manually removed, everything starts working. Version-Release number of selected component (if applicable): 4.8 How reproducible: Consistently at customer side Steps to Reproduce: 1. Install a LoadBalancer service with a SCTP port 2. Use it normally 3. Delete everything (in our case, it is done with helm uninstall, but that's not relevant) 4. Wait some time 5. Re-create the same LoadBalancer service such that it has the same load balancer IP, but let a different cluster IP be chosen at random. Actual results: Traffic is dnatted to old cluster IP and does not reach its destination. Expected results: Traffic to be dnatted to the right cluster IP and reach its destination Additional info: conntrack -D -r $OLD_CLUSTER_IP workarounds the issue. More information in comments.
Testing passed in 4.10.0-0.nightly-2022-05-10-182617 by following the verifying steps from https://github.com/ovn-org/ovn-kubernetes/pull/2829
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 (OpenShift Container Platform 4.10.14 bug fix update), 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-2022:2178