From nobody Fri Jun 04 21:31:54 2021 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1C0F57EC611 for ; Fri, 4 Jun 2021 21:31:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FxbZ272xhz4tM3 for ; Fri, 4 Jun 2021 21:31:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D6B4524578 for ; Fri, 4 Jun 2021 21:31:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 154LVsUi058616 for ; Fri, 4 Jun 2021 21:31:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 154LVsLY058615 for net@FreeBSD.org; Fri, 4 Jun 2021 21:31:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256393] Issue with recreation of ppp/tun interfaces Date: Fri, 04 Jun 2021 21:31:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-STABLE X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rgrimes@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: melifaro@FreeBSD.org X-Bugzilla-Flags: mfc-stable13? mfc-stable12- mfc-stable11- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256393 --- Comment #21 from Rodney W. Grimes --- (In reply to Alexander V. Chernikov from comment #19 > Do I understand correctly that you're suggesting that loopback routes sho= uld be installed by the routing daemons instead of kernel? Suggest? No, my words are stronger than that. The KERNEL should NOT implem= ent 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 IM= P's and slip lines to use the larger MTU of the loopback interfaces. A BSD sys= tem 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 thou= ght that the kernel should maintain this route for them. This is arguable a la= ck of skill or understanding that if you take an interface down ALL routes are gona go away, and you need to re install them.=20=20 > I'm also not sure how can this work with modern routing software. IIRC fr= r does not care about any route which is not RTF_GATEWAY. It is certainly p= ossible to configure such routes in bird, but it has to be done on per-pref= ix 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 wa= nt these routes in place, as this hides interface errors for locally sent pack= ets 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 kern= el is doing. I also know of older routing code that maintained these witho= ut issue. And finally these routes are a micro optimazation that are simpl= y not needed in most cases. --=20 You are receiving this mail because: You are on the CC list for the bug.=