[Olsr-users] Problems with the quagga plugin
Mon May 16 10:07:40 CEST 2011
On Sun, 15 May 2011 16:31:00 +0300, Vasilis Tsiligiannis
> Στις Τετ 11 Μαΐ 2011 14:43:59 Damien Miliche γράψατε:
>> It seems that these problems are linked and have a common cause.
>> As I realized, while reading the post on
>> http://www.gossamer-threads.com/lists/quagga/dev/17522, the olsr routes
>> that are marked as inactive actually miss a valid route for the "via
>> field" (gateway/nexthop): "When the nexthop is not reachable (from zebra
>> point of view), the route stays inactive".
> You need to figure out why the gateway is not reachable.
The gateway is well in the radio range, and if I run OLSRd without quagga,
the (gateway) routes do properly appear in the routing table.
As I said in my previous post, I think the problem comes from the "Quagga
BUG Workaround" in the quagga plugin, that does not distribute routes where
destination = gateway to quagga. And indeed, when I comment the "return
0"-workaround, the routes for the directly reachable nodes do appear in the
routing table. However, still the other routes are marqued as inactive,
even if now proper routes for the gateways exist.
> Neighbor nodes should
> be directly reachable even without a host route for them since they lye
> on the same broadcast subnet. Are you using OLSR on multiple interfaces?
Actually, the neighbor nodes are not on the same broadcast subnet. I am
actually following the addressing model of INRIA
suggesting to configure the MANET interfaces with a /32 mask in order to
prevent multi-hops subnet problems. For OLSRd, it should not be a problem
(providing that the OLSRd broadcast address is well configured), as it
already creates host routes; only that does not add a subnet route, which
could bring some conceptual IP problems for multi-hops routes.
And no, I am using OLSR only on one MANET interface per node.
Thanks in advance for your help.
More information about the Olsr-users