On 8/11/21 4:37 PM, Toussaint OTTAVI via 44Net wrote:
Le 11/08/2021 à 16:05, Rob PE1CHL via 44Net a écrit :
I think ARDC can offer end-user PoP access to their backbone themselves, and regional
groups can always decide to setup their own access which connects to such a PoP and allows
their own end-users to connect.
But we may have a problem if we tie a specific user to a specific subnet on the portal,
and we want to provide him the same subnet whatever the POP he uses. F/ex, if a Corsican
user obtains an allocation for Internet stuff (assume 44.190.11.0/30), and if he connects
to your POP in the Netherlands, how could we route the incoming traffic to it ? As
Internet eBGP minimal subnet is /24, 44.190.11.0/24 will still be announced via my POP.
That means I'll have to route the incoming traffic from my POP to yours, then to the
user ?
When you have a system that you want to be capable of doing such special routing, you need
to have a BGP session with the backbone.
Over that BGP session you can send or receive those routes.
There is NO minimal subnet size on BGP! We use BGP to route single addresses (/32). The
"minimal /24" restriction is only a policy on Internet BGP, because there
already are so many routes in the table and they do not want to have even more.
However, on our own backbone network (which runs BGP on private AS numbers and is in no
way exchanging BGP information with the internet, only with other AMPRnet routers over
tunnels) we do not have to implement that restriction and we can route everything.
And still, people can filter by subnet size on their own routers when they want a smaller
table and are not interested in all those detailed routes.
On our current design, subnets for users are allocated by us locally, and we have two
local POPs, both announcing our subnet. Access routers can connect to POP1 or POP2.
That's easy because all is local. But if we want to allow any user to connect to any
POP and always get the same IP/subnet, things may not be so easy...
In our network it already works. Whenever a user connects e.g. to OpenVPN, the route to
their address is distributed using BGP.
So you can be on radio in network 44.137.40.0/22 (on a WiFi access point), then switch off
your radio and connect to OpenVPN using a certificate that issues you address 44.137.40.2,
and you still get the correct routing. All routers in the Dutch network route that single
address to the OpenVPN server instead of to the router serving 44.137.40.0/22.
For this to work also for the other users on that WiFi access point, proxy-arp has to be
enabled on those accesspoint networks.
Then, when another user ARPs for 44.137.40.2 the router will answer with its own MAC
address and route the traffic using that single-address route.
Works just fine!
We also have this for IPIP and IPsec tunnels, routes obtained from ampr-ripd are
automatically redistributed in our radionetwork using BGP.
Some users also may not think their local access
point is reliable enough and want to connect to an ARDC PoP or even more than one.
It should always be possible to have multiple options, we should not wire the
possibilities into the network design.
Human being is what it is, and I don't think this is specific to amateur radio, HI
:-) Thus, every user must be allowed to connect to any POP of its choice (not necessarily
the nearest). On a dynamic DHCP pool, that's easy. But if we want to distribute the
same subnet to an access router whatever the POP, is it possible to do that automatically
at WW scale ? Does it make sense for a TK user to connect to a PE POP ? The fact our
Echolink clients often connect to VK proxies is definitely not a good reason, HI :-)
Given the current scale of the AMPRnet network we should not worry about the number
of routes. When compared to internet, we are miniscule.
We have 700 routes in the IPIP mesh, currently about 230 routes in the Dutch network, I
think about 2500 in the HAMNET network, etc.
All in all probably less than 10000. And you can always filter some detailed routes when
you are not handling specific cases like the above.
(e.g. the whole world would not be interested in all our /32 routes unless they want to
handle /32 addresses connected to a PoP in TK)
Then, should we revert to something simpler, with
mandatory "primary" and "secondary" POPs (based on geographic
location, and with specific configuration / agreement between POP operators) ?
For users that connect and setup a BGP session, there is no need to configure what network
they have. But there may be a need to configure a BGP peer. Current RouterOS requires
that, the next version does not (so you can accept any incoming BGP session using a single
config item).
With the current software it would be required to configure somewhere (
portal.ampr.org of
course!) on which PoP you want to connect, and you would get some info in return (like the
BGP AS# and the IP address of the BGP software).
Rob