|
Casey,
The problem is one I am only too familiar with.
It is caused by the linux kernel not taking into account the size ipip tunnel
headers when sending traffic over an ip tunnel.
Basically, the MTU (maximum transmition unit - the largest size ov packet than
can be sent over a network) is normally 1500 bytes. With the IP header
information this drops to 1492 so the largest size of packet that can be sent
of an IP link before the packet get split into multiple packets is 1492 bytes.
When you use ipip tunneling there is an additional header that takes the
maximum transmition size through the link to somthing like 1480. Linux kernel
2.4.??? does not take into account this additional header and sets the mtu for
the ip tunnel to 1492. So if you send a packet that is between 1480 and 1492 it
gets truncated rather than split into multiple packets. The ip tunnel
destination then waits to recieve that rest of the packet which it never does.
The result is the server never responds.
When I was having this problem it was a nightmare because you can not guarantee
it will fail. It only fails when the packet size is very specific and the size
of the header is also large.
To fix this you can either.
1. Upgrade to kernel 2.6.???
2. Change the MTU values on the director.
I solved it by changing the MTU values, but it was nearly a year ago now I a
can't remember exactly which ones I changed, ie, the RIP on the director, the
tunnel from the director, or the tunnel from the real server.
If anyone can put some light on which one needs changing that would be very
helpfull as if we need to re-install I will be stuffed!
Hope this helps.
Chris
-----Original Message-----
From: Casey Zacek [mailto:cz@xxxxxxxxxxxx]
Sent: 27 May 2004 01:26
To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Large HTTP GET/POST timeout
I've been searching for resolutions for this problem all day, and the
only thing I've found is this old thread:
http://www.in-addr.de/pipermail/lvs-users/2003-February/007885.html
The problem, as described by one of my customers, is this (the
customer is running phpBB on 3 Linux/Apache servers with an LVS-Tun
setup):
"For very few users, when they post long posts (anything over a few
lines) and hit submit, the browser appears to hang and finally it
times out. Similar effects if they try and update their profiles. I
even experienced this on my home computer. I use a proxy server
sometimes and it showed the request being transmitted from my computer
but ultimately no response was received from the site. Now, in most
instances of this, we have found that the affected users are on
broadband using a router of some type. I myself use a cable modem
connected through a Linksys Router. When I experienced the issue, I
was able to post from work, but not from home. I fiddled with my
setup, thinking it was cookies or caching of some type and ultimately
performed a firmware upgrade on my router. Suddenly the problem went
away."
At the time, I was running kernel 2.4.25 (IPVS 1.0.10), but since
upgraded to 2.4.26 (IPVS 1.0.11), then 2.6.6 (IPVS 1.2.0). I have
asked the customer to retest it, but he'll have to talk to some of his
users, from the sound of things, since he upgraded his router
firmware. I'd love to chalk it up to "client router problems," but
that probably won't be good enough for this customer. It worked using
a Riverstone smartswitch router running what equates to LVS-NAT, but
it does not work with this LVS-Tun setup.
With all three versions, I get a lot of these messages:
IPVS: ip_vs_tunnel_xmit(): frag needed
I don't know if it's related, but I'm pretty sure it is after reading
that thread.
Any help is appreciated.
--
Casey Zacek
Senior Engineer
NeoSpire, Inc.
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
Berkeley Alexander
Temple House, 25-26 High Street, Lewes, East Sussex, BN7 2SD
Tel 01273 477784, Fax 01273 478994
www.baonline.co.uk
PLEASE NOTE:
The information in this e-mail is confidential and may be legally privileged.
It may not represent the views of Berkeley Alexander. It is intended solely for
the addressees. Access to this e-mail by anyone else is unauthorised. If you
are not the intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any unauthorised recipient should advise the sender immediately of
the error in transmission.
|
