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>