|
Hello,
On Wed, 2 Jun 2004, Chris Paul wrote:
> This is all getting a bit heavy for my liking, but can someone please confirm
> the state of play for me.
There was problem before 2.4.23 as already explained in
the HOWTO:
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.LVS-Tun.html
> I was under the impression that this problem is because of a bug in older
> versions of the Linux Kernel. From the amount of discussion about attempted
> workarounds, I get the impression the problem still exists and can be
> reproduced with even the latest kernels.
Ah, which problem? There can be so many problems. The things
you can do in director when using LVS-TUN:
- if PMTU to RIP is lower then outdev's MTU then you have to specify it
in special route to RIP. If the PMTU is 1500 you do not need such
route, IPVS automatically reports MTU 1480 to all clients that
send packets > 1480. There is no chance for PMTUD to work when
the ICMP errors are dropped between director and client. It will
happen for any used PMTU to RIP.
- run tcpdump and check for any received or generated ICMP errors
As for the existing problems, they are explained in the
above page. In short, the PMTU is not updated in routing cache
if director receives ICMP_FRAG_NEEDED. But this is easy to detect
and to solve. The good news is that you can detect it from any client,
send large file, tcpdump for ICMP errors coming from real servers to
director. If this is the case (PMTU to RIP is lower than outdev's MTU)
than you can try to specify pmtu in special route to RIP. Once the
director knows the right PMTU to RIP then it will report it to every
client that violates it. There is no need IPVS to relay the ICMP error
coming from RIP to the client, we just know how to generate
it on each request from client. The only benefit can be if
ipip.c is patched to update the PMTU in the routing cache and
to avoid creating special route to RIP.
All other problems can be related to filtering of the
ICMP errors generated from director and sent to client. Such
places for filtering can be the netfilter in director or any
router used to reach the client. It is enough to check that
the ICMP errors generated in director reach the director's uplink
GW. Then you hope that the client does not filter ICMP.
I do not remember for other problems related to TUN
and PMTUs. Any other issues?
> Is this the case?
>
> TIA
>
> Chris
Regards
--
Julian Anastasov <ja@xxxxxx>
|
