on-interface routes

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120917/f8cd02f2/attachment-0001.asc>