-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
-
None
-
None
-
None
-
-
None
-
None
-
None
-
None
-
None
1. Proposed title of this feature request
Synchronize conntrack state to allow egress IP migration on connections with only server->client traffic
2. What is the nature and description of the request?
During the investigation of OCPBUGS-58355, it was found that if an egress IP is migrated to a different node while TCP connections are established, server-to-client (i.e. external-to-pod) traffic on the same connection will be blocked until some client-to-server (i.e. pod-to-external) traffic is generated.
The above happens because the new node doesn't have the conntrack state from the older node, so conntrack on the new node doesn't know about the existing connections until the pod generates some traffic to the external systems (which triggers conntrack entries re-generation). It is important to note that user traffic must be generated from client to server for this
In the bug, engineering deemed that impossible to fix as a bug and stated that RFE is required. So I am rasing RFE to have a mechanism added to OVN-Kubernetes such that this conntrack synchronization happens.
There is already software that performs this kind of synchronization (like conntrackd), but it is likely that we will need something
3. Why does the customer need this? (List the business requirements here)
Customers need this because any workaround requires modifying the client application (either to generate client-to-server traffic or have some other kind of retry mechanism) and the customer needs to deploy applications not controlled by them, either because those are 3rd-party applications and/or may be subject to other kinds of limitations
4. List any affected packages or components.
OVN-Kubernetes
- is caused by
-
OCPBUGS-58355 After an egress IP is moved to a different node, pods won't receive any TCP traffic until they send some traffic
-
- Closed
-