|
HI Matthew,
How big is the size of his POST - does it exceed one packet?
There has been a reported problem with TUN from the HowTo:
--------------------------------------------------------------------------
Since the mtu is fixed, the header reduces the payload size and
occasionally will require fragmenting of packets being sent from the
director to the realserver in LVS-Tun. LVS doesn't have any special code
to handle this situation. So far (Nov 2003) no-one has had problems
(possibly indicating that few people are using LVS-Tun), but eventually it
happened
--------------------------------------------------------------------------
This fragmenting may explain why when he goes "direct" to the real
server there is no problem.
More from the HowTo:
--------------------------------------------------------------------------
In reality, it's not "the end of the IP tunnel that initiates the tunnel"
because the tunnel interface on the W2k box doesn't initiate anything --
it only receives forwarded traffic from the director. What he really means
is "the interface on the real server that is handshaking the TCP
connection with the client." The goal is to get the client to send smaller
packets so that they'll make it on to the realserver.
CLIENT sends SYN to DIRECTOR
DIRECTOR encapsulates SYN packet in IPIP tunnel; sends to REALSERVER
REALSERVER receives SYN packet on LOOPBACK interface
REALSERVER sends SYNACK to CLIENT from LOOPBACK interface w/ MSS=1452
CLIENT sends ACK to DIRECTOR, on to REALSERVER
REALSERVER responds to CLIENT from LOOPBACK
repeat until dead
So, we have to change that MSS that gets sent back from realserver to
client. That is, set the MTU on the loopback interface on the Win2k box.
The solution is to do exactly what Chris Paul Chris said, except change
from:
hklm\system\currentcontrolset\services\tcpip\parameters\interfaces\{guid
of ip tunnel}
to:
hklm\system\currentcontrolset\services\tcpip\parameters\interfaces\{guid
of MS Loopback Adapter}
After all, if you set an MTU in the IP tunnel interface this way, it won't
be there after you reboot, I've found. Oh, and 1480 is the magic number.
1400 is safe, but 1480 works. Any higher than that, and it doesn't work as
desired.
So I went to investigate how to do the same thing on my Linux real
servers, only to find that the tunl0 interface, which is the connection
endpoint for Linux realservers, already has an MTU of 1480. I don't know
when that got fixed, but I guess I won't worry about it.
(later) I was wrong; here's the fix for Linux realservers:
iptables -A OUTPUT -s VIRTUAL-IP -p tcp -m tcp --tcp-flags SYN,RST,ACK
SYN,ACK -j TCPMSS --set-mss 1440
Tested, tcpdumped, works. Now I have no more 'IPVS: ip_vs_tunnel_xmit():
frag needed' messages. (At least for now. We'll see if I'm wrong
tomorrow.)
Chris Paul, 11 Mar 2005
Isn't this fixed in Kernel 2.6 anyway
Casey Zacek cz (at) neospire (dot) net
I really don't think it's possible to fix this on the director (and my
directors are running 2.6.11 anyway -- and it's not fixed there). The
closest way I could think of was to ignore the DF flag in the incoming TCP
packets and just fragment them anyway.
Casey Zacek cz (at) neospire (dot) net 2005/04/12
It's not fixed in 2.6; I still need the iptables rule to set the mss
# iptables -A OUTPUT -s VIRTUAL-IP -p tcp -m tcp --tcp-flags SYN,RST,ACK
SYN,ACK -j TCPMSS --set-mss 1440
--------------------------------------------------------------------------
Could you please get back to the list if this helps solve your
problem?
I too am using LVS Tun in a 50 node cluster --- and am interested
in hearing your experiences?
Nige
Nigel Hamilton
Turbo10 Metasearch Engine
email: nigel@xxxxxxxxxxx 4 Ivory Wharf
tel: +44 (0) 208 450 0221 4 Elephant Lane
fax: +44 (0) 207 232 4867 London SE16 4JD
________________________________________________________________________________
http://turbo10.com Search Deeper. Browse Faster.
On Tue, 2 Jan 2007, Matthew wrote:
Hey gang,
We are running a 3 machine setup using TUN. While we have thousands of
people using our CGI's on a daily basis, I have this 1 dude (there's always
frackin' 1) who is getting an internal server error when accessing this CGI.
The apache logs say this when he submits a POST in one particular section of
the CGI:
request failed: error reading the headers
If he does this same request by directly accessing the nodes, it works fine.
He says nothing has changed in his setup which is T1 -> T1 router -> Firewall
-> home network.
Is there anything anyone can think of that might be causing this header
error? Could there be something in his setup that isn't liking the TUN
effect? I stray away from this as the reason because other sections of the
CGI (as well as our whole website) work fine for him.
I can log in as this customer and make the same change and it works fine so
I'm guessing it has to be something on his side.
Any ideas? Is there some tool I can use or log to read to fix this?
Thanks,
Matthew
_______________________________________________
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
|
