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
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...).
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
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
On 12/30/20 3:40 PM, Toussaint OTTAVI via 44Net wrote:
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, 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
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
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 :-)
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
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.
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
-
Marius Petrescu -
PE1CHL -
Rob Janssen -
Rob PE1CHL
-
Tony Langdon -
Toussaint OTTAVI