Uploaded image for project: 'Fast Datapath Product'
  1. Fast Datapath Product
  2. FDP-1009

OVN-Kubernetes: LoadBalancer reply traffic SNATed to joinIP

    • 5
    • False
    • Hide

      None

      Show
      None
    • False
    • ovn24.09-24.09.1-61.el9fdp
    • rhel-9
    • ssg_networking
    • +

      We are observing an unexpected behavior in a scenario where a LoadBalancer contains a VIP that is equal to the client IP:

       

       _uuid               : 0dea00a4-7c0b-4f48-b3b1-2f1d0805ba20
      external_ids        : {"k8s.ovn.org/kind"=Service, "k8s.ovn.org/network"=l2-network, "k8s.ovn.org/owner"="nad-l2/test", "k8s.ovn.org/role"=primary}
      health_check        : []
      ip_port_mappings    : {}
      name                : "l2.network_Service_nad-l2/test_TCP_node_router+switch_ovn-control-plane"
      options             : {event="false", hairpin_snat_ip="169.254.0.5 fd69::5", neighbor_responder=none, reject="true", skip_snat="false"}
      protocol            : tcp
      selection_fields    : []
      vips                : {"10.96.20.214:9376"="10.128.0.15:9376", "172.18.0.3:9376"="10.128.0.15:9376", "172.18.0.4:9376"="10.128.0.15:9376"}

       

      In a scenario where a request is made from 172.18.0.3 to 172.18.0.4:9376 the reply traffic leaves the server node with the source IP equal to lb_force_snat_ip value of the GW router(currently set to the join IP):

      15:50:16.179964 eth0  In  ifindex 82 02:42:ac:12:00:03 ethertype IPv4 (0x0800), length 80: 172.18.0.3.6666 > 172.18.0.4.9376: Flags [S], seq 779931353, win 65280, options [mss 1360,sackOK,TS val 4221977849 ecr 0,nop,wscale 7], length 0
      15:50:16.180616 71fee46a0d3b9_3 Out ifindex 70 0a:58:64:41:00:02 ethertype IPv4 (0x0800), length 80: 100.65.0.2.6666 > 10.128.0.15.9376: Flags [S], seq 779931353, win 65280, options [mss 1360,sackOK,TS val 4221977849 ecr 0,nop,wscale 7], length 0
      15:50:16.180632 71fee46a0d3b9_3 P   ifindex 70 0a:58:0a:80:00:0f ethertype IPv4 (0x0800), length 72: 10.128.0.15.9376 > 100.65.0.2.6666: Flags [.], ack 1274067726, win 507, options [nop,nop,TS val 516652703 ecr 4221787239], length 0
      15:50:16.180650 eth0  Out ifindex 82 02:42:ac:12:00:04 ethertype IPv4 (0x0800), length 72: 100.65.0.2.9376 > 172.18.0.3.6666: Flags [.], ack 1274067726, win 507, options [nop,nop,TS val 516652703 ecr 4221787239], length 0
      15:50:16.180654 breth0 P   ifindex 5 02:42:ac:12:00:04 ethertype IPv4 (0x0800), length 72: 100.65.0.2.9376 > 172.18.0.3.6666: Flags [.], ack 1, win 507, options [nop,nop,TS val 516652703 ecr 4221787239], length 0
      

      The issue doesn't occur when the clientIP is not one of the VIPs.

       

              amusil@redhat.com Ales Musil
              pdiak@redhat.com Patryk Diak
              Jianlin Shi Jianlin Shi
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: