|
Hello,
On Thu, 15 Jun 2000, Wensong Zhang wrote:
>
>
> On Wed, 14 Jun 2000, Julian Anastasov wrote:
>
> > 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.
Yes, we correctly forward these ICMP messages in
both directions.
ext_MTU < int_MTU is detected only when we forward packet
from NAT-ed real server to the client. It is handled from
ip_forward. We use ip_forward only in VS/NAT. I agree, no
problem here. No packet mangling before icmp_send, no need
to restore packet.
>
> 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
Yes, in ip_vs_dr_xmit() we need just to add a mtu
check and to reply with icmp_send(). The current status
is: we don't generate ICMP messages.
> 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?
Right, VS/TUN is perfect.
For VS/NAT demasq is broken. We must restore the
original packet in ip_fw_unmasq_icmp when called from
icmp_send (called from ip_forward after the packet mangling
and after 2nd ip_route_input). (I hope nobody complains the
576 data bytes are not restored). There is no such thing in
2.3, the packet restoring is a big pain and it was removed
but that doesn't means 2.3 looks correct when sending
ICMP_FRAG_NEEDED from ip_forward(). We are not sure if the
packet is not already changed from the PRE_ROUTING? The
result: rewritten iph->daddr (internal address) is returned
in the ICMP reply. Is my interpretation correct? I didn't
tested it yet.
For the masq direction it is handled from ip_forward
before packet mangling. No problem here.
>
> 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.
Yes, strange setup for director :) The external
link with greater mtu than the internal :)
>
> > Of course, this must be corrected in next versions.
> >
>
> Sure!
I think we have to make two changes:
- ip_vs_dr_xmit(): check mtu and reply
- ip_fw_unmasq_icmp(): we must put only our out_get() check,
there is no reason for the in_get() check (nothing is
changed before ip_forward in the masq direction).
>
> Thanks,
>
> Wensong
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
