[quagga-users 7413] Re: Inactive Kernel routes

Paul Jakma paul at clubi.ie
Wed Aug 16 14:08:54 IST 2006


Hi Frank,

On Mon, 14 Aug 2006, Frank E. Renwick wrote:

> Paul,
>
> Thanks very much for the information.  This is a much better 
> solution than the workaround I implemented, which was to always set 
> the NEXTHOP_FLAG_ACTIVE flag for IPV4_IFINDEX routes in 
> zebra_rib.c.

Welcome. I'd love to get operational feedback on that patch, as I 
don't see reason not to include it (I'm just wary without some kind 
of "been using it for $SIGNIFICANT_PERIOD now and it works" 
feedback).

> I do want to briefly address your comment about the "silliness" of 
> host routes in olsr.  MANET networks are forced to use host routes 
> for the network nodes.  Consider the following topology, with the 
> dashed lines indicating network connectivity over a wireless (say 
> 802.11b) medium:
>
>                                  Node1
>                                 /     \
>                                /       \
>                               /         \
>                           Node2        Node3
>                             |            |
> 	                       |            |
>                           Node4        Node5
>
> Now in an ad-hoc MANET network using the olsr routing protocol, all wireless
> interfaces reside on a common IP subnet:
>
> Node1: 172.16.1.1/24
> Node2: 172.16.1.2/24
> Node3: 172.16.1.3/24
> Node4: 172.16.1.4/24
> Node5: 172.16.1.5/24
>
> If olsr were to only use subnet routes matching the mask of the 
> interface, Node1 would not be able distinguish whether it should 
> use Node2 or Node3 as a next hop to reach Node4.  This is just one 
> example of course.  With the use of /32 routes, Node1 can clearly 
> establish that Node2 should be used as the next hop when sending 
> data to Node4.

Right, I understand why OLSR uses /32 routes, and that's perfectly 
fine.

It's just that OLSR only /needs/ to install those /32s when the 
destination has moved away from its "subnet" interface. I.e if you 
have subnet A and B, a host on subnet A called A.x, then:

 	Node1
       eth1  eth0
        /     \
       /       \
    ------A   -----B
      |
      A.x

Installing a /32 route of:

 	A.x/32 via A.x, eth1

is non-sensical, however you look at it. Even without the weird 
gateway, so the route is:

 	A.x/32, eth1

the route then is still redundant, given that 'eth1' has a 
"connected" route for the A subnet, ie the following route exists:

 	subnet A, eth1

Such a route, the second /32, wouldn't need any zebra patches though 
(shouldn't anyway).

What /would/ make sense, is where a node moves, so that A.x becomes 
reachable via eth1 instead. Then:

 	A.x/32, eth0

would make sense and not be redundant.

Routes such as:

 	Y via A.x, eth1

then run into problems (IIRC, such routes remaining inactive was the 
problem reported in May which the patch attempts to solve) as when 
zebra tries to figure out the correct connected route for the A.x 
nexthop, it ran into things it wasn't expecting.

> I hope this helps clarify why olsr uses /32 routes to communicate 
> the layer 3 topology of the shared access medium.  If you have 
> additional questions, or feel that I missed something, don't 
> hesitate to let me know.

I still think olsrd is being slightly silly in the routes it 
installs, as explained above installing both:

- non-sensical routes, which are fundamentally incomprehensible to
   other routing daemons, though which we can try work-around. (be
   nice not to have to though).

- redundant routes, which just clutter up the routing table for no
   good purpose. (though, zebra isn't particularly clever either with
   respect to installing mildly redundant routes into the kernel
   either, so..).

Another solution is to have olsrd maintain its best-routes through 
zebra. Wasn't there some work done on a "zserv-client-ified" olsrd?

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
philosophy:
 	The ability to bear with calmness the misfortunes of our friends.


More information about the Quagga-users mailing list