Date: Thu, 03 Jan 2008 13:16:53 +0000 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@FreeBSD.org, "ru@FreeBSD.org >> Ruslan Ermilov" <ru@FreeBSD.org> Subject: Re: Outstanding multipath related PR; Floating statics. Message-ID: <477CE045.7000200@FreeBSD.org> In-Reply-To: <477CDECE.9010205@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?477CE045.7000200>