No answers to this problem? I can't be the first to experience it..... I realized I didn't mention what distro i was using: All machines are Debian Lenny (2.6.26-2 ) Balancers are 32bit, realservers are amd64.
The IPVS setup is through keepalived which is at version 1.1.15-1, ipvsadm is at version 1:1.24-2.1 I'd really appreciate any help wtih this issue Thanks Pat On Thu, Oct 21, 2010 at 6:14 PM, Patrick Zaloum <[email protected]> wrote: > Hello > I have set up an IPVS environment using keepalived. My IPVS machines > are in a DMZ, and my real servers are behind the firewall. I have > apache running on the real servers and I am providing a VIP with > HTTP/HTTPS service pointing to the RIP's. > > I have created the tunl0 device with the VIP, and no-arp, on the real servers. > > I can ping the VIP from a client, and health check on the IPVS shows > both realservers as healthy. > > If I attempt to connect to the service from a client, I get a timeout. > I took a tcpdump in various places as I troubleshooted. My client is > receiving the return packet from the real server (as per the design) > but does not seem to accept it. I noticed in the dump that the > sequence numbers were not what I would expect: I send a SYN to the > VIP, it gets sent to a RIP over the IPIP tunnel, realserver responds > an ACK to the client. In the SYN if the sequence number is 1000 the > real server should ACK 1001... what is happening is that the > realserver is ACKing the tunnel packet, not the encapsulated packet. I > suspect this is where my problem is but I haven't found anything that > resembled this issue on Google. > > Can anyone suggest a fix? > > I will paste some relevant tcpdump output. Notice my CLIENT SYN packet > is 4244383796, TUNNEL SYN packet is 1869554645. What the client > receives from the RIP is ACKing with 1869554646 and not 4244383797 as > I would have expected. If you look at the packet sent in the tunnel > (CIP to RIP Tunnel) the SYN number is the same as the IPIP packet, NOT > the same one my client IP sent initially. > > CIP to VIP > 18:01:29.521993 IP CIP.42852 > VIP.https: S 4244383796:4244383796(0) > win 5840 <mss 1460,sackOK,timestamp 99292997 0,nop,wscale 6> > > > IPVS to RIP (IPIP) > 18:01:29.522040 IP IPVS > RIP: IP {CIP.42852 > VIP.https: S > 1869554645:1869554645(0) win 5840 <mss 1380,sackOK,timestamp 99292997 > 0,nop,wscale 6>} (ipip-proto-4) > > > CIP to RIP (Tunnel) > 18:01:29.522040 IP CIP.42852 > VIP.https: S 1869554645:1869554645(0) > win 5840 <mss 1380,sackOK,timestamp 99292997 0,nop,wscale 6> > > > RIP to CIP > 18:01:29.522175 IP VIP.https > CIP.42852: S 2673651702:2673651702(0) > ack 1869554646 win 5792 <mss 1460,sackOK,timestamp 552990048 > 99292997,nop,wscale 7> > > > Am I missing something here? Is this behaviour by design? > > Thanks in advance! > Pat > _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
