On Mon, Sep 17, 2012 at 04:51:11PM +0400, Alexander V. Chernikov wrote:
On 17.09.2012 17:06, Ondrej Zajicek wrote:
On Mon, Sep 17, 2012 at 01:29:35PM +0600, Eugene M. Zheganin wrote:
Hi.
Why bird touches on-interface routes ? Right now I have to create import filters and prohibit importing of on-interface routes, because in case of losing a link bird thinks that this route was added by it and deletes it, making the network unuseable. Is there a way to tell it 'don't touch on-interface routes' ?
BIRD tries to not touch these routes, so it is strange that in your case these routes are removed.
First, device routes (and their removal) are not exported to kernel unless 'device routes' option is active. But this can be circumvented when protocol tries to export 'regular' route (with next-hop) for the same network (this is probably what happened if you have OSPF and two routers connected to a network, one loses a link and tries to route to that network through the other router). Workaround for this is to have active 'direct' protocol, which generates local routes with higher priority, so any OSPF route for that prefix is not propagated to the kernel.
This workaround still has problems in case of direct* patterns reconfiguration.
What exact problem is in direct* pattern reconfiguration? I guess there is a problem if there is some lower priority route with next hop, which is blocked by higher priority device route from direct protocol, which disappears for a while during reconfiguration. Is this what you mean? But just standalone direct protocol reconfiguration shouldn't cause problems (device route removal is blocked by kernel protocol).
Unfortunately, I can't think of any good bird-side patch to fix this in better way.
I have some plans for changes in kernel protocol that might fix this, basically if BIRD finds kernel (device) route during kernel table scan, then it marks the net in kern.proto. internal table as 'protected' and do not accepts route changes for that net (unless allowed by an option). This would replace current 'device routes' option, which is just an unreliable hack.
I'm planning to fix this in FreeBSD kernel, but it is a long story..
I guess a good way to fix this is to do it in a similar way like in Linux - have some exclusive flag for RTM_ADD that do not allow to replace a route, just add a new, and also some 'strict' flag for RTM_DELETE, which removes the route only if 'source' flags (like RTF_STATIC or RTF_PROTO1) are the same in the kernel route and in the request.
Can we update Direct protocol documentation to reflect this problem?
You mean that routes disappear for a moment during reconfiguration, so if they are used to protect kernel routes they should not be changed? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."