From owner-freebsd-net@freebsd.org Tue Dec 12 18:33:35 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70E00EA2357 for ; Tue, 12 Dec 2017 18:33:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40DF06A841 for ; Tue, 12 Dec 2017 18:33:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBCIXX5D087629; Tue, 12 Dec 2017 10:33:33 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBCIXXXf087628; Tue, 12 Dec 2017 10:33:33 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712121833.vBCIXXXf087628@pdx.rh.CN85.dnsmgr.net> Subject: Re: Changes to route(8) or routing between r325235 and r326782? In-Reply-To: <5A301BAA.8010509@grosbein.net> To: Eugene Grosbein Date: Tue, 12 Dec 2017 10:33:33 -0800 (PST) CC: Jan Bramkamp , freebsd-net@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:33:35 -0000 > On 13.12.2017 01:02, Rodney W. Grimes wrote: > > >>> The whole maintain_loopback_route should be KILLED from the kernel, > >>> it is simply the wrong thing to be doing. > >> > >> Only if you can supply alternative way to assign highest priority > >> (administrative distance = 0) for "directly connected" routes. > >> And ability to override dynamically received prefixes with direct > >> interface address assignment. > > > > This is all done by correctly configured routing daemon > > running in userland over the route socket. > > Do we have such daemon maintaining directly connected routed in the base system? I believe we do, though it uses a fairly rare protocol now a days, called ripv2. man routed Both bird and quagga maintain these routes as well. I believe that openospfd does too. In fact I dont know of a routing daemon that does not try to maintain these. Also why does this need to ba a "in the base system"? Certainly sticking a route decision in the kernel that defeats any attempt to change it makes that pointless anyway. > > > Only being doing that for 25+ years that way, why suddenly does the > > kernel need to over ride what has already been done and working? > > I cannot speak for 25+ years but I can for 17+ while there was NO way > in FreeBSD to assign an address like 192.168.0.1/24 to an interface > when such prefix already was installed to the kernel by routing daemon. That is a differet issue than having the kernel install such routes. And nomally you do NOT need to do that if your routing protocol is doing the right things, as it well see the net interface, recompute its rib and correct the fib > Pinning loopback prefixes solved this problem at last. No, it only breaks people that run real routing protocols like OSPF and BGP. Also fixing one problem only to create others is not the way we should be attacking things, that just leaves sizeof(bugs) at N. You can no longer deny that this creates a problem for someone, as we now have a user that had a working system get borked by these changes. I am no longer a sole, as warner well certainly put it, whiner on this issue. Again, the maintain_loopback_route stuff was added because someone couldnt deal with the fact that you loose all routes via an interface when you down it and then bring it back up. That behavior is what you WANT to happen. Having the kernel magically add routes when an interface comes back up is just bad for a real router. The kernel can not possibly know what my policy is about that route. It now does what someone thinks is the best policy, and that is in direct conflict with what most routing protocols are going to try and do. I do not know of any other system that does this, but then I dont fuss with Linux much. -- Rod Grimes rgrimes@freebsd.org