<div><div class="im"><br>
</div>> But Babel does support filtering? No? And it works?<br><br>with distant vector this is easier,..<br></div><div><br></div><div>cause a distant vector router just don't tell it's neigbours about targets it don't like to route them to,.. (i.e he filters out)<br>
<br>and so the neighbours will not try to reach this tagets over him, ...</div><div><br></div><div>while linkstate neighbours (that know the complete topo of the mesh) will expect their traffic being forwarded over the best route *G<br>
and don't expect nodes to have their own plans, about this *G<br></div><br><div class="gmail_quote">On Fri, Dec 10, 2010 at 11:07 PM, Mitar <span dir="ltr"><<a href="mailto:mmitar@gmail.com">mmitar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi!<br>
<div class="im"><br>
On Fri, Dec 10, 2010 at 5:09 PM, Henning Rogge <<a href="mailto:hrogge@googlemail.com">hrogge@googlemail.com</a>> wrote:<br>
> The problem with MANET routing is that is DEPENDS on the fact that every<br>
> nodes forward ALL routes along the mesh.<br></div></blockquote><div>at least with linkstate,..</div><div><br></div><div>furthermore usually policy routing is absolutely sufficient to route your own traffic different than mesh traffic,..</div>
<div><br></div><div>regarding: filtering plugin,..</div><div>why build something into olsrd, which is already available on your router,. </div><div><br></div><div>of course "router" != windows box, but linux and bsd both can do policy routing (but they do it different *g)</div>
<div><br></div><div>imho a plugin or some built in configuration option to help setting up policy rules, would be better than a filtering plugin, that will only break "everything" *G</div><div><br>As olsrd already creates policy routing rules, for niit and smart gateways (only under linux), everything needed is already here,..<br>
it would just need a little more code (mostly in the config parser) to create some policyrules based on things in olsrd.conf like<br></div><div><br>PolicyRouting {<br> MeshRange <a href="http://10.10.0.0/16">10.10.0.0/16</a></div>
<div><div> MeshRange <a href="http://10.20.0.0/16">10.20.0.0/16</a><br> LocalRange <a href="http://10.10.10.0/24">10.10.10.0/24</a><br> MeshInterface vlan123</div><div>}<br><br></div></div><div>olsrd could than write a ruleset:</div>
<div><br></div><div>that routes all traffic from all mesh interfaces (automatically including all interfaces olsrd runs on, and Additional Specified MeshInterfaces)<br>and all traffic from and to all MeshRanges with olsrd routes. (except targets announced via hna (and maybe additional LocalRanges))<br>
</div><div><br>while all other traffic will use the main routing table containing (only) the static routes from the user or dhcp routes,...</div><div><br></div><div>I think this should be ok for 95% of setups with colliding local and olsrd routes,..</div>
<div>and if not the user can do/add its own more complex policy routing ruleset if he "likes" *G<br></div></div><div><br></div><div>Markus<br></div>