[OLSR-users] Anyone tried two nodes with internet connection?
Rajesh Narayanan
(spam-protected)
Sat Jan 13 08:49:08 CET 2007
Thanks for the vote of confidence and I did go around with a little drumbeat
;-) . But the issue is still there and would be great if it can be solved
within the dyn-gw plugin.
Any idea on how to propose this as a need/issue to be resolved?
Thanks,
Rajesh.
On 1/12/07, Tim Martin <(spam-protected)> wrote:
>
> Congratulations!! :-)
>
>
> Rajesh Narayanan wrote:
>
> 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
> > >
> >
> >
> ------------------------------
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)://www.olsr.org/mailman/listinfo/olsr-users
>
>
> --
>
> Stop Spam Now: http://www.spamarrest.com/affl?4025320
>
>
> _______________________________________________
> 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/2e775c5b/attachment.html>
More information about the Olsr-users
mailing list