From owner-freebsd-net@freebsd.org Sat Oct 21 18:46:18 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 D7FEEE36FA1 for ; Sat, 21 Oct 2017 18:46:18 +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 838E86690B for ; Sat, 21 Oct 2017 18:46:16 +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 v9LIk7nZ085173 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Oct 2017 20:46:08 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd-rwg@pdx.rh.CN85.dnsmgr.net Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id v9LIk0aH066633 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 22 Oct 2017 01:46:00 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: loopback routes miss RTF_PINNED flag To: "Rodney W. Grimes" References: <201710211830.v9LIUG8U035432@pdx.rh.CN85.dnsmgr.net> Cc: "freebsd-net@freebsd.org" From: Eugene Grosbein Message-ID: <59EB95E8.1040807@grosbein.net> Date: Sun, 22 Oct 2017 01:46:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201710211830.v9LIUG8U035432@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: Yes, score=5.5 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM,RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 3.3 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-Flag: YES X-Spam-Level: ***** X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Oct 2017 18:46:19 -0000 22.10.2017 1:30, Rodney W. Grimes wrote: >>> Is there a reason that the kernel is setting a policy at all? These >>> _loopback_route routines are of dubious value and mostly interfere >>> with anyone running a real routing protocol. >> >> In case of PPP interfaces, a pinned route to remote side of the interface >> it absolutely needed. And not only in such case. It was long period >> during which FreeBSD administrators and PPP daemons suffered from not being >> able to assign an address to an interface with ifconfig command or corresponding ioctl >> when there was conflicting dynamic route that had de-facto priority it should not have. >> With introduction of current RTF_PINNED semantics, this long-stanging problem finally gone. > > I do not believe that is correct, ppp well work just fine without a > loopback route to the remote ppp address, infact I would not want > a loopback route to the remote ppp address as that prevents me > from doing a ping test of the ppp link itself. > _loopback_route installs a route the the LOCAL ip address via > the lo0 interface and had better not be trying to do any remote > addresses at all, or that is lot a loopback route but a very > debuous short circuit route. [skip] I have not said that pinnd route to remote side of the interface is loopback one, that would be plain wrong, as you have noted. I said that in face of PPP interface kernel creates two routes, one loopback and another one to the tunnel interface itself. Both of them should be allowed to override possibly already existing dynamic routes and RTF_PINNED solves this problem. And before RTF_PINNED introduction there were no solution, not to mention complex and not always possible dynamic route filtering. >>> IMHO this should be handled by code outside the kernel. >> >> Handled by what? Administrator should be able to override dynamic routes >> with basic system facilities. > > The problem is that this _loopback_route code places routing > policy in the kernel that is not possible to override by > any administrator or daemon, that is simply and fundamentally > wrong no matter how correct the routes may be. Hmm, why do you thing this is not possible? Of course, kernel supplies API (RTF_PINNED route option flag itself) to override pinned routes. How else PPP daemon or ifconfig/route commands would be allowed to manipulate such routes as they can now? This includes route removal. But route daemon should not override pinned routes that are pinned for the reason. If pinned route is not needed, it should not have been created in first place, I agree. But if it WAS created, it should have absolute priority over dynamic routes or we get into same old trouble solved with RTF_PINNED that I described earlier. >> Routing daemons should learn to respect kernel-created pinned routes, not vice-versa. > Um, kernels should NOT implement routing policy, in any way. I'm not sure I understand what is 'routing policy implemented with kernel' you talk about.