[OLSR-users] Anyone tried two nodes with internet connection?

[Rajesh Narayanan]

THE HACK WORKS! ;-)

Well nothing too much to be proud about though since its still a hack and a
rather poor one at that though. But it shows that redundancy can work with
mesh networks.

So here is the problem statement again:
                     linkA                   OLSR                linkB
InternetConnA<-------> NodeA  <* * * * > NodeB <-------> InternetConnB
            <++++++++++>                             <##########>
** Under normal circumstances NodeA should use InternetConnA (+++++) and
NodeB should use InternetConnB (#####) as shown above.

** But say linkA breaks or an upstream router in InternetConnA breaks, then
all the traffic from NodeA should go via NodeB as shown below
                     linkA                     OLSR                linkB
InternetConnA<-XXX--> NodeA  <* * * * > NodeB <-------> InternetConnB

<##########>
                                    <+++++++++++++++++++++++>

The HACK
----------------
* Run OLSR on both NodeA and NodeB
* I wrote a script that Ping tests InternetConnA
* When the linkA breaks, the default route to internetconnA is removed
    - Traffic automatically takes the OLSR route.
* Reinstall the default route periodically to test png to internetConnA {bad
hack i know! :-( }
    - If the ping succeeds then i leave it.
    - Else I delete it again.

Conclusion:
-----------------
* Prototyped redundancy along with mesh.
* Not a very good hack but it shows that this can work.

Next Steps
-----------------
* Looking to add this as a plugin to OLSR, maybe as an addendum to the
dyn-gw plugin.
* There are many challenges and its not simple since its a little
counter-intuitive to the basics of routing.

This is still very much an open problem and I'd like to discuss this with
anyone and everyone who would like to help solving this :-).

Regards,
Rajesh.


On 1/12/07, Rajesh Narayanan <(spam-protected)> wrote:
>
> Hi Andreas,
>
> Thanks for the detail explanation again. I tried this:
>
> Case 1:
> ------------
> * Added a host route to a server thats on the uplink to NodeA
> * Asked the dyn-gw config to ping that address.
> * Olsrd Configuration:
> <snip>
> Hna4 {
>     0.0.0.0    0.0.0.0
> }
>
> LoadPlugin "olsrd_dyn_gw.so.0.4"
> {
>     PlParam "Ping"    " 10.193.244.15"
> }
>
> <snip>
>
> * Route config:
> Destination        Gateway     Genmask               Flags    Metric
> Ref   Use     Iface
> 10.193.244.15    0.0.0.0        255.255.255.255    UH        0
> 0       0        Vlan1
> (no default routes.. i.e. no routes for 0.0.0.0)
>
> *** So here is the disparity. HNA says that 0.0.0.0 can be reached through
> this node. While there is no route configuration for this route.
> *** So if I start olsrd with the above configuration then I get this error
>
> HNA[00000000/00000000]   is   invalid
> HNA[00000000/00000000]   is   invalid
> HNA[00000000/00000000]   is   invalid
> \
>
> Case2:
> ----------
> * Now say I add a 0.0.0.0 route so that route table looks like:
> Destination        Gateway     Genmask               Flags    Metric
> Ref   Use     Iface
> 10.193.244.15    0.0.0.0        255.255.255.255    UH        0
> 0       0        Vlan1
> 0.0.0.0              0.0.0.0         0.0.0.0                  U
> 0          0       0        Vlan1
>
> * And change the olsrd.conf to
> <snip>
> Hna4 {
> ## Removed 0.0.0.0 0.0.0.0 from here.
> }
>
> LoadPlugin "olsrd_dyn_gw.so.0.4"
> {
>     PlParam "HNA"    "0.0.0.0"
>     PlParam "Ping"    "10.193.244.15"
> }
>
> OLSRD fails as i get the error:
> Fatal error in pligin parameter "HNA"/"0.0.0.0"
> (This happens whether i have the 0.0.0.0 in the route table or not)
>
> Conclusion:
> -----------------
> Suggestion of having a host route fails. Maybe due to a bug in the olsr
> code.
>
> Please advice.
> Thanks,
> Rajesh.
>
>
>
>
>
> On 1/12/07, Andreas Tønnesen <(spam-protected)> wrote:
> >
> > Rajesh Narayanan wrote:
> > > But here is the conclusion I have come to (maybe because of my own
> > > limited knowledge). I dont think any other hack other than removing
> > > the default route is going to work, since that is at the core of the
> > > issue. The default route takes precedence so one will have to delete
> > > the default route.
> > >
> > > But since its been deleted, it needs to be added back so as to check
> > > if its working after some time and test the ping via the default
> > > route. If it works, then great; if not, then it needs to be deleted
> > again.
> >
> > I don't think you understood Bernds explanation. The idea is:
> > - Set up a static _host_ route to the ping destination trough the uplink
> >
> > interface.
> > - Now let dyn_gw dynamically add/remote the default route based on the
> > pings.
> > - The pings will _always_ be routed through the host route so there is
> > no need
> > for any hacks(like re-adding the default route or doing some sort of
> > IP-routing bypass).
> >
> > It should give you just what you want.
> >
> >
> > My other option(which Bernd also explained) is to have _dedicated_
> > gateways. That means
> > you have gateways that _only_ act as gateways. That means they do not
> > themselves depend
> > on Internet connectivity. This is what the plugin was originally created
> > for. The boxes
> > that ran this plugin were pure gateways dedicated to providing Internet
> > access and if they
> > lost their link they should stop announcing themselves as a GW and just
> > wait to recover.
> > The node it self never needs to have a "backup" Internet route trough
> > the olsrd domain
> > since it's ONLY purpose is to serve Internet connectivity not to connect
> > to Internet
> > themselves.
> >
> > - Andreas
> >
> > _______________________________________________
> > olsr-users mailing list
> > (spam-protected)
> > https://www.olsr.org/mailman/listinfo/olsr-users
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20070112/f15a5f70/attachment.html>