HNA route calculation

All changes in the network topology must be considered as a possible change in the routes to HNA gateways. Therefore the HNA routes are recalculated rather often in a mobile context. As seen in section 6.6.3 all variables that signal a topology change in olsrd triggers a recalculation of HNA routes. HNA recalculation can also be triggered by setting the global variable changes_hna to UP.

HNA route calculation is a matter of calculating the closest gateway to all networks for which HNA entries exist. This set of routes is then compared to the current HNA routes, and differences are updated in the current set and in the kernel routing table much like the approach described in section 6.8.8.

Although not explicitly specified in RFC3626, HNA routes should be kept as stable as possible. This means that in a situation as displayed in figure 7.1, where multiple gateways are registered for the same network and all the gateways are registered with the same hop-count, route calculation should not ``dangle'' between these gateways. One gateway should be chosen, and this should be used as long as the given situation exists. In olsrd this is the default behavior due to the hashing of entries in the HNA set and the route calculations traversal of this set. The stability of routes over time, based on other factors than hop-count, is however not taken into consideration when calculating HNA gateways.

Figure: A situation where node A should keep a stable Internet gateway by either using G1 or G2, and not alter between them.

HNA route calculation is implemented in src/routing_table.c and src/process_routes.c.