Re: [lvs-users] Unexpected source IP selection in IPVS TUN

["Calvin Zachman" <calvin.zachman@xxxxxxx>]

   Hi Julian,

   That is the exact issue we are seeing. Thank you for the guidance. I will
   look  into  whether we can update to the latest RHEL with newer kernel
   version.
   I  know it's probably a long shot, but are you aware of any workaround
   without updating?

   Thanks,
   Calvin

     ----- Original message -----
     From: Julian Anastasov <ja@xxxxxx>
     Sent by: lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx
     To: Calvin Zachman <calvin.zachman@xxxxxxx>
     Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
     Subject: [EXTERNAL] Re: [lvs-users] Unexpected source IP selection in IPVS
     TUN
     Date: Mon, Apr 6, 2020 8:49 AM

   Hello,
   On Mon, 6 Apr 2020, Calvin Zachman wrote:
   >    EXPECTED BEHAVIOR: IPVS encapsulates the traffic with IPinIP using the
   IP
   >     address from the private interface of the VM (10.X.X.X). Example
   traffic
   >    successfully balanced from LVS director VM 10.221.95.2 to remote real
   server
   >    10.221.95.5:
   >
   >    # tcpdump -n -i eth0 host 10.221.95.2 and proto 4
   >    13:58:28.151571 IP 10.221.95.2 > 10.221.95.5: IP 52.117.148.54.64369 >
   >    169.46.4.90.80:  Flags  [S],  seq  180302151,  win 65535, options [mss
   >      1460,sackOK,TS  val  590414746  ecr  0,nop,wscale  9], length 0
   (ipip-proto-4)
   >    13:58:28.152447 IP 10.221.95.2 > 10.221.95.5: IP 52.117.148.54.64369 >
   >    169.46.4.90.80: Flags [.], ack 2964164084, win 128, options [nop,nop,TS
   val
   >    590414747 ecr 89050127], length 0 (ipip-proto-4)
   >    13:58:28.152467 IP 10.221.95.2 > 10.221.95.5: IP 52.117.148.54.64369 >
   >      169.46.4.90.80:  Flags  [P.], seq 0:75, ack 1, win 128, options
   [nop,nop,TS
   >      val  590414747  ecr  89050127], length 75: HTTP: GET / HTTP/1.1
   (ipip-proto-4)
   >    13:58:28.154037 IP 10.221.95.2 > 10.221.95.5: IP 52.117.148.54.64369 >
   >    169.46.4.90.80:  Flags  [.], ack 723, win 131, options [nop,nop,TS val
   >    590414749 ecr 89050129], length 0 (ipip-proto-4)
   >
   >    NOTE: The above trace was grabbed after finding a way around the issue
   (see
   >    below)  and depicts only inbound traffic from the LVS. DSR carries the
   >    response back to the client out eth1.
   >    OBSERVED BEHAVIOR: IPVS mysteriously encapsulates traffic with source
   IP
   >    from  127.X.255.255.  Running  tcpdump  from  the  remote  real server
   >    (10.221.95.5):
   >
   >    # tcpdump -n -i eth0 net 127.0.0.0/8 and proto 4
   >    tcpdump: verbose output suppressed, use -v or -vv for full protocol
   decode
   >    listening on eth0, link-type EN10MB (Ethernet), capture size 262144
   bytes
   >    23:43:34.065782 IP 127.138.255.255 > 10.221.95.5: IP 52.117.148.54.3595
   >
   >    169.46.4.90.80:  Flags  [S],  seq  146570019,  win 65535, options [mss
   Looking at archives I found thread that can help you:
   [1]https://marc.info/?t=153556562900003&r=1&w=2
   Check if your kernel has this line removed from
   do_output_route4():
   fl4.saddr = (rt_mode & IP_VS_RT_MODE_CONNECT) ? *saddr : 0;
   Probably, it is present.
   Regards
   --
   Julian Anastasov <ja@xxxxxx>
   _______________________________________________
   Please read the documentation before posting - it's available at:
   [2]http://www.linuxvirtualserver.org/
   LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
   Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
   or go to [3]http://lists.graemef.net/mailman/listinfo/lvs-users

References

   1. https://marc.info/?t=153556562900003&r=1&w=2
   2. http://www.linuxvirtualserver.org/
   3. http://lists.graemef.net/mailman/listinfo/lvs-users
_______________________________________________
Please read the documentation before posting - it's available at:
http://www.linuxvirtualserver.org/

LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users