From owner-freebsd-net@freebsd.org Sat Oct 21 18:30:17 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 E9E2DE36AD6 for ; Sat, 21 Oct 2017 18:30:17 +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 C9E8666261 for ; Sat, 21 Oct 2017 18:30:17 +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 v9LIUGx2035433; Sat, 21 Oct 2017 11:30:16 -0700 (PDT) (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 v9LIUG8U035432; Sat, 21 Oct 2017 11:30:16 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201710211830.v9LIUG8U035432@pdx.rh.CN85.dnsmgr.net> Subject: Re: loopback routes miss RTF_PINNED flag In-Reply-To: <59EB8D87.9080700@grosbein.net> To: Eugene Grosbein Date: Sat, 21 Oct 2017 11:30:16 -0700 (PDT) CC: "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.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:30:18 -0000 [ Charset windows-1252 unsupported, converting... ] > 22.10.2017 0:38, Rodney W. Grimes wrote: > > >> When IP address is being added to an interface, a kernel installs loopback route. > >> For P2P interfaces, we have local IP address and remote one. > >> > >> A route to remote address is added with RTF_PINNED flag, > >> so that it overrides any possibly existing route to that address added > >> by a routing daemon and that's fine. > >> > >> A route to local address created with ifa_maintain_loopback_route() function in > >> https://svnweb.freebsd.org/base/head/sys/net/if.c?annotate=323170#l1711 > >> misess RTF_PINNED flag, so that it cannot override similar possibly existing route > >> and that's not fine as rtrequest1_fib() returns EEXIST in such case. > >> This error is then propagated back to userland ioctl SIOCAIFADD breaking > >> interface configuration sequence. See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223129 > >> for real world example. > >> > >> Is there a reason for such loopback routes to not have RTF_PINNED flag? > > > > 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. # ifconfig tun0 tun0: flags=8051 metric 0 mtu 1426 options=80000 inet 192.168.128.10 --> 192.168.128.9 netmask 0xffffffff nd6 options=21 groups: tun Opened by PID 884 # route -n get 192.168.128.9 route to: 192.168.128.9 destination: 192.168.128.9 fib: 0 interface: tun0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1426 1 this is NOT a loopback route, this is a tun0 route. # ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=4219b ether 00:22:68:0b:54:01 inet 192.168.32.44 netmask 0xffffff00 broadcast 192.168.32.255 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active # route -n get 192.168.32.44 route to: 192.168.32.44 destination: 192.168.32.44 fib: 0 interface: lo0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 16384 1 0 this IS a loopback route, not created by _loopback_route, but by bird, it would be the same if I was running with the _loopback_route code and not bird. > > > My local tree removes this code. > > > > The reasons claimed to it being added was if you downed/upped an > > interface you lost these routes, which have traditionally been > > installed at boot time by /etc/netstart. > > Not only for this reason, see above. "Claimed" as in I have found the original commit and read why it was done. That it has other effects are not part of that claim. > > > 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. > > > Your propossed RTF_PINNED I think actually just aggrivates > > the problem with most routing daemons fighting the kernel > > on adding/removing these routes. > > > > bird is very noisy if you do not disable this code. > > quagga plays this just fine without noise. I believe Quagga does not attempt to install the loopback routes unless you specifically configure it to do so. > > Routing daemons should learn to respect kernel-created pinned routes, not vice-versa. Um, kernels should NOT implement routing policy, in any way. -- Rod Grimes rgrimes@freebsd.org