loopback routes miss RTF_PINNED flag

[Eugene Grosbein]

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.