bird patches review

[Alexander V. Chernikov]

On 06.10.2011 14:43, Ondrej Zajicek wrote:
> On Mon, Oct 03, 2011 at 10:03:30PM +0400, Alexander V. Chernikov wrote:
>>>> In most hardware routers (and even in Quagga) it is possibly to see if
>>>> RIB entry is installed to FIB
>>>> (e.g. * ). Maybe kernel can set some flag at least when it sees
>>>> installed prefix gets removed from kernel table?
>>>> (or adds some flags on route installation and remove it on route removal)
>>>>      
>>> There is already such flag (because kernel sync is a bit tricky and abuses
>>> routing table to rememer its state), perhaps we could show that flag in
>>> some way.
>>>
>>>    
>> Should I [as usual] submit patch for that? :)
Sorry, got -ETIME error :(
> I found that the flag signalizes whether route is expected to be
> installed (but the installation might failed). I added the flag
> signalizing that the last attempt to install the route to the kernel
> table failed, and showed that flag in 'show route':
>
> bird> show route 
> 10.200.0.0/16      via xx.xx.xx.xx on eth0 [static1 16:13] ! (200)
> 192.168.0.0/16     via xx.xx.xx.xx on eth0 [static1 16:13] * (200)
> 10.220.0.0/16      via xx.xx.xx.xx on eth0 [static1 16:13] * (200)
>
> Showing just whether the route is (supposed to be) installed seems
> a bit pointless - it is usually 'export all' or 'export none' for
> kernel protocol. If someone removes the route from FIB (kernel)
> and BIRD notices that, it reinstalls the route, so unless there
> is a problem in route installation, it remains synced.
We're talking about immediate or delayed reinstallaion ?
If route gets removed accidentally, immediate reinstallation is great.
If, for some reasons, we have to remove route manually
(for example if we're trying to do ifconfig some_iface a.b.c.d/z where
a.b.c.0/z already exists from IGP), it is much better not to restore
route immediately
giving user chance to do what needs to be done.

Quagga (I can be wrong here) marks route inactive on route removal event and
tries to restore it on next table scan.

--
Alexander V. Chernikov
Yandex NOC