On 07.03.2013 07:34, Alexander V. Chernikov wrote:
Hello list!
There is a known long-lived issue with interface routes addition/deletion:
ifconfig iface inet 1.2.3.4/24 can fail if given prefix is already in kernel
route table (for
example, advertised by IGP like OSPF).
Interface route can be deleted via route(8) or any route socket user (sometimes
this happens with
popular opensource daemons like bird/quagga).
Problem is reported at least in kern/106722 and kern/155772.
You patch is a welcome addition.
This can be fixed the following way:
Immutable route flag (RTM_PINNED, added in 19995 with 'for future use' comment)
is utilised to mark
route 'immutable'.
rtrequest1_fib refuses to delete routes with given flag unless RTM_PINNED is
set in rti_flags.
How do the routing daemons react to being unable to change/delete
such a route?
EADDRINUSE would likely be a more descriptive error instead of EPERM?
Every interface address manupulation is done via rtinit[1], so
rtinit1() sets this flag (and behavior does not change here).
>
Adding interface address is handled via atomically deleting old prefix and
adding interface one.
This brings up a long standing sore point of our routing code
which this patch makes more pronounced. When an interface link
state is down I don't want the route to it to persist but to
become inactive so another path can be chosen. This the very
point of running a routing daemon. So on the link-down event
the installed interface routes should be removed from the routing
table. The configured addresses though should persist and the
interface routes re-installed on a link-up event. What's your
opinion on it?
Other than these points I think your code is fine and can go
into the tree.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
