Received: with ECARTIS (v1.0.0; list netdev); Mon, 09 Feb 2004 15:03:28 -0800 (PST) Received: from u.domain.uli (ja.mac.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19N3FKO022502 for ; Mon, 9 Feb 2004 15:03:20 -0800 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i19N6FVw002071; Tue, 10 Feb 2004 01:06:16 +0200 Date: Tue, 10 Feb 2004 01:06:15 +0200 (EET) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: "David S. Miller" cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Restrict local IP announcements in ARP requests In-Reply-To: <20040209140853.69ab8bea.davem@redhat.com> Message-ID: References: <20040209140853.69ab8bea.davem@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3169 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Hello, On Mon, 9 Feb 2004, David S. Miller wrote: > I'm fine with this patch, although it appears incomplete because: Of course :) I'm still thinking on it, for example: - do we need to complicate the things in arp_solicit and to announce not only local IPs but also sender IPs for which we support proxy_arp. But may be it is better not to complicate the arp_solicit routine because it can detect different skbs to same target, each with different saddr, so this is only a matter of optimization. I'll send you final diff in the next days after resolving this ifdef, I'm giving myself and the other gurus some days for thinking :) > > 2 - always use the best source address for this target > > The code handling this case is "#if 0/#endif" commented out in your > patch. I just wanted to know if output route is better to use in this case? Or it is better to use inet_select_addr? > Finish this thing up, and as a birthday present to everyone I'll also > add an IN_DEV_ARP_IGNORE flag for inet devices to so people can control > complete ARP ignoring via a global/per-device sysctl. > > Hopefully, combined, this will get all the virtual server maniacs off > of my back :-) Ah, no, forget about ARP_IGNORE :) Nobody wants this :) As for IPVS like setups, the requirements need per IP tunning which is possible only with some kind of filtering, not a global flag, especially for the input device. Note that the "hidden" flag is checked for the target device, this was the only way to differentiate by device. May be this is a proof arp_announce is not for IPVS :) It is mostly to work with other stacks because I'm flooded with emails about how Linux ARP can be more friendly. Regards -- Julian Anastasov