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
