Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-50912

Use the new OVN ct-commit-all option

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • 4.18
    • None
    • None
    • False
    • Hide

      None

      Show
      None

      As part of the UDN work in OVN-Kubernetes we are trying to enable k8s LoadBalancer services with ExternalTrafficPolicy=Local.
      
      To achieve that we forward the traffic tho the management interface(ovn-k8s-mp1) of the UDN after DNATing it to a predefined IP(169.254.0.3).
      
      This traffic flow doesn't work, after the connection is established subsequent reply packets are getting SNATed by this NAT rule:
      
      [root@ovn-control-plane ~]# ovn-nbctl lr-nat-list l3nad_ovn_cluster_router
      TYPE             GATEWAY_PORT          MATCH                 EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP          EXTERNAL_MAC         LOGICAL_PORT
      snat                                   eth.dst == 36:47:2    169.254.0.12                        100.100.1.0/24 
      
      tshark -r masq_snat/ovn-control-plane_ovn-k8s-mp1_port_6666.pcap
          1   0.000000   172.22.0.3 → 169.254.0.3  TCP 74 6666 → 32740 [SYN] Seq=0 Win=32120 Len=0 MSS=1460 SACK_PERM=1 TSval=785707095 TSecr=0 WS=128
          2   0.003085  169.254.0.3 → 172.22.0.3   TCP 74 32740 → 6666 [SYN, ACK] Seq=0 Ack=1 Win=32448 Len=0 MSS=1260 SACK_PERM=1 TSval=4164526464 TSecr=785707095 WS=128
          3   0.003384   172.22.0.3 → 169.254.0.3  TCP 66 6666 → 32740 [ACK] Seq=1 Ack=1 Win=32128 Len=0 TSval=785707098 TSecr=4164526464
          4   0.003403   172.22.0.3 → 169.254.0.3  HTTP 147 GET / HTTP/1.1 
          5   0.004127 169.254.0.12 → 172.22.0.3   TCP 66 9376 → 6666 [ACK] Seq=1 Ack=1 Win=253 Len=0 TSval=4164526466 TSecr=785707098
       
      
      172.22.0.3 - external client, 32740 - service nodePort, 9376 - backend service port. The SYN-ACK is not SNATed(this is what we want).
      
      One thing I observed is that after removing the match condition from the SNAT the traffic worked as expected without getting SNATed to 169.254.0.12.
      
      Attaching the DBs and the packet capture.
      
      The node involved in the repro is ovn-control-plane, backend pod is running on it and it's UDN IP is 100.100.1.9. 

      There is a new option on ovn 25.03 and further called "ct-commit-all" that can be set for each LR. This should avoid the mentioned issue.

              sseethar Surya Seetharaman
              amusil@redhat.com Ales Musil
              Anurag Saxena Anurag Saxena
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: