On 07.03.2013 14:38, Ermal Luçi wrote:
On Thu, Mar 7, 2013 at 12:55 PM, Andre Oppermann <an...@freebsd.org 
<mailto:an...@freebsd.org>> wrote:

    On 07.03.2013 12:43, Alexander V. Chernikov wrote:

        On 07.03.2013 11:39, Andre Oppermann wrote:

            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 <http://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?

        routing daemons live long with the fact that there route socket cmds can
        fail (and the is route(8) utility which can do anything), so typically
        bird/quagga yells like
        'bird: KRT: Error sending route 11.0.0.0/24 <http://11.0.0.0/24> to 
kernel: File exists'
        and marks given route as not installed in internal RIB. Additionally,
        daemon will probably re-try to insert such routes on every periodic KRT
        rescan (tens of minutes).



Isn't it better to teach the routing code about metrics.
Routing daemons cope better this way and they can handle this.
So the policy of this behaviour can be controled by administrator rather than 
by code!
With metrics you can add routes with bigger metric for interfaces and lower 
from routing daemons.
This also can mitigate somehow on interfaces with the same subnet configured 
possibly.

Generally I agree with you that this would be the ideal outcome.
However we're still quite a bit away from reaching that goal.
To make this really work we have make mpath plus metrics a first
class citizen in the routing code and also the update the routing
daemons kernel interfaces to know about this.  I hope we get there
in the not too distant future.

As a first step I think it is important that Alexanders patch goes
in to fix a long standing and very annoying problem with the code
we have.  Also the link down route withdraw should be added asap.
Then we can take the next steps towards the ultimate goal you describe.

I hope you do not object to Alexanders patch?

--
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"

Reply via email to