[Olsr-users] Question about listed HNA networks and "active" olsr interfaces
Eric Malkowski
(spam-protected)
Wed Oct 12 20:24:40 CEST 2011
Actually the script can use default routes -- I use the multiple routing
table feature in the linux kernel with the iproute2 package and rely on
policy routing so I can source ping packets that take the per interface
routing table with proper default route for the particular interface.
Once the script decides which internet connection it wants to use based
on ping results, it adds a default route to the main table and
dyn_gw_plain notices this and advertises to the mesh. If all internet
connections go bad, the script removes the default route from the main
table so one can be learned from the mesh to route this node's internet
traffic elsewhere.
I've tested this and it works really well for me.
Also -- my script supports dhcp client on the internet connection -- it
discovers the default route learned from DHCP and then builds the policy
route table for that interface and removes the main table default route
until it decides the connection is good.
What I don't have it load balancing, but it's not needed for the amount
of traffic. The main link does everything and the backup links are
slower DSL that we fail over to if the main Canopy links go down.
What you are doing below looks cool too -- and appears to not require
policy routing w/ multiple tables, but just one main routing table and
/1 and /2 prefixes to prioritize -- neat idea.
-Eric
Teco Boot wrote:
> Your check script cannot use a default route for testing the 5 hosts, and conditionally add this route. I expect you do not have dhcp or pppd provided defaults, which many of us have. I use conditionally added (2x) /1 or stronger (4x) /2. With these prefixes, a node can have a "passive default", because a better exit path on another node is available. dyngw can handle the /1 and /2 routes. This is my config:
> LoadPlugin "olsrd_dyn_gw.so.0.5"
> {
> PlParam "HNA" "0.0.0.0 0.0.0.0"
> PlParam "HNA" "0.0.0.0 128.0.0.0"
> PlParam "HNA" "128.0.0.0 128.0.0.0"
> PlParam "HNA" "0.0.0.0 192.0.0.0"
> PlParam "HNA" "64.0.0.0 192.0.0.0"
> PlParam "HNA" "128.0.0.0 192.0.0.0"
> PlParam "HNA" "192.0.0.0 192.0.0.0"
> }
> Note that it enables olsr-network-wide priority: a /2 gw super-seeds all /0 and /1 gateways.
>
> I recently enabled smartgateways. So I could use only the /1's, and a SmartGateway plugin for adjusting exit link metrics (currently bw). Is anybody working on such?
>
> Teco
>
>
>
>
> Op 12 okt 2011, om 15:55 heeft Eric Malkowski het volgende geschreven:
>
>
>> 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
>>>>
>>>>
More information about the Olsr-users
mailing list