Subject: Re: [44net] Strange Broadcasts... From: "Marius Petrescu" marius@yo2loj.ro Date: 06/06/2015 09:48 PM
To: "'AMPRNet working group'" 44net@hamradio.ucsd.edu
Hi Rob,
I was quite active in the Mikrotik community and tried to push a little our ampr tunnel stuff. But the results are actually null. People are friendly but not interested.
Ok... at the moment I am reading the forum to see how change requests actually are to be posted and how they are handled, as I have some other requests.
The missing element is a way to create an IPIP interface without a specific peer IP, and add routes to specific peers on a given IPIP interface to get it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to interfaces, let alone "onlink" routes. So even when you would want to load routes using a script, it still cannot be done. They must have a reason for this (probably they want to keep the routing entirely clean according to common practices), as the Linux kernel can do a lot more than what they expose via the config interface.
The easiest way to get ampr up fully is actually to set up a metarouter on a mipsbe routerboard (they have a xen virtualization on those), and run a OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it works, but at the moment I use a PPC based routerboard which doesn't offer virtualization. But your RB2011 is a good candidate for this kind of setup, being mipsbe based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik series.
As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP. But for others, this approach can be interesting. Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over this radio link and the MikroTik (but there is no useful content on them).
Regarding to linux: They run a proprietary distribution on a 3 kernel, but shell access is unfortunately not available, and there is no way to add 3-rd party extensions.
The device can be "rooted", though. You get a busybox shell. I have not done that yet, it will probably make it difficult to get support in case I encounter some bug I want to be fixed.
Rob
On Wed, Jun 10, 2015 at 12:49 PM, Rob Janssen pe1chl@amsat.org wrote:
The missing element is a way to create an IPIP interface without a specific peer IP, and add routes to specific peers on a given IPIP interface to get it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to interfaces, let alone "onlink" routes. So even when you would want to load routes using a script, it still cannot be done.
You lost me here. I've had scripts doing this, successfully, for quite some time (unless I misunderstand you). No, it's not via a single IPIP interface, but these routers are very capable of managing lists of hundreds of items, so that's of no concern.
https://github.com/kd7lxl/python-amprapi/blob/master/updateros.py
Usage: https://github.com/kd7lxl/python-amprapi/#usage-1
You can run it with -n -v to just print a list of commands that would be run to configure all the AMPR tunnels. This is a non-destructive way to see what this script does in terms of ROS commands.
Tom KD7LXL
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)
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.
This brings me to a new idea: a metarouter running that pyton script on the same router the interfaces are created on... Hmmm.
73s de Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom Hayward Sent: Thursday, June 11, 2015 19:16 To: AMPRNet working group Subject: Re: [44net] Strange Broadcasts...
(Please trim inclusions from previous messages) _______________________________________________ On Wed, Jun 10, 2015 at 12:49 PM, Rob Janssen pe1chl@amsat.org wrote:
The missing element is a way to create an IPIP interface without a specific peer IP, and add routes to specific peers on a given IPIP interface to
get
it in multipoint mode.
That is clear, yes. I already found that the do not support static routes being bound to interfaces, let alone "onlink" routes. So even when you would want to
load
routes using a script, it still cannot be done.
You lost me here. I've had scripts doing this, successfully, for quite some time (unless I misunderstand you). No, it's not via a single IPIP interface, but these routers are very capable of managing lists of hundreds of items, so that's of no concern.
https://github.com/kd7lxl/python-amprapi/blob/master/updateros.py
Usage: https://github.com/kd7lxl/python-amprapi/#usage-1
You can run it with -n -v to just print a list of commands that would be run to configure all the AMPR tunnels. This is a non-destructive way to see what this script does in terms of ROS commands.
Tom KD7LXL _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Thu, Jun 11, 2015 at 11:20 AM, Marius Petrescu marius@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:
- An IPIP interface needs mandatory a remote endpoint (no P2MP)
- 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
On 2015-06-11 20:45, Tom Hayward wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 11, 2015 at 11:20 AM, Marius Petrescu marius@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:
- An IPIP interface needs mandatory a remote endpoint (no P2MP)
- 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?
ntpd cares about it and also the Linux and FreeBSD kernels.
ISC ntpd listens on each interface automatically, hence after ~200 interfaces it breaks as it runs out of file descriptors (each interface gets a separate socket as it uses it that way to be able to properly select the interface to reply to packets on that interface).
Both the Linux and FreeBSD kernels (last time I checked) use a linked list to go through the interfaces, hence more interfaces means more slowness on the last couple of interfaces...
Hence yes, at one point it does matter ;)
Just a FYI though ;)
Greets, Jeroen
On Thu, Jun 11, 2015 at 12:03 PM, Jeroen Massar jeroen@massar.ch wrote:
(Please trim inclusions from previous messages) _______________________________________________ On 2015-06-11 20:45, Tom Hayward wrote:
(Please trim inclusions from previous messages) _______________________________________________ Forget about this; it's just syntax. Who cares if we have to have hundreds of P2P interfaces instead of a single P2MP?
ntpd cares about it and also the Linux and FreeBSD kernels.
We're talking about the RouterOS kernel (Linux derivative). Do you have any specific knowledge or test results from it, or is this just unrelated trivia?
Tom KD7LXL
-
Jeroen Massar -
Marius Petrescu -
Rob Janssen -
Tom Hayward