[OLSR-users] olsrd with 2 networks

Bernd Petrovitsch (spam-protected)
Wed Feb 8 11:16:20 CET 2006


On Wed, 2006-02-08 at 09:26 +0100, Kosta Welke wrote:
> 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 ;)

/me-too-Disclaimer: All bullshit written by me also belongs to me.

> [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 :)

Yup.

> > 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).

No, that's actualy the clean solution IMHO. The "unclean" is - writing
as extremely as possible  - to configure a (IMHO) conceptually wrong
netmask on an interface so that olsrd can use it there and clean up the
mess after configuring the actually (IMHO) wrong netmask.

[...]
> > 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)

Yup.

> >> 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 

They could use use layer2 broadcasts. Do we want this?

> 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)

And that's precisely the setup which should work afterwards (sorry to
all for not drawing nice ASCII art in the first place) without "strange"
config+setup hacks where you need 3 years of experince of active IP
network administration.

> > 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.

ACK. 

> 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.

That's actually one feature (IMHO) that you don't need NAT at all (which
is the reason not mentioning it): Give one interface on each box a
public IP address (if you really want to see it on the Internet and vice
versa) and give all others private IP addresses (no IMHO we don't really
have a shortage of IPv4 addresses but it is not trivial to get some from
RIPE).
Of course the other "trivial" solution is to totally migrate to IPv6.

> 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 

The basic assumption was that all routers (per definition "IP hosts with
more than one interface") run olsrd (meaning more the protocol and the
implementation).
In theory it should work with RIP and/or OSPF too (as long as you
configure /32 netmasks on your interfaces) but it would be probably too
slow.

> 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.

Yes, of course, this is another "solution": But then it is IMHO easier
(and equivalent to the above drawing) to assign *all* interfaces IP
addresses from one private net and announce the public IP addresses via
HNAs alone.

> 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 :(
[..]
> [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. 

ROTFL....

> However, I never was able to try that out. Lucky me :)

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services





More information about the Olsr-users mailing list