30 Dec
2020
30 Dec
'20
8:19 a.m.
Yes, a 44 BGP network would do the trick, but I am
certainly not willing
to pay hundreds of USD per month for such an endeavor. BGP peering is
not cheap and not readily available in the whole wide world unless it is
not piggy backed on another preexisting AS for a select few working in
the network business.
Aside from the discussion "what it really costs", this is one reason why I
think
the deployment of access routers around the world should be coordinated by ARDC
instead of being an individual effort by hams around the world each serving only
their local region. Certainly there should be room for that, but it should not
be the only option.
ARDC can investigate and find one or more VPS providers where they can order a
number of VPS including BGP announcement of a subnet at several datacenters,
for some fixed price which should be within the ARDC budget.
In the network structure as I see it, there would be routers connected by tunnels
and serving a VPN service for the users, but they would not all need to have
BGP announced subnets. When it is too expensive to have that in some country,
that can be done in a nearby country instead. The private-AS internal BGP routing
of all AMPRnet addresses will handle that.
Of course one usually would want a country subnet to be announced somewhere
nearby, to reduce latency for the users not connected to AMPRnet. With a
well-connected router mesh in good datacenters, the latency will be in the millisecond
region, and not like the values we now see for traffic going via amprgw.
Rob
30 Dec
30 Dec
8:53 a.m.
New subject: ipencap routing question -> What about the future ?
Le 30/12/2020 à 14:19, Rob Janssen via 44Net a écrit :
Aside from the discussion "what it really
costs", this is one reason why I think
the deployment of access routers around the world should be coordinated by ARDC
instead of being an individual effort by hams around the world each serving only
their local region. Certainly there should be room for that, but it should not
be the only option.
This would be a good start :-)
But I think we should also try to normalize the portion between those
"Access Routers" (let's call them "POPs") and the endpoint
routers.
Having a common system for all the endpoints, all over the world, is the
best solution for developers to adopt it. We'll get more "plug and play"
solutions, more integration in various existing systems, and more users.
A D-Star or DMR repeater works everywhere in the world, because
protocols are (somewhat) standardized. Just provide the IP of a
reflector / master server (of your choice), choose your protocol (there
are several), and it works ! We should be able to achieve the same goal
for 44net addressing. If the protocols and routing policies are
standardized, anybody is free to implement them with the hardware /
software of its choice (Linux, Windows, Mikrotik, Raspberry Pi, OpenWRT,
etc...).
9:13 a.m.
New subject: ipencap routing question -> What about the future ?
On 12/30/20 2:53 PM, Toussaint OTTAVI via 44Net wrote:
But I think we should also try to normalize the portion between those "Access
Routers" (let's call them "POPs") and the endpoint routers.
Having a common system for all the endpoints, all over the world, is the best solution
for developers to adopt it. We'll get more "plug and play" solutions, more
integration in various existing systems, and more users. A D-Star or DMR repeater works
everywhere in the world, because protocols are (somewhat) standardized. Just provide the
IP of a reflector / master server (of your choice), choose your protocol (there are
several), and it works ! We should be able to achieve the same goal for 44net addressing.
If the protocols and routing policies are standardized, anybody is free to implement them
with the hardware / software of its choice (Linux, Windows, Mikrotik, Raspberry Pi,
OpenWRT, etc...).
In principle I agree with that, but I fear the discussions and disagreements about what
that standard should look like.
Protocols are standardized, but new ones appear all the time. Many routers implement
only well-established standard
protocols (L2TP, GRE, PPTP, SSTP), and not newfangled things like wireguard or openvpn.
Ok you write "choose your protocol (there are several)" and that could mean we
could have several "standard protocols"
and they need not be the same set all over the world.
Rob
9:40 a.m.
New subject: ipencap routing question -> What about the future ?
Le 30/12/2020 à 15:13, PE1CHL via 44Net a écrit :
In principle I agree with that, but I fear the
discussions and disagreements about what that standard should look like.
Protocols are standardized, but new ones appear all the time. Many routers implement
only well-established standard
protocols (L2TP, GRE, PPTP, SSTP), and not newfangled things like wireguard or openvpn.
IMHO, we need specific things, so we should not target primarily
business routers, but we should use platforms that allow compilation /
installation of open-source software. The most obvious are Linux and
OpenWRT, but there may be others.
Ok you write "choose your protocol (there are
several)" and that could mean we could have several "standard protocols"
and they need not be the same set all over the world.
I would probably choose one protocol among others for personal reasons,
but you may choose another one for other good reasons :-) OpenVPN and
Wireguard are examples of suitable protocols. The "standard" may allow
two or three of them. The POP / gateway should support both (with a
common set of basic features, and some other features enabled/disabled
according to the protocol capability). And the end users could choose
their "client" protocol.
Of course, handling several tunneling protocols may complicate the
gateways. But keeping some freedom of choice is IMHO a key for acceptance.
This does not apply for routing protocol, anyway. It would have to be
unique. As it's commonly used in many places, I think BGP (including
eBGP and iBGP variants) is a good candidate.
73 de TK1BI
10:06 a.m.
New subject: ipencap routing question -> What about the future ?
On 12/30/20 3:40 PM, Toussaint OTTAVI via 44Net wrote:
Le 30/12/2020 à 15:13, PE1CHL via 44Net a écrit :
Ok, that is not my opinion. I think we should avoid running into traps like "let us
choose that new wireguard as the
standard protocol to be used by everything" as we would again exclude everything
outside of Linux and OpenWRT
and end up in the same situation as we now are with IPIP mesh: always requiring the user
to install a Linux box.
In my opinion, that is the wrong way to go. We should ALLOW the use of open platforms
where users can compile
their own software, but IN NO WAY should we "force" them to do so. And
especially not for evangelism reasons.
A good new network should be usable from a surplus Cisco router with IOS 12.4 or another
standard
branch office router just as well as from a Raspberry Pi.
Rob
In principle I agree with that, but I fear the
discussions and disagreements about what that standard should look like.
Protocols are standardized, but new ones appear all the time. Many routers implement
only well-established standard
protocols (L2TP, GRE, PPTP, SSTP), and not newfangled things like wireguard or openvpn.
IMHO, we need specific things, so we should not target primarily business routers, but we
should use platforms that allow compilation / installation of open-source software. The
most obvious are Linux and OpenWRT, but there may be others.
11:22 a.m.
New subject: ipencap routing question -> What about the future ?
Le 30/12/2020 à 16:06, Rob PE1CHL via 44Net a écrit :
Ok, that is not my opinion. I think we should avoid running into traps like "let us
choose that new wireguard as the
standard protocol to be used by everything" as we would again exclude everything
outside of Linux and OpenWRT
and end up in the same situation as we now are with IPIP mesh: always requiring the user
to install a Linux box.
I'm not talking about choosing a specific protocol. I'm talking about
using a platform that allows installation of standard open-source
software (including the specific software we may need to write for
specific tasks). Too many of us had previous (bad) experiences with
closed software, hardware or service provider. We'd like to be able to
get rid of it completely, HI :-)
A good new network should be usable from a surplus
Cisco router with IOS 12.4 or another standard
branch office router just as well as from a Raspberry Pi.
We are not implementing a standard Internet variant. We are trying to
implement a new version of a ham radio network. But we have to keep some
compatibility with existing things. And some things are very tricky.
Trying to implement them with a router targeted for business
applications may be complicated and/or very restrictive.
We often talk about Linux (or one of the many flavors of Linux) because
it's the perfect Army Knife, or LEGO toolbox, for many, many things. The
POP/gateways will be virtual, and thus, will require Linux. Linux can
use standard network protocols (in the same way as Cisco does), but it
also allows the use of any other software not supported by Cisco, and it
allows the use of scripting/programming languages. We are radio
amateurs. One of our main purposes is experimentation. Linux is a
perfect platform for experimentation. OpenWRT is an optimized version of
Linux for routers, and runs on $20 hardware. FreeBSD is some kind of
cousin of Linux and often used in software firewalls. There are many
other ones...
My fear is that if we use business refurbished routers, we'll limit
greatly the available features.
Anyway, as there seems to be some fans of that kind of setup, maybe we
can design the base tunneling protocol so that it can be implemented on
a business router. But which one ? Cisco ? Juniper ? Fortinet ?
SonicWALL ? Do all those manufacturers support the same tunneling
protocol with NAT traversal and dynamic endpoint IP ?
Moreover, my suggestion was not to restrict to ONE tunneling protocol,
but to choose two or three. One of them can be a "business" protocol
currently implemented in business routers...
73 de TK1BI
3:14 p.m.
New subject: ipencap routing question -> What about the future ?
I think we discuss about 2 different sides of our network coin.
On one hand we have the end users, which may have very little networking
or IT knowledge, and on the other the potential POP sysops.
While on the POP side the implementation and maintainance of the system
is done by knowledgeable persons, and so may actually implement whatever
interconnection protocols we like (including the existing full mesh IPIP
wich is quite fit for the current task except encryption), the user part
should be kept as simple and OS agnostic as possible.
That is why I push with the usage of well known protocols on the user
side, so that the end user can use basically cheap home routers or even
single computers/tablets/phones to achieve 44net connectivity .
What happens between POPs is another story, and the sky is the limit.
But a first practical approach is to keep existing IPIP ful mesh between
POPs which needs a minimal effort, while moving regular clients to
another VPN star topology to increase the accessibility of the network.
Marius, YO2LOJ
On 30.12.2020 18:22, Toussaint OTTAVI via 44Net wrote:
Le 30/12/2020 à 16:06, Rob PE1CHL via 44Net a écrit :
Ok, that is not my opinion. I think we should avoid running into
traps like "let us choose that new wireguard as the
standard protocol to be used by everything" as we would again exclude
everything outside of Linux and OpenWRT
and end up in the same situation as we now are with IPIP mesh: always
requiring the user to install a Linux box.
I'm not talking about choosing a specific protocol. I'm talking about
using a platform that allows installation of standard open-source
software (including the specific software we may need to write for
specific tasks). Too many of us had previous (bad) experiences with
closed software, hardware or service provider. We'd like to be able to
get rid of it completely, HI :-)
3:35 p.m.
New subject: ipencap routing question -> What about the future ?
On 12/30/20 9:14 PM, Marius Petrescu via 44Net wrote:
What happens between POPs is another story, and the
sky is the limit.
But a first practical approach is to keep existing IPIP ful mesh between POPs which needs
a minimal effort, while moving regular clients to another VPN star topology to increase
the accessibility of the network.
The IPIP mesh works but it has the problem of static routing (fixed subnets to each
endpoint).
You could use IPIP tunnels between routers but they would change to /30 addresses on the
endpoints with BGP peering between te routers. When there is such a change it is
probably
better to migrate to GRE instead of IPIP at the same time to be IPv6-future-proof and also
to
have at least authentication (IPsec AH) underneath to protect against unwanted packet
injection
from spoofed source addresses on internet.
Rob
31 Dec
31 Dec
3:55 a.m.
New subject: ipencap routing question -> What about the future ?
On 31/12/20 7:14 am, Marius Petrescu via 44Net wrote:
I think we discuss about 2 different sides of our
network coin.
On one hand we have the end users, which may have very little
networking or IT knowledge, and on the other the potential POP sysops.
While on the POP side the implementation and maintainance of the
system is done by knowledgeable persons, and so may actually implement
whatever interconnection protocols we like (including the existing
full mesh IPIP wich is quite fit for the current task except
encryption), the user part should be kept as simple and OS agnostic as
possible.
And then there's people like me. I'm more than the typical user
- I run
a rather complex network here, with multiple subnets on the one wire,
and even have to policy route at a few points to keep it all going. But
I don't (currently) have the WAN knowledge and experience to run a POP
that might have to participate using BGP, etc (I've never been hands on
with BGP, for example - I just know it exists and have an idea what it
does).
I am also likely to need a bunch of addresses, so where do I fit in the
grand scheme of things?
That is why I push with the usage of well known protocols on the user
side, so that the end user can use basically cheap home routers or
even single computers/tablets/phones to achieve 44net connectivity .
Yeah, need to
keep things straightforward for the majority of end users.
What happens between POPs is another story, and the sky is the limit.
But a first practical approach is to keep existing IPIP ful mesh
between POPs which needs a minimal effort, while moving regular
clients to another VPN star topology to increase the accessibility of
the network.
I see the topology looking more like a coronavirus, where the core of
the network is a "ball" of connectivity, with the end users being on the
end of the spikes. :) But within that body, there's redundancy and
optimisation of routes.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
5:08 a.m.
New subject: ipencap routing question -> What about the future ?
On 12/31/20 9:55 AM, Tony Langdon via 44Net wrote:
And then there's people like me. I'm more
than the typical user - I run
a rather complex network here, with multiple subnets on the one wire,
and even have to policy route at a few points to keep it all going. But
I don't (currently) have the WAN knowledge and experience to run a POP
that might have to participate using BGP, etc (I've never been hands on
with BGP, for example - I just know it exists and have an idea what it
does).
I am also likely to need a bunch of addresses, so where do I fit in the
grand scheme of things?
Running BGP on an endpoint just to tell the POP what networks you want
to receive is very easy. It is easiest when you have a router that has
streamlined the configuration of BGP a little. E.g. on a MikroTik you
would just need this (it can be entered via commandline or via GUI clicks):
/routing bgp instance
set default as=42xxxyyyzz
/routing bgp network
add network=44.xx.yy.zz/nn
add network=44.xx.yy.zz/nn
/routing bgp peer
add default-originate=if-installed name=somename nexthop-choice=force-self \
remote-address=44.aaa.bb.cc remote-as=42pppqqrr ttl=1
That will tell the router to connect to the peer (the POP) and advertise a
few networks. The peer will route those networks to you, and you receive the
routes to other networks via the peer.
The AS numbers are from the private AS range and have a structure that
allows local assignment of numbers (just like IP subnets). It is already in
use in several places.
This can be further tweaked e.g. when you have only a single peer you can
just receive a large route from them instead of all the detail routes that all
point the same direction.
But it is not rocket science. And when using software on a Linux box that
you have to configure yourself (quagga, bird) the principle is the same, you
just may need a somewhat larger configuration file but that would mostly
be the same for everyone so examples can be published.
Rob
1232
days inactive
1233
days old
9 comments
6 participants
participants (6)
-
Marius Petrescu -
PE1CHL -
Rob Janssen -
Rob PE1CHL
-
Tony Langdon -
Toussaint OTTAVI