<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Congratulations!! <span class="moz-smiley-s1"><span> :-) </span></span><br>
<br>
<br>
Rajesh Narayanan wrote:
<blockquote
cite="mid8e843e380701121653n3ce3b2b3te8874ba1726b7fc4@mail.gmail.com"
type="cite">THE HACK WORKS! ;-)<br>
<br>
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.<br>
<br>
So here is the problem statement again:
<br>
linkA OLSR linkB<br>
InternetConnA<-------> NodeA <* * * * > NodeB
<-------> InternetConnB<br>
<++++++++++>
<##########>
<br>
** Under normal circumstances NodeA should use InternetConnA (+++++)
and NodeB should use InternetConnB (#####) as shown above.<br>
<br>
** But say linkA breaks or an upstream router in InternetConnA breaks,
then all the traffic from NodeA should go via NodeB as shown below
<br>
linkA OLSR linkB<br>
InternetConnA<-XXX--> NodeA <* * * * > NodeB
<-------> InternetConnB<br>
<##########><br>
<+++++++++++++++++++++++><br>
<br>
The HACK<br>
----------------<br>
* Run OLSR on both NodeA and NodeB
<br>
* I wrote a script that Ping tests InternetConnA <br>
* When the linkA breaks, the default route to internetconnA is removed<br>
- Traffic automatically takes the OLSR route.<br>
* Reinstall the default route periodically to test png to internetConnA
{bad hack i know! :-( }
<br>
- If the ping succeeds then i leave it.<br>
- Else I delete it again.<br>
<br>
Conclusion:<br>
-----------------<br>
* Prototyped redundancy along with mesh.<br>
* Not a very good hack but it shows that this can work.
<br>
<br>
Next Steps<br>
-----------------<br>
* Looking to add this as a plugin to OLSR, maybe as an addendum to the
dyn-gw plugin.<br>
* There are many challenges and its not simple since its a little
counter-intuitive to the basics of routing.
<br>
<br>
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 :-).<br>
<br>
Regards,<br>
Rajesh.<br>
<br>
<br>
<div><span class="gmail_quote">On 1/12/07, <b
class="gmail_sendername">Rajesh Narayanan</b> <<a
href="mailto:nrajesh71@gmail.com">nrajesh71@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi
Andreas,<br>
<br>
Thanks for the detail explanation again. I tried this:<br>
<br>
Case 1:<br>
------------<br>
* Added a host route to a server thats on the uplink to NodeA <br>
* Asked the dyn-gw config to ping that address.
<br>
* Olsrd Configuration:<br>
<snip><span class="q"><br>
Hna4 {<br>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a> <a
href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">
0.0.0.0</a><br>
}<br>
<br>
LoadPlugin "olsrd_dyn_gw.so.0.4"<br>
{<br>
PlParam "Ping" "
<a href="http://10.193.244.15" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">10.193.244.15</a>"<br>
}<br>
<br>
</span><snip><br>
<br>
* Route config:<span class="q"><br>
Destination Gateway Genmask Flags Metric
Ref Use Iface
<br>
</span><a href="http://10.193.244.15" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">10.193.244.15</a>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
<a href="http://255.255.255.255" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">255.255.255.255</a>
UH 0 0 0 Vlan1<br>
(no default routes.. i.e. no routes for <a href="http://0.0.0.0"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
0.0.0.0</a>)<br>
<br>
*** So here is the disparity. HNA says that <a href="http://0.0.0.0"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
can be reached through this node. While there is no route configuration
for this route.
<br>
*** So if I start olsrd with the above configuration then I get this
error
<br>
HNA[00000000/00000000] is invalid<br>
HNA[00000000/00000000] is invalid<br>
HNA[00000000/00000000] is invalid<br>
\<br>
<br>
Case2:<br>
----------<br>
* Now say I add a <a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">
0.0.0.0</a> route so that route table looks like:
<span class="q"><br>
Destination Gateway Genmask Flags Metric
Ref Use Iface<br>
</span><a href="http://10.193.244.15" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">10.193.244.15</a>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0
</a> <a href="http://255.255.255.255" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">255.255.255.255</a>
UH 0 0 0 Vlan1<br>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
<a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
U 0 0 0 Vlan1<br>
<br>
* And change the olsrd.conf to<br>
<snip>
<br>
Hna4 {<br>
## Removed <a href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a> <a
href="http://0.0.0.0" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">
0.0.0.0</a> from here.<span class="q"><br>
}<br>
<br>
LoadPlugin "olsrd_dyn_gw.so.0.4"<br>
{<br>
</span> PlParam "HNA" "<a href="http://0.0.0.0"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>"<span
class="q"><br>
PlParam "Ping" "<a href="http://10.193.244.15" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">10.193.244.15</a>"<br>
}<br>
<br>
</span>OLSRD fails as i get the error:<br>
Fatal error in pligin parameter "HNA"/"<a href="http://0.0.0.0"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>"<br>
(This happens whether i have the <a href="http://0.0.0.0"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">0.0.0.0</a>
in the route table or not)
<br>
<br>
Conclusion:<br>
-----------------<br>
Suggestion of having a host route fails. Maybe due to a bug in the olsr
code.<br>
<br>
Please advice.<br>
Thanks,<br>
<span class="sg">Rajesh.</span>
<div><span class="e" id="q_11017daee2201265_12"><br>
<br>
<br>
<br>
<br>
<br>
<div><span class="gmail_quote">On 1/12/07, <b
class="gmail_sendername">Andreas Tønnesen</b> <<a
href="mailto:andreto@olsr.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">andreto@olsr.org
</a>> wrote:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Rajesh
Narayanan wrote:<br>
> But here is the conclusion I have come to (maybe because of my own<br>
> limited knowledge). I dont think any other hack other than removing<br>
> the default route is going to work, since that is at the core of
the
<br>
> issue. The default route takes precedence so one will have to
delete<br>
> the default route.<br>
><br>
> But since its been deleted, it needs to be added back so as to
check<br>
> if its working after some time and test the ping via the default
<br>
> route. If it works, then great; if not, then it needs to be
deleted again.<br>
<br>
I don't think you understood Bernds explanation. The idea is:<br>
- Set up a static _host_ route to the ping destination trough the
uplink
<br>
interface.<br>
- Now let dyn_gw dynamically add/remote the default route based on the<br>
pings.<br>
- The pings will _always_ be routed through the host route so there is<br>
no need<br>
for any hacks(like re-adding the default route or doing some sort of
<br>
IP-routing bypass).<br>
<br>
It should give you just what you want.<br>
<br>
<br>
My other option(which Bernd also explained) is to have _dedicated_<br>
gateways. That means<br>
you have gateways that _only_ act as gateways. That means they do not
<br>
themselves depend<br>
on Internet connectivity. This is what the plugin was originally created<br>
for. The boxes<br>
that ran this plugin were pure gateways dedicated to providing Internet<br>
access and if they<br>
lost their link they should stop announcing themselves as a GW and just
<br>
wait to recover.<br>
The node it self never needs to have a "backup" Internet route trough<br>
the olsrd domain<br>
since it's ONLY purpose is to serve Internet connectivity not to connect<br>
to Internet<br>
themselves.<br>
<br>
- Andreas<br>
<br>
_______________________________________________<br>
olsr-users mailing list<br>
<a href="mailto:olsr-users@olsr.org" target="_blank"
onclick="return top.js.OpenExtLink(window,event,this)">olsr-users@olsr.org</a><br>
<a href="https://www.olsr.org/mailman/listinfo/olsr-users"
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://www.olsr.org/mailman/listinfo/olsr-users</a><br>
</blockquote>
</div>
<br>
</span></div>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
olsr-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:olsr-users@olsr.org">olsr-users@olsr.org</a>
<a class="moz-txt-link-freetext" href="https://www.olsr.org/mailman/listinfo/olsr-users">https://www.olsr.org/mailman/listinfo/olsr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Stop Spam Now: <a class="moz-txt-link-freetext" href="http://www.spamarrest.com/affl?4025320">http://www.spamarrest.com/affl?4025320</a>
</pre>
</body>
</html>