[Olsr-users] Managing Local Default Route offered as HNA 0.0.0.0 when healthy versus OLSR learned default route from mesh

[Eric Malkowski]

That's a good idea -- I could do that, but my concern would be that when
OLSR installs a route of higher priority when the local internet
connection fails, does the OLSR dyn_gw plugin use pings that are forced
out the local internet connection eth0?  I don't want OLSR to install a
default route and then that node always thinks it needs to use some
default route in the mesh and things are "healthy" via pings that go
through the mesh rather than out the local eth0.  i.e. I want it to return
to using the local eth0 when the internet connection comes back (detected
by ping replies from internet hosts).

I will test it and take a closer look at the dyn gw plugin to make sure it
works that way.  If not, I could probably avoid using multiple routing
tables and just rely on internet gateway using a lower priority as you
describe and then use the -I argument to ping to force the pings that
monitor the internet connection to go out eth0 even when OLSR has
installed a default route and the internet connection is down and we're
trying to detect when it's back up so the OLSR default route can be
deleted (by dyn_gw_plain).

Thanks for responding.  I'm familiar with route metrics, but just didn't
think to do it that way!  Much simpler.  Thanks.

-Eric

>> Problem is the wired default route is favored over the OLSR installed
>> default route (zero metric versus non-zero olsr default route metric),
>
> That's what route priorities are for.  You need to make sure that the
> default route has a lower priority than the priority that OLSR uses.
>
>   ip route add ... metric 17
>
> (The kernel calls it ``priority'', the user-space tools call it
> ``metric,'' and Cisco calls it ``administrative distance.'')
>
>                                         Juliusz
>