From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 13:16:55 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE70616A417 for ; Thu, 3 Jan 2008 13:16:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id B145613C467 for ; Thu, 3 Jan 2008 13:16:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 4D01182EF5; Thu, 3 Jan 2008 08:16:55 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 03 Jan 2008 08:16:55 -0500 X-Sasl-enc: DvJTRO3UTRif41w6eRi+58ZROj3vQW7V+ycCV9mI9TrJ 1199366214 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id A26F327476; Thu, 3 Jan 2008 08:16:54 -0500 (EST) Message-ID: <477CE045.7000200@FreeBSD.org> Date: Thu, 03 Jan 2008 13:16:53 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Julian Elischer References: <200712170740.lBH7eYaU068543@repoman.freebsd.org> <4766D6E5.1010503@FreeBSD.org> <4766E54C.30402@elischer.org> <477BBBC7.2020800@FreeBSD.org> <477C1156.9090106@elischer.org> <477CDECE.9010205@FreeBSD.org> In-Reply-To: <477CDECE.9010205@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, "ru@FreeBSD.org >> Ruslan Ermilov" Subject: Re: Outstanding multipath related PR; Floating statics. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2008 13:16:56 -0000 Bruce M. Simpson wrote: > > The problem which caused Thomas to raise the PR, is that of allowing > the prefix route for 192.168.1.0/24 to float over to the other > interface which *can* reach that prefix. I should also point out that the problem exists at Layer 2 and Layer 3. To be sure, if a route already exists for 192.168.1.0/24 which transits the downed interface, it will be chosen first. However if ARP entries are still in the stack, they represent the most specific match and their /32 entries will be chosen *before* any Layer 3 route, regardless of interface status. In other words, the removal of ARP entries from the routing table would solve only half of the problem that Thomas has observed. So I guess the real question is: should the lookup of the next-hop for a "connected" route, that is, the network prefix route associated with an interface, be allowed to "float" to the next interface which is UP? I think it should. Interface routes are NOT STATIC routes. I'm in favour of retaining the existing meaning of STATIC routes. But I also think we should allow the IFP resolution for STATIC routes to "float" if they are configured as FLOATING STATICs as this is what most folk really want the forwarding code to do. regards BMS