loopback routes miss RTF_PINNED flag

[Rodney W. Grimes]

[ 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<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1426
	options=80000<LINKSTATE>
	inet 192.168.128.10 --> 192.168.128.9 netmask 0xffffffff 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	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: <UP,HOST,DONE,STATIC,FIXEDMTU,PINNED>
 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
	ether 00:22:68:0b:54:01
	inet 192.168.32.44 netmask 0xffffff00 broadcast 192.168.32.255 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	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: <UP,HOST,DONE,STATIC>
 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 at freebsd.org