[Bug 256393] Issue with recreation of ppp/tun interfaces

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 04 Jun 2021 21:31:54 UTC

--- Comment #21 from Rodney W. Grimes <rgrimes@FreeBSD.org> ---
(In reply to Alexander V. Chernikov from comment #19
> Do I understand correctly that you're suggesting that loopback routes should be installed by the routing daemons instead of kernel?

Suggest? No, my words are stronger than that.  The KERNEL should NOT implement
ANY routing policies.  A loopback route IS a routing policy.

Further loopback routes are a micro-optimazation that was originally done to
short circuit the MTU of 1500 on ethernet, and much short in the days of IMP's
and slip lines to use the larger MTU of the loopback interfaces.  A BSD system
can run perfectly fine with NONE of these loopback routes, they are nothing
more than an optimization.

> If yes, I'm not sure how one would handle non-router cases (e.g. a server with a single interface).

Well this use to be handled by a simple static route, but someone couldnt
handle the fact that the route goes away if you down the interface and thought
that the kernel should maintain this route for them.  This is arguable a lack
of skill or understanding that if you take an interface down ALL routes are
gona go away, and you need to re install them.  

> I'm also not sure how can this work with modern routing software. IIRC frr does not care about any route which is not RTF_GATEWAY. It is certainly possible to configure such routes in bird, but it has to be done on per-prefix basis.

I'll discuss this with the FRR folks, but I do believe that software already
knows how to maintain loopback routes.  Usually on a "router" you do NOT want
these routes in place, as this hides interface errors for locally sent packets
to a local address.

> Could you share a bit more details on what is the proposed alternative?  Well I think part of why we are here right now is that routed is trying to maintain these routes and it is conflicting/having issue with what the kernel is doing.  I also know of older routing code that maintained these without issue.  And finally these routes are a micro optimazation that are simply not needed in most cases.

You are receiving this mail because:
You are on the CC list for the bug.