Re: Bug in ip_vs_out?

To: Rodger Erickson <rerickson@xxxxxxxxxxxx>
Subject: Re: Bug in ip_vs_out?
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Tue, 26 Feb 2002 18:21:58 +0200 (EET)

On Tue, 26 Feb 2002, Rodger Erickson wrote:

>       Greetings,
>       The following fragment is from the ip_vs_out() routine in
> ip_vs_core.c.  It seems to me that packets for which there is no cp but
> where ip_vs_lookup_real_service succeeds should also be dropped.  In other
> words, the decision to "eat" the packet should be independent of the
> decision to send the ICMP DEST_UNREACH.

        Your way hurts some 2.4 users. In the old LVS versions
we always assumed LVS is the only one who deals with the packets
sent to the real service. There are cases where we need only to
forward (without LVS-DNAT) the packets to the real service (they are
not destined to VIP:VPORT). In this case LVS should not reply with ICMP
error to the RS's replies which are not part from LVS connection.
The simplest example for this is when the director is a router between
a directly attached network and the real server's net and where NAT
does not occur. NAT occurs between the RSs and the universe.

                LVS ----------- Clients without NAT
                RS net

>       Thus, I think it should look something like:
> if (!cp) {
>       if (ip_vs_lookup_real_service(iph->protocol,
>                                     iph->saddr, h.portp[0])) {
>               if (sysctl_ip_vs_nat_icmp_send) {
>                       /*
>                        * Notify the real server: there is no existing
>                        * entry if it is not RST packet or not TCP packet.
>                        */
>                       if (!>rst || iph->protocol != IPPROTO_TCP) {
>                               icmp_send(skb, ICMP_DEST_UNREACH,
>                                       ICMP_PORT_UNREACH, 0);
>                       }
>               }
>               kfree_skb(skb);
>               return NF_STOLEN;
>       }

>       If there is some flaw in my thinking I would appreciate it if
> someone could explain this to me so I can understand :-)

        May be the sysctl name is not correct but anyways.

>       Thanks,
>       Rodger Erickson


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>