[Bug 256393] Issue with recreation of ppp/tun interfaces
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 04 Jun 2021 21:31:54 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256393 --- 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.