[OLSR-users] olsrd with 2 networks

Kosta Welke (spam-protected)
Wed Feb 8 09:26:17 CET 2006


Bernd Petrovitsch wrote:
> On Wed, 2006-02-08 at 01:10 +0100, Kosta Welke wrote:

Disclamer: If anything I write here makes no sense, its my fault. I 
didnt even have a coffee yet ;)

[use a /32 netmask]
>>> - I don't have to explicitly delete the automatically added route
>>>   afterwards.
> I meant the route added with the eth<x>-interface creation at boot time.

I wanted to write "then assign a /32 netmask at boot time", buts thats 
what you wrote, so I guess we agree :)

> Of course. But in the cabled world, the subnet has actually a technical
> relevance (which is almost completely gone with host-only routing).

I agree. In a 'host-only' world, a "My subnet consists of me"-netmask 
makes sense.

If you assign /32 netmasks, it might be helpful to manually set a 
broadcast address on the interface (if you feel olsrd -b is "unclean" 
somehow).

> Yes. But in the cable world, you probably won't configure IP addresses
> from the *same* subnet on different interfaces on different broadcast
> domains on the very same host *and* expect that it works.

I totally agree.

> On the other hand (read: host-based routing), the core box of my node
> has several OLSRD managed interfaces with (almost) *all* IP addresses
> from the same subnet on different physical interfaces.

If this is your setup, using olsrd's broadcast option is propably the 
easiest solution. (As manually configuring the bcast addr for each 
interface is more work for the same benefit)

>> Consider this simple example:
>> 10.0/16 ---box1--- 1.2.3/24 --- box2 ---- 5/8
>> Thanks to olsr you can route from 10.0/16 to 5/8, out of the box, no 
>> configuration needed (Except telling olsrd which interface to use...)

> He, this works (without 255.255.255.255 as configured broadcast
> address)?

Yes. I meant box1 to have two interfaces: one for 10.0/16 and one for 
1.2.3/24. As both box1 and box2 can broadcast to each other using 
1.2.3/24, they are aware that the other one has other subnets.

However, if the network looked like this:
10.0/16 ---box1---1.2.3.4 192.168.0.1---box2--- 5/8
(which would mean that box1 and box2 are on the same layer2 net, but 
have completely different IPs and cant broadcast to each other using 
their usual bcast addresses) You have to fiddle with broadcast addresses 
manually. (Thats only because box1's bcast cant reach box2 and vice 
versa on an IP layer. Bad enough, if only box1 uses a 'global' bcast 
addr, and box2 uses its subnet bcast addr, box2 would see box1 but not 
the other way around -> asymmetrical link)

> One (if not the) good reason is IMHO: You get officail IP addresses from
> RIPE and use them. Then you get more (because you need more) or you use
> private networks for not-to-be-seen outside hosts.
> Voila.

In such a situation, I would advise to re-arrange the network layout to 
be a more "natural" IP network. However, thats theory. In practice you 
might not have that choice.

If you have such a setup, be aware that mix-matching NAT and olsrd 
inside the same network might not be a good idea. NAT on the borders of 
the olsr network, works fine, though.

If such a network crosses routers, remember that olsrd must also run on 
the routers (which might not be possible, as theres no olsrd for e.g. 
IOS, as far as I know), or you must configure your routers to relay 
broadcasts (which increases network load, maybe you want to only do that 
on the olsr port, so that the windows boxes dont flood the network by 
saying "Look at me! I got a share!"[0]). This is for such a Network Layout:

10/8 and 1.2.3/24 in parallel ---box1--- 10/8 and 1.2.3/24 in parallel.

For my university project, olsr would have been a cool choice, but it 
was not possible to deploy it because it coulndt run on the routers :(

HTH,
Kosta

[0] I was also told that if Windows XP Home Edition sees more than a 
certain number of other machines in its network, it stops working. 
However, I never was able to try that out. Lucky me :)




More information about the Olsr-users mailing list