Date: Wed, 13 Dec 2017 02:52:42 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Jan Bramkamp <crest@rlwinm.de>, freebsd-net@freebsd.org Subject: Re: Changes to route(8) or routing between r325235 and r326782? Message-ID: <5A30338A.4060500@grosbein.net> In-Reply-To: <201712121833.vBCIXXXf087628@pdx.rh.CN85.dnsmgr.net> References: <201712121833.vBCIXXXf087628@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13.12.2017 01:33, Rodney W. Grimes wrote: >>> 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 I've tried to use routed for RIPv2, it was badly broken for very-very long time. Unusable at least since FreeBSD 4.x era. Anyway, you misunderstood my question. Again, in other words: do we have routing daemon installing prefixes of addresses assigned to system interfaces to kernel forwarding database (FIB) in the base system? > Also why does this need to ba a "in the base system"? Because Unix routing machine is supposed to perform static routing out-of-the-box. >> 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 It it pretty normal and routine for system administrator or daemon such as ppp(8) to assign new address to an interface. You cannot say "don't do that". And failure of such basic task is unacceptable. >> Pinning loopback prefixes solved this problem at last. > > No, Yes, it did :-) > 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. Please describe some practical case when pinning breaks OSPF or BGP. > 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. That setup is easily fixed with small correction of packet filtering rules and did not require loopback route removal in first place. > 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. It solves much more problems than that. > 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. Cisco and others do the same. This behaviour is "standard de-facto". Deviations should be possible, of course - as alternatives.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A30338A.4060500>