Reports of bad headers using TUN?

[Nigel Hamilton]

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 at turbo10.com					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 at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>