Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Oct 2017 01:10:15 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: loopback routes miss RTF_PINNED flag
Message-ID:  <59EB8D87.9080700@grosbein.net>
In-Reply-To: <201710211738.v9LHcboD035221@pdx.rh.CN85.dnsmgr.net>
References:  <201710211738.v9LHcboD035221@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 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.

> 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.

> 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.

Routing daemons should learn to respect kernel-created pinned routes, not vice-versa.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?59EB8D87.9080700>