On Thu, 2007-01-11 at 14:32 -0800, Rajesh Narayanan wrote:
> On 1/11/07, Bernd Petrovitsch <bernd@firmix.at> wrote:
>         On Thu, 2007-01-11 at 12:25 -0800, Rajesh Narayanan wrote:
>         > :-)
>         >
>         > This is precisely the question that I have been myself
>         thinking since
>         > yesterday. I thought of going back to routing fundamentals
>         to see if 
>         > there is a good answer. So far I have not been able to think
>         of
>         
>         Actually Andreas delivered the two possibilities in his
>         answer. One is
>         below and the other is: Take dedicated nodes for this.
> 
> ************ sorry if im starting to sound silly :-), but I didnt
> understand this one.

No problem (English is not my native language and perhaps I'm only silly
- or dumb - right now): You put two LinkSys (or PCs or whatever you
have) running OLSRD as your "dedicated border routers" inbetween the
rest of the mesh network and your uplink. And these have - in the most
simple/extreme case - exactly two interfaces (these maybe "only"
ethernet interfaces but anyone will do):
-) one to your uplink
-) one to the next OLSR router in the mesh network

[...]
>         The other solution (see Andreas email) is to add (low
>         priority) host 
>         routes to known-outside ping targets - the ones which are used
>         to decide
>         if we have an uplink or not.
> 
> **********  this does not help. The issue is with the static route
> that gets added when the uplink is discovered. Once its discovered and
> the static default route gets added, no amount of dancing with olsrd
> or the dyn-gw parameters will be useful.

The low priority host routes are to be added statically and - thus - are
not touched/chaned/removed by OLSRD.
So it should work like:
- Everything is up and running - the static low prio static host routes
  and default route are in place. `ping checks` work (and no one cares
  which route is actually responsible).
- The uplink fails because the ping's fail (e.g. someone pulls the
  cable). OLSRDs dyn_gw plugin removes the default route. Naturally this
  change propagates through the mesh network.
- If the cable is plugged in again, the ping's will work again since
  we have these static low prio static host routes. Via the dyn_gw
  plugin we get a default route again which is also propagated through
  OLSRD.
And the static low prio host routes do not interfere with the OLSR
because OLSRD propagates only routes learned via OLSR or HNA-announcte
(or configured).
Or do I miss something?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



