|
On Wed, 14 Jun 2000, Julian Anastasov wrote:
>
> Hello,
>
> On Wed, 14 Jun 2000, Kyle Sparger wrote:
>
> > I figured this might be on-topic. I don't think that LVS handles this
> > correctly, but I could be wrong. Anybody know? :) Is is it not even a
> > concern? It seems like it would be to me...
>
> Yes, it is not handled. ip_fw_unmasq_icmp is not changed
> from LVS. But the problem occurs when external_MTU > internal_MTU
> in the Director which is not an usual case for LVS. The other case
> when the client has little MTU is handled. The result is:
>
> - no problems for clients
> - the server works or don't works entirely. I think this
> could be visible. So, the problem is that the Director doesn't
> generate ICMP to the real servers. But the ICMP messages from
> clients are propagated to the real servers.
>
For external_MTU < internal_MTU, LVS can handle this, because the
ICMP_FRAG_NEEDED message from clients or intermediate routers can be
forwarded to the right real server.
For external_MTU > internal_MTU, VS/DR cannot handle it, because we don't
do MTU checking before calling ip_send(); VS/NAT and VS/TUN currently can
handle it. In VS/NAT, the mangled packet will go through ip_forward, which
has MTU checking. In VS/TUN, ip_vs_tunnel_xmit has MTU checking. Right?
BTW, I think it rarely happens. In VS/DR, the load balancer and real
servers are connected by an uninterrrupted physical network, such as
ethernet. The default MTU is 1500, which usually large than client MTU.
> Of course, this must be corrected in next versions.
>
Sure!
Thanks,
Wensong
> The only PMTUdisc problem in 2.2 in the server side
> is for the clients accessing 2.2 MASQ server which uses
> ports not in the reserved range (portfw, mfw, autofw). This
> is a known bug from long time ago which is not fixed yet.
>
> LVS at least don't hurts its clients, only the
> real servers in VS/NAT.
>
> Regards
>
> --
> Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
>
>
>
|
