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

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256393

--- 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 such PINNED route in the FIB. Later some PPP daemon tries to assign that address to its interface as address of local or remote side and it should not fail with EEXIST but override non-PINNED route. It should fail with EEXIST if PINNED route exists already.

"and it should not fail unless there is already such PINNED route in the FIB" -
currently we have 2-level priority system (PINNED and non-PINNED,
https://cgit.freebsd.org/src/tree/sys/net/route/route_ctl.c?h=stable/13&id=ae23d302479#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) instead of another daemon trying to create a route or ifconfig(8) trying to assign same address, they both should fail only due to existing PINNED route. They should not fail otherwise and silently override possibly pre-existing non-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 should
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.

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