[Olsr-dev] olsrd-0.6.1 deletes default route on MacOS X

Markus Kittenberger (spam-protected)
Sat Dec 11 01:49:34 CET 2010


> But Babel does support filtering? No? And it works?

with distant vector this is easier,..

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)

and so the neighbours will not try to reach this tagets over him, ...

while linkstate neighbours (that know the complete topo of the mesh) will
expect their traffic being forwarded over the best route *G
and don't expect nodes to have their own plans, about this *G

On Fri, Dec 10, 2010 at 11:07 PM, Mitar <(spam-protected)> wrote:

> Hi!
>
> On Fri, Dec 10, 2010 at 5:09 PM, Henning Rogge <(spam-protected)>
> wrote:
> > The problem with MANET routing is that is DEPENDS on the fact that every
> > nodes forward ALL routes along the mesh.
>
at least with linkstate,..

furthermore usually policy routing is absolutely sufficient to route your
own traffic different than mesh traffic,..

regarding: filtering plugin,..
why build something into olsrd, which is already available on your router,.

of course "router" != windows box, but linux and bsd both can do policy
routing (but they do it different *g)

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

As olsrd already creates policy routing rules, for niit and smart gateways
(only under linux), everything needed is already here,..
it would just need a little more code (mostly in the config parser) to
create some policyrules based on things in olsrd.conf like

PolicyRouting {
 MeshRange 10.10.0.0/16
 MeshRange 10.20.0.0/16
 LocalRange 10.10.10.0/24
 MeshInterface vlan123
}

olsrd could than write a ruleset:

that routes all traffic from all mesh interfaces (automatically including
all interfaces olsrd runs on, and Additional Specified MeshInterfaces)
and all traffic from and to all MeshRanges with olsrd routes. (except
targets announced via hna (and maybe additional LocalRanges))

while all other traffic will use the main routing table containing (only)
the static routes from the user or dhcp routes,...

I think this should be ok for 95% of setups with colliding local and olsrd
routes,..
and if not the user can do/add its own more complex policy routing ruleset
if he "likes" *G

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20101211/e21d6038/attachment.html>


More information about the Olsr-dev mailing list