Date: Fri, 04 Jun 2021 21:08:55 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 256393] Issue with recreation of ppp/tun interfaces Message-ID: <bug-256393-7501-Dc52lww8OR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-256393-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-256393-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D256393 --- Comment #20 from Alexander V. Chernikov <melifaro@FreeBSD.org> --- (In reply to Eugene Grosbein from comment #17) > 1) Some routing daemon installs to FIB some /32 route learned dynamically= . It may have its reasons and it should not fail unless there is already su= ch PINNED route in the FIB. Later some PPP daemon tries to assign that addr= ess to its interface as address of local or remote side and it should not f= ail with EEXIST but override non-PINNED route. It should fail with EEXIST i= f PINNED route exists already. "and it should not fail unless there is already such PINNED route in the FI= B" - currently we have 2-level priority system (PINNED and non-PINNED, https://cgit.freebsd.org/src/tree/sys/net/route/route_ctl.c?h=3Dstable/13&i= d=3Dae23d302479#n467 ). Routes within a single priority are treated equally. If something tries = to insert a route, which already exists, the following options are possible: 1) different priorities for the current/inserted route -> fail if lower, replace if higher 2) same priorities, one of nexthop is not multipath-capable (interface or temporary route) -> EEXIST 3) same priorities, both nexthops are multipath-capable -> extend/form multipath group Other than the clarification above, the described behaviour is the current behavior. > 2) Same in case of a routing daemon doing same things but route(8) instea= d of another daemon trying to create a route or ifconfig(8) trying to assig= n same address, they both should fail only due to existing PINNED route. Th= ey should not fail otherwise and silently override possibly pre-existing no= n-PINNED route including one installed by still running routing daemon. IIRC route(8) does not use RTF_PINNED during addition, so route installation may fail even w/o PINNED route. I'm not sure if that's something that we sh= ould change. Also, currently, override triggers a couple of rtsock notifications to allow routing daemons to track the changes, so it's not exactly "silent". The rest describes the current system behaviour. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-256393-7501-Dc52lww8OR>