LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: Large HTTP GET/POST timeout

To: Joseph Mack <mack.joseph@xxxxxxx>
Subject: Re: Large HTTP GET/POST timeout
Cc: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 28 May 2004 01:01:52 +0300 (EEST)
        Hello,

On Thu, 27 May 2004, Joseph Mack wrote:

> Presumably you can set the MTU at either end and both ends should figure it 
> out.
>
> Julian,
>
>       Is the kernel on the director still responsible for this problem? Is it 
> supposed
> to be fixed?

        First, one have to identify the problem, I have a step-by-step
howto for TUN setups:

http://www.ssi.bg/~ja/TUN-HOWTO.txt

>       Why is the default MTU for ipip packets 1480, rather than 
> 1500+overhead_for_ipip=1520?
> Is 1500 a hardware buffer size limit in the NICs? (ie hardware buffer=1500?)

        There is no such thing as MTU for ipip. IPVS simply
extends the packet with 20 bytes by prepending IPIP header.
There is a convention in IPv4 to reply with ICMP error if a
packet with DF flag set reaches smaller pipe (packet length > PMTU).
If DF is not set the packet is fragmented in MTU-sized fragments.

        There can be dozen problems related to MTU:

- no ICMP errors generated (from director, from other hosts
between director and real servers)

- ICMP errors do not reach their destination (the client), eg.
filters dropping blindly any ICMP traffic

- ICMP errors generated from real servers (or from hosts before
real lservers) not forwarded from director to client

- PMTU not updated in routing cache due to IP TOS changes after routing

        As for MTU 1500, I do not know which is the origin of this
limit. May be it is a balance between link sharing and protocol
header overhead.

Regards

--
Julian Anastasov <ja@xxxxxx>
<Prev in Thread] Current Thread [Next in Thread>