[Olsr-users] Question about listed HNA networks and "active" olsr interfaces
Wed Oct 12 15:55:06 CEST 2011
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
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
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
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.
> Op 12 okt 2011, om 14:28 heeft ZioPRoTo (Saverio Proto) het volgende geschreven:
>> 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.
>> 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
>>> Other node connected by wired link:
>>> eth0 Glue network 10.0.3.2/24 (does active OLSR NOT listed as HNA in
>>> 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.
>>> -Eric Malkowski
>>> Olsr-users mailing list
>> Olsr-users mailing list
More information about the Olsr-users