|
I've seen the post, but I didn't think that my problem was related...
Especially since my test packets are only connection oriented ones
(telnet VIP port 443). Can you go into more detail on how you dealt
with this problem? I noticed in the article they put the MSS rule on
the output chain of the real server - you are putting it on the
forward chain. Is this on the real server as well? The director?
Thanks for your help!
Pat
On Thu, Nov 4, 2010 at 4:29 PM, Malte Geierhos <malte@xxxxxxxxxxxxx> wrote:
> Hi,
>
> just a short guess : your packets get fragmented - and you're not allowing
> icmp passing through
> so it maybe related to the tcp-mss size.
>
> you tried this ? : iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j
> TCPMSS --set-mss 1300
>
> according to here :
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html
>
> it's been a while i used ipip - but this one made my day once - with some
> similar problems.
>
> regards,
> malte
>
> Am 26.10.2010 um 02:00 schrieb Patrick Zaloum:
>
>> 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 <pzaloum@xxxxxxxxx> 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 - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>> or go to 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
>
_______________________________________________
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
|
