[Olsr-users] Question about listed HNA networks and "active" olsr interfaces

Wed Oct 12 15:55:06 CEST 2011

Teco-

Yes -- the enet is a normal subnet, and not like mesh interfaces where 
different hosts on the same subnet can be "distributed" and thus the 
need for host routes at layer 3 so the various hosts on this 
"distributed mesh subnet" can be found (and whatever HNAs they want to 
advertise) etc.  In my case typically only the mesh hosts themselves 
(the single address present on ath1 at each node) needs to be reachable 
(plus their HNAs) and no-one else is on the "mesh" subnet that doesn't 
do active OLSR (in my case the 10.5.0.X/24 subnet where X is simply the 
node number).

For the ethernet -- it's a normal subnet and it's desired for it to be 
an HNA so anyone w/ a DHCP address on that subnet can be reachable 
everywhere (since OLSR won't make host routes for the various DHCP 
clients!).

It's also desired to have OLSR active on the ethernet so it extends the 
the mesh subnet across a wired segment that brings the two "halves" of 
the mesh together -- it's great the OLSR just work across ethernet much 
like it does through wireless setups in ad-hoc mode w/ hidden nodes 
etc.  On enet there are never hidden nodes, but clearly that's not a 
problem for OLSR.

I've also accomplished the same thing (gluing two subsections of mesh 
together) with an OpenVPN tunnel in the "tap" mode -- OLSR is active on 
the tap interfaces at each tunnel endpoint (tap can do broadcasts which 
is great feature of OpenVPN).  Since there's obviously no DHCP or 
anything on the tap interface -- just the two tunnel endpoints, the 
subnet used by openvpn on the tap interfaces never needs to be an HNA.

This year on the large outdoor mesh we do in the Cambridge / Boston Mass 
area for the Head Of The Charles Regatta we have some nodes on tall 
buildings that create an entire mesh, but we also have a couple of 
backhauls with VPN as a backup to "glue" two sections of the mesh 
together in case one more more of our nodes on the tall buildings fail 
etc.  It's really working well.

Lastly -- I use the dyn gw plain feature so I can have a separate script 
with policy routes out my internet backhauls do ping checks to 5 
internet sites that should be reachable if said internet connection is 
alive.  As long as one of the 5 sites respond, it considers the internet 
connection good and just adds a default route.  dyn_gw_plain notices the 
default route and advertise it to the mesh.  When the script sees all 5 
sites unreachable, it removes the default route and dyn_gw_plain notices 
this so the node can try to get a default route from somewhere else in 
the mesh.  Some sites have 2 internet connections and my script simply 
prioritizes the "better one" when both connections are available.  For 
that node to seek a default route from the mesh, both internet 
connections at that site need to go down.  That has worked very well for 
us too.

-Eric

Teco Boot wrote:
> Responding on original mail:
>
> The Ethernet is a normal subnet, right? And high speed, so it makes sense
> to prefer it over the mesh link. So with LinkQualityAlgorithm "etx_ffeth"
> and Mode "ether" olsrd knows how to handle it.
>
> For mesh interfaces, a longest match prefix (/32, /128) is made reachable
> for all nodes in the network. Each such prefix has separate routes on each
> router. Some say the host prefix is to be configured on the mesh interface
> (RFC5889). But this results in remote reachability problems is routing daemon
> was stopped. Therefore, RFC5889 is not practical, and shorter prefix lengths
> are used for configuring the interface. So we have different subnet lengths
> for mesh interfaces itself and the routes to it.
>
> For ether interfaces, we could turn off this host prefix length injection 
> mechanism and send out HNA for the connected subnet. This is how routers 
> usualy work.
>
> So yes, I support a change:
>   On interfaces that are up and mode for that interface is "ether": send out an
>   HNA with configured prefix for that interface.
>
> Teco
>
> Op 12 okt 2011, om 14:28 heeft ZioPRoTo (Saverio Proto) het volgende geschreven:
>
>   
>> Hello,
>>
>> I did not understand the detail of your setup, however:
>>
>> 1) it is fine to have multiple nodes in the network announcing via HNA
>> the same prefix, as long as these node are really connected with some
>> interface to that subnet
>>
>> 2) hna is a global configuration parameter for the olsrd demon, so the
>> prefix will be announced whatever is the state of the interfaces.
>> However you open here a discussion about a potential new feature of
>> binding a HNA prefix to a Interface status. I'll discuss this on a
>> separate thread.
>>
>> Saverio
>>
>>
>> 2011/9/27 Eric Malkowski <(spam-protected)>:
>>     
>>> Hi All-
>>>
>>> It's been a while since I've posted here and I'm still using OLSR 0.5.8-r6
>>> (latest stable of that series before 0.6.X came out).
>>> I have a basic question about listing networks as HNA in the config and the
>>> "Active" interfaces one does OLSR on.
>>>
>>> I usually never list a subnet in the HNA list at the beginning of the config
>>> file AND list the interface that the HNA subnet is tied to for "active" OLSR
>>> at the end of the file.  I have run into a situation where it would be
>>> beneficial to do this.  Is it OK to do this?
>>>
>>> An example could be like this -- two typical mesh + ap nodes out of range of
>>> each other but connected with a simple wired interface:
>>>
>>> Outdoor node:
>>>
>>> ath0  AP network listed only as HNA 10.23.0.1/16
>>> ath1  Mesh 10.5.0.3/24   (does active OLSR, NOT listed as HNA in config)
>>> eth0  Glue network 10.0.3.1/24  (does active OLSR NOT listed as HNA in
>>> config)
>>>
>>> Other node connected by wired link:
>>>
>>> eth0  Glue network 10.0.3.2/24 (does active OLSR NOT listed as HNA in
>>> config)
>>> ath1  Mesh 10.5.0.5/24  (does active OLSR, NOT listed as HNA in config)
>>> ath0  AP network listed only as HNA 10.25.0.1/16
>>>
>>> I've found that even though the two ath1 interfaces (on same subnet) are
>>> separated by the wired link, clients on each ath0 networks of either node
>>> enjoy connectivity everywhere.
>>>
>>> What I do is have one of the two nodes act as a convenience DHCP server on
>>> eth0 so if someone plugs in a wired client, they can get an IP.  If internet
>>> is available, the default route gets them internet access.  However since
>>> the eth0 network 10.0.3.1/24 is not listed as an HNA by at least ONE of the
>>> two nodes, someone on eth0 w/ a DHCP address may not be able to get
>>> everywhere since only host routes are listed for 10.0.3.1 and 10.0.3.2.
>>>
>>> I'd like to simply have each node list their eth0 10.0.3.0/24 network as an
>>> HNA in the config.  Any ideas if this will be a problem?  As I said, I
>>> normally don't configure an interface for active OLSR AND to be listed as
>>> HNA in the config at the same time as it didn't seem like the right thing to
>>> do, but I'm thinking to keep everyone to have full connectivity everywhere
>>> who might grab an IP from the networks on ath0 or eth0 of each node, it
>>> would make make sense that the eth0 10.0.3.0/24 network is listed as HNA in
>>> one of the two nodes' config files or both.  The more I think about this I
>>> would think it should be fine.
>>>
>>> I hope this makes sense.
>>>
>>> Thanks,
>>>
>>> -Eric Malkowski
>>>
>>>
>>>
>>> --
>>> Olsr-users mailing list
>>> (spam-protected)
>>> https://lists.olsr.org/mailman/listinfo/olsr-users
>>>
>>>       
>> -- 
>> Olsr-users mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-users
>>     