On Thu, Jun 11, 2015 at 11:20 AM, Marius Petrescu <marius(a)yo2loj.ro> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Tom, we were discussing about the possibility to completely setup a mesh as
in linux, via one single P2MP interface, to be able to have a ampr-ripd-like
mechanism contained in the router.
This setup is not possible on ROS at the moment, having 3 restrictions as a
cause, even if the kernel module allows this:
1. An IPIP interface needs mandatory a remote endpoint (no P2MP)
2. A route can not have a specified hardware interface (the syntax via
w.x.y.z%interface is not allowed on IPv4)
3. OnLink routes can not be created (routes which have no routable
destination at creation time)
Forget about this; it's just syntax. Who cares if we have to have
hundreds of P2P interfaces instead of a single P2MP? The script
creates them, so the burden of both methods is equivalent.
Of course, by creating an interface for each mesh
partner is possible, and
the problem is solved (like your script does), but it needs an external
machine to run that script periodically, and as such is not self contained.
Okay, so the problem at hand is that we want an update mechanism
self-contained in the router. This is a fair request. It certainly
would ease maintenance.
This brings me to a new idea: a metarouter running
that pyton script on the
same router the interfaces are created on... Hmmm.
I considered this, but failed to identify a benefit worthy of the
setup time. I just run the tunnel update script on my workstation
because it's easy.
But if you are going to run something on a metarouter, I'd recommend
going one step farther and just run ampr-ripd in the metarouter, as
you have done. I'm curious how you configured this. Did you also run
an IGP on the metarouter so that the routes were shared with the
primary router? I'll probably set this up soon, although we have a
VMware environment now, so it'll be virtualized there instead of
metarouter.
Tom KD7LXL