[OLSR-users] olsrd with 2 networks

[Sven-Ola Tuecke]

Hey,

using a /32 netmask will be OK if you dont have a default route on that 
thing. Otherwise routing is different. Any packet to a destination not 
covered by a host route will be sent to default. In a typical mesh network, 
this is not what you want.

LG Sven-Ola

"Bernd Petrovitsch" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> On Wed, 2006-02-08 at 01:10 +0100, Kosta Welke wrote:
>> Bernd Petrovitsch wrote:
>> > On Tue, 2006-02-07 at 12:47 +0100, Kosta Welke wrote:
>>
>> > The interface will have exactly one IP address.
>> > And actually I'm thinking on configuring /32 on the interfaces IP
>> > address because:
>> > - I don't have to explicitly delete the automatically added route
>> >   afterwards.
>>
>> I do not completely understand what you mean, but please note that olsr
>> automatically deletes routes it created after process termination. (At
>> least, thats what I observed. Please correct me if I'm wrong or if this
>> is not 100% reliable)
>
> This is correct.
> I meant the route added with the eth<x>-interface creation at boot time.
>
>> >   This may be a Linux-only problem and it doesn't hurt really, but it 
>> > is
>> >   far from elegant (and error prone during debugging).
>> >   Think of hosts with several OLSR interfaces (e.g. on antennas,
>> >   LANs, OpenVPN endpoints).
>>
>> Do you mean that Linux automatically assigns a e.g. 10/8 netmask when
>> you only need a /24? Yes, the easiest solution is to adjust the netmask,
>> so that no networks that may be around interfere.
>
> No, the kernel adds a route if you set the interface up. And *this*
> route must be immediately removed - since olsrd is managing the routes
> for that interface(s).
>
>> Depending on the size of your "one-hop limit", your netmask could be
>> narrower, of course.
>>
>> > - IMHO this is the conceptually *only* correct interface address
>> >   configuration since OLSRD routes (conceptually) only hosts and not
>> >   subnets (with != /32 netmask).
>>  >   So relying on some "artificial" subnet declaration looks somewhat
>> >   "fishy" to me.
>>
>> I beg to differ. The subnet declaration is not artificial at all, it is
>> how IP works. The subnet tells the IP stack if it should send the packet
>
> Of course. But in the cabled world, the subnet has actually a technical
> relevance (which is almost completely gone with host-only routing).
>
>> to a router or directly on the interface. So it makes sense to advertise
>
> No, you tell that via the IP route (e.g. the `ip add route` call with or
> without `via`). The netmasks simply defines the subnet (together with
> the subnet address/IP address).
>
>> that you have a route to your subnets. Of course, if you have an
>> uncommon network layout, using netmask /32 and setting olsrd's broadcast
>> address to 255.255.255.255 *can* be the best (or only) solution.
>>
>> >   "artificial" because it has nothing to do with routing (except that 
>> > it
>> >   defines a broadcast address. But I can configure it also in the 
>> > config
>> >   file) or broadcast or collision domains but more a pure 
>> > administrative
>> >   given value.
>>
>> As I mentioned earlier, I did not completely understand what you mean,
>> but note that the netmasks almost only purpose *is* routing decisions.
>
> 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.
> Yes, there may be pathologically situations where this acually works but
> I won't consider it by any means as "normal" (and for sure I won't
> recommend it).
>
> And that is the technical meaning of a "subnet" in the cable world: In
> the vast majority of cases one subnet lives in one broadcast domain (at
> least in theory without hacks).
>
> 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.
>
>> Defining a broadcast address is almost negligible :)
>>
>> >> The broadcast option is only needed when you want to connect to nodes
>> >> that are in your one-hop radius, but have a different network address.
>> > Yes, but the next hop has potentially an address from a complete
>> > different subnet.
>>
>> That why you use olsrd in the first place. 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)?
> I think I must try this out.
>
>> >> A (bad) example would be an ethernet where 10.0/16 and 192.168/16
>> > See it as an example setup for this discussion - there are several
>> > reasons why such setups may make sense and they are IMHO absolutely
>> > unavoidable in the mid-term.
>>
>> If you have good reasons for such a layout, use the -b 255.255.255.255
>> option. Thats why its there :)
>
> 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.
>
> Bernd
> -- 
> Firmix Software GmbH                   http://www.firmix.at/
> mobil: +43 664 4416156                 fax: +43 1 7890849-55
>          Embedded Linux Development and Services
>
>
>
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users