On 17.09.2012 19:56, Ondrej Zajicek wrote:
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? Yes. Typically all interfaces running OSPF suffers from this problem.
But just standalone direct protocol reconfiguration shouldn't cause problems (device route removal is blocked by kernel protocol). I haven't investigated this in details (despite I have several different configurations where this problem appears from time to time). I'll try to do this.
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. This is a better way, if this does not make kernel protocol much more complicated.
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?
Not exactly. Currently doc states ", in most cases it is not needed to have these device routes in BIRD routing table and to use the direct protocol.". I'm talking about adding something like The question is whether it is a good idea to have such device routes in BIRD routing table. "You definitely want to add device routes if you're running *BSD. This is workaround for interface routes being removed when IGP route for the same network flaps." s/OS/Linux/ kernel usually handles device routes for directly connected networks by itself so we don't need