Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 9 Dec 2002 20:16:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 9 Dec 2002 20:16:20 -0500 Received: from tmr-02.dsl.thebiz.net ([216.238.38.204]:54799 "EHLO gatekeeper.tmr.com") by vger.kernel.org with ESMTP id ; Mon, 9 Dec 2002 20:16:19 -0500 Date: Mon, 9 Dec 2002 20:22:30 -0500 (EST) From: Bill Davidsen To: Roberto Nibali cc: "'linux-kernel@vger.kernel.org'" Subject: Re: hidden interface (ARP) 2.4.20 In-Reply-To: <3DEFE86A.8060906@drugphish.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1937 Lines: 40 On Fri, 6 Dec 2002, Roberto Nibali wrote: > As mentioned before, you don't necessarily need to patch your kernels, > there are other possibilities to overcome the arp problem. You could (if > not already done so) consult the LVS howto where solutions are certainly > applicable also to non-LVS LBs. In spite of vast resistance from some developers, it is highly desirable on some systems to force a packet with a given source IP out an interface which has that IP assigned. With this capability it is possible to make a single machine with multiple NICs behave like two machines with individual NICs. This also solves ARP issues, although it's a much more general thing. Think development, think debug, think UML virtual machines, or a machine with multiple boundary routers which are addressed to separate NICs. The usual proxy_arp fix doesn't really address these cases. If I have multiple default routes, the router on which the packet arrived is likely to be on the route with the fewest hops, randomly using another route doesn't help. Source routing takes too much overhead for lots of connections, and as I recall is limited to 256 rules. I'm not sure the hidden interface patch really does this, although I just looked quickly. Patches like the hidden interface will continue as long as there are useful things people want to do with Linux and can't. It's one of many in the networking area. I don't expect them to be adopted in the main kernel, but as long as they're easier than making multiple configs, particularly at runtime, they will be around. -- bill davidsen CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/