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

[Eric Malkowski]

Tried this -- but it won't work because OLSR dyn gw plugin only considers
for HNA internet to advertise to rest of mesh a route with metric
(priority) zero.  From sourcecode:

if( (ifflags & RTF_UP) &&
     (metric == 0) &&
     (netmask == mask.v4.s_addr) &&
     (dest_addr == net->v4.s_addr))
   {

       ... Code to ping an internet IP to validate the gateway is good ...

   }

When setting my internet default gateway to metric > 0 like you describe
(you suggest 17), OLSR never wants to advertise the internet connection to
the rest of the mesh.  I need it to do that when it's local internet
connection is healthy.

I'm going to try out my 2nd routing table approach -- a quick look at the
dyn_gw_plain plugin appears it will work well -- my 2nd routing table and
sourced pings in my own script can add or delete a metric zero default
route  in the kernel's "main" routing table depending on whether I detect
the link to be good by using my 2nd routing table (that always has a
default gw via eth0) to monitor things.

I'll post my results.

Thanks for the ideas.

-Eric

> 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
>>
>
>