From owner-freebsd-net@freebsd.org Tue Dec 12 19:52:56 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 4DCC8E82174 for ; Tue, 12 Dec 2017 19:52:56 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F07B66F69D for ; Tue, 12 Dec 2017 19:52:55 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBCJqktC018814 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Dec 2017 20:52:46 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBCJqgVh004566; Wed, 13 Dec 2017 02:52:42 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Changes to route(8) or routing between r325235 and r326782? To: "Rodney W. Grimes" References: <201712121833.vBCIXXXf087628@pdx.rh.CN85.dnsmgr.net> Cc: Jan Bramkamp , freebsd-net@freebsd.org From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <5A30338A.4060500@grosbein.net> Date: Wed, 13 Dec 2017 02:52:42 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <201712121833.vBCIXXXf087628@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_96_Q autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: * date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** 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 19:52:56 -0000 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.