[OLSR-users] Strange routing depending on netmask

[Andreas Tønnesen]

Hi Ignacio,

This is probably caused by a bug recently discovered and fixed(and
refixed ;-) ) in CVS. the problem is that when adding routes going
via routers(destination not reachable on the link) the kernel will
not accept the route unless there already exists a route to the
gateway/router. The logic for ensuring this in 0.4.8 is not 100%
reliable so that it might happen that routes with routers/gateways
are added before the direct route to the gateway. This is only a problem
when adding routes to 1 hop neighbors that uses multiple interfaces,
other than that, routes are added based on hopcount, ensuring that 1-hop
neighbors are added first.
What would happen in your case is that node 15 in the first case would add:
first 10.1.13.23	10.1.13.21	sl2
which would be ok since we have a route to  10.1.13.21/8(10.0.0.0)
then  10.1.13.22	10.1.13.21	sl2
which is also ok. and so on...

But as soon as you start using a prefix length of 24 the kernel no
longer has a route to 10.1.13.21 via sl2 since sl2 is on the
10.1.15.0/24(10.1.15.0) subnet. So when olsrd tries to add:
10.1.13.23	10.1.13.21	sl2
it fails!
same with 10.1.13.22	10.1.13.21	sl2
but then it adds the direct route to the gw:
10.1.13.21	*		sl2
which is ok. and the rest of the routes are ok since we now have
a route to the gw.

The bugfix fixes the logic that was implemented to ensure that direct 
routes were _always_ added first.

Hope this made any sense :-)
Bottom line is that it should work in CVS (which will hopefully soon be
0.4.9). It would be great if you could verify this!!

- Andreas

Ignacio García Pérez wrote:
> Hi,
> 
> I have found a strange behaviour of olsrd. I'm using version 0.4.8. My setup
> is a little unusual:
> 
> Each node has four serial SLIP interfaces an a dummy interface. The dummy
> interface is there and participates in the OLSR protocolo solely to provide
> the main address This is the setup for, say, node 13:
> 
> dummy0	10.1.13.1
> sl0		10.1.13.20
> sl1		10.1.13.21
> sl2		10.1.13.22
> sl3		10.1.13.23
> 
> As you see, there are 256 addresses reserved for each node, and they are
> assigned to different interfaces. The ".1" address is always assigned to the
> dummy0 interface, so other nodes wanting to communicate with node 13 will
> just connect to address 10.1.13.1.
> 
> For this example, the setup for node 15 is obviously:
> 
> dummy0	10.1.15.1
> sl0		10.1.15.20
> sl1		10.1.15.21
> sl2		10.1.15.22
> sl3		10.1.15.23
> 
> Let us assume that interface sl1 in node 13 is connected to interface sl2 in
> node 15.
> 
> 10.1.13.21 <-----> 10.1.15.22
> 
> IMPORTANT: In the olsrd.conf file I set the broadcast address for all
> participating interfaces to 255.255.255.255.
> 
> Now, if I configure all interfaces with network mask 255.0.0.0, the routes
> look, AS EXPECTED, like this:
> 
> In node 13:
> 
> Destination	Gateway	Intefrace
> 10.1.15.1	10.1.15.22	sl1
> 10.1.15.20	10.1.15.22	sl1
> 10.1.15.21	10.1.15.22	sl1
> 10.1.15.22	*		sl1
> 10.1.15.23	10.1.15.22	sl1
> 
> In node 15:
> 
> Destination	Gateway	Intefrace
> 10.1.13.1	10.1.13.21	sl2
> 10.1.13.20	10.1.13.21	sl2
> 10.1.13.21	*		sl2
> 10.1.13.22	10.1.13.21	sl2
> 10.1.13.23	10.1.13.21	sl2
> 
> But if I configure the all interfaces with network mask 255.255.255.0:
> 
> In node 13:
> 
> Destination	Gateway	Intefrace
> 10.1.15.1	10.1.15.22	sl1
> 10.1.15.20	10.1.15.22	sl1
> 10.1.15.21	10.1.15.22	sl1
> 10.1.15.22	*		sl1
> 
> In node 15:
> 
> Destination	Gateway	Intefrace
> 10.1.13.1	10.1.13.21	sl2
> 10.1.13.20	10.1.13.21	sl2
> 10.1.13.21	*		sl2
> 
> That is, routes are inserted in the routing table up to, and including, the
> address of the network interface in the remote node with which we have a
> link.
> 
> As far as I know, network interface mask should be meaningless to olsrd,
> right?
> 
> Does anyone know this this happens?
> 
> Thanks.
> 
> Nacho.
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005
> 
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users

-- 
Andreas Tønnesen
http://www.olsr.org