10 Jun
2015
10 Jun
'15
3:49 p.m.
Subject:
Re: [44net] Strange Broadcasts...
From:
"Marius Petrescu" <marius(a)yo2loj.ro>
Date:
06/06/2015 09:48 PM
To:
"'AMPRNet working group'" <44net(a)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
11 Jun
11 Jun
12:15 p.m.
New subject: Strange Broadcasts...
On Wed, Jun 10, 2015 at 12:49 PM, Rob Janssen <pe1chl(a)amsat.org> wrote:
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
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. 
2:20 p.m.
New subject: Strange Broadcasts...
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(a)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(a)amsat.org> wrote:
load
> 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
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2:45 p.m.
New subject: Strange Broadcasts...
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
3:03 p.m.
New subject: Strange Broadcasts...
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(a)yo2loj.ro> wrote:
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
(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?
3:31 p.m.
New subject: Strange Broadcasts...
On Thu, Jun 11, 2015 at 12:03 PM, Jeroen Massar <jeroen(a)massar.ch> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On 2015-06-11 20:45, Tom Hayward wrote:
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
(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.
3260
days inactive
3261
days old
5 comments
4 participants
participants (4)
-
Jeroen Massar -
Marius Petrescu -
Rob Janssen -
Tom Hayward