[Olsr-users] Problems with the quagga plugin

[Damien Miliche]

Hi Vasilis,

Thanks for your answer. Anyway, I am not sure to understand the "recursive
routes" problem :s

> This happens because Quagga considers nexthops which are recursively
> reachable 
> as inactive. I beleive this assumption is correct with classic subneted 
> routing but fails in MANETs. Since olsrd-quagga plugin is attempting to
> bring 
> these two "worlds" in contact, we have to find a solution which breaks
none
> of 
> them.
> 
> One solution is to treat host routes the same way as directly connected
> routes 
> which are always considered valid nexthops. But this would mean more
Quagga
> 
> modifications which I'd prefer to avoid. AFAIK, Quagga makes an exception
> on 
> the de-activation of recursive routes in iBGP networks. Maybe we could
use
> the 
> same mechanism to "activate" OLSR routes.


To give a better view of my problem, here is what I get on a gateway node
(192.168.10.1/32 on wlan0, 192.168.20.1/24 on eth0) that sees (at least
suppose to see) two direct olsr/MANET neighbours (192.168.10.49/32 and
192.168.10.59/32), and an indirect one (192.168.10.219/32 via
192.168.10.59), and is connected through Ethernet to an OSPF-enabled host
(192.168.20.9/24):

from the httpinfo olsrd plugin:
    OLSR Routes in Kernel
    Destination		Gateway		Metric	Cost (ETT)	Interface
    192.168.10.49	192.168.10.49	1	4392.000	wlan0
    192.168.10.59	192.168.10.59	1	4427.000	wlan0
    192.168.10.219	192.168.10.59	2	18341.000	wlan0
what is OK according to my topology, and what I would like to redistribute
to the OSPF node.


from zebra:
    Router> sho ip route
    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
           I - ISIS, B - BGP, H - HSLS, o - OLSR, b - BATMAN,
           > - selected route, * - FIB route

    C>* 127.0.0.0/8 is directly connected, lo
    K>* 169.254.0.0/16 is directly connected, eth0
    C>* 192.168.10.1/32 is directly connected, wlan0
    o>* 192.168.10.49/32 [125/1] is directly connected, wlan0, 00:01:06
    o>* 192.168.10.59/32 [125/1] is directly connected, wlan0, 00:18:23
    o   192.168.10.219/32 [125/2] via 192.168.10.59 inactive, 00:00:24
    O   192.168.20.0/24 [110/10] is directly connected, eth0, 00:27:36
    C>* 192.168.20.0/24 is directly connected, eth0

the resulting Kernel routing table:
    # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
    192.168.10.59   0.0.0.0         255.255.255.255 UH    1      0        0
wlan0
    192.168.10.49   0.0.0.0         255.255.255.255 UH    1      0        0
wlan0
    192.168.20.0    0.0.0.0         255.255.255.0   U     1      0        0
eth0
    169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0
eth0

To get that, I deactivated the "quagga bug workaround" for entries where
destination = gateway in the quagga plugin for olsrd.
The difference with when this workaround is activated, is that the first
two entries are then not added to the kernel routing table because marked
as inactive in zebra.

As, without the workaround, the gateway node (192.168.10.59) is not
inactive, I don't understand why the route towards 192.168.10.219 is still
marked as inactive.
Moreover, as you can see, the valid/active host routes are already marked
as "directly connected", then should also be considered as valid nexthops.


Best regards,

-- 
Damien Miliche