on-interface routes

[Alexander V. Chernikov]

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

>
>