Date: Sat, 21 Oct 2017 13:16:25 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: loopback routes miss RTF_PINNED flag Message-ID: <201710212016.v9LKGPnh035752@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <59EB95E8.1040807@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I think we are talking either about 2 different issues, or we are
having a very major breakdown in communications. I am going to
try again to clarify what I have said and try to get a better
picture of what you might be experiencing.
> 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.
Ok, but your proposed patch is changing a route to pinned, this is a
local loopback route that well be via the lo0 interface. You mentioned "pinned
rolute to remote side" which lead me down that path and to the above
comment about it not beeing needed.
>
> 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.
I think I see what your getting to, your bringing up an interface that
routes into a network that we have already learned about over some
routing protocol. When the if comes up the maintain_loopback_route
clashes with that route and you get a complaint, adding RTF_PINNED
clears that issue up some how?
> And before RTF_PINNED introduction there were no solution, not to mention complex
> and not always possible dynamic route filtering.
Um, I have been and still am routing with ppp and ethernet using
the FreeBSD kernel since pre 1.0 without using RTF_PINNED, so I
do not agree here. THere are solutions, infact it just works.
>
> >>> 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?
I did not say it was not possible, I said that routing
policy does not belong in the kernel. And I actually
think part of what is causing you problems is the
fact that it does.
> 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.
Ok, so why is it that these maintain_loopback_route routes are needed,
the world works and lives fine without them, other than a minor
in effecency in traffic to the local ip address of the interface.
>
> 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.
That is a policy decision, your policy is that you want these kernel
routes to take precedence over the dynamicly created ones, I want
the ones that my bird configuration says that I want and unless I
go ripe this code out of the kernel I can not get them cause the
kernel keeps changing them back.
>
> >> 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.
maintain_loopback_route adds routes to the kernel routing table,
technically that is a routing policy.
Let me try to get my proposal into a patch form and see if
it doesnt solve your problem too.
I have no issue with you adding RTF_PINNED to the route that
is created now, as my solution just totally disables that code anyway..
that is if you want it disabled.
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201710212016.v9LKGPnh035752>