Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-8054

Synchronize conntrack state to allow egress IP migration on connections with only server->client traffic

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Network - Core
    • None
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • 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

              mcurry@redhat.com Marc Curry
              rhn-support-palonsor Pablo Alonso Rodriguez
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                None
                None