|
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>
|
