On 11/8/21 8:16 pm, Rob PE1CHL via 44Net wrote:
On 8/11/21 11:35 AM, Toussaint OTTAVI via 44Net wrote:
For a long time now, everything has worked perfectly for those users who announce on internet BGP and do ALSO register on the IPIP mesh. They know how to route to other IPIP mesh members via a tunnel and route the remainder to internet. They are reachable for everyone that has sane routing.
Of course, it works. But every sysadmin has to know exactly how to route every subnet. F/ex, not everybody knows 44.190 routing policy. Grouping into "Internet" and "Intranet" categories, each category in a parent subnet, would hugely simplify things.
Rob, I see you're making some assumptions (which have their own pros and cons), mainly that all 44.0/9 and 44.128/10 traffic that's not local or directly connected is routed via the backbone. This does have some pros and cons, more below.
No, it would make no difference whatsoever! The backbone system would internally use BGP to distribute the subnet routes for all client systems connected to it, much like the IPIP mesh now uses RIP to advertise that info. The difference would be that it would be dynamic, as determined by connection of endpoints, not a static portal route list. The "holes" in those routes default to the route to internet, and the 44.190 ranges would fall into that category. There is no need at all for a sysadmin to do anything special for that. Furthermore, with "every sysadmin" you suggest that this would be a task for anyone in the network, while in reality only the backbone sysadmins would be tasked with that, as the remainder of admins either have a static route for 44/9 and 44.128/10 or they have configured BGP to automatically exchange routes with the backbone routers (and their local radio network).
All nice, but the backbone would need to have _multiple_ links to the Internet. For example, currently (by default), to get from my IPIP connected subnet to my BGP connected one, I have to do a very long trip of 2000+km via San Diego to communicate over 150km! Obviously, an exit point onto the Internet geographically closer would be needed if I was going to trust the backbone to route my traffic correctly.
As I manage both subnets, my solution (that only works for me, of course) is to run a VPN between here and my other subnet, and route traffic between 44.190.8/24 and 44.136.76/24 via the VPN at my 44net router. That VPN link is needed, otherwise traffic with a source IP of 44.136.76/24 would get routed via San Diego. Systems without a 44net IP, OTOH, would simply find 44.190.8/24 via the regular Internet (and via NAT, etc).
But managing a database on the portal about what subnet is Intranet and what subnet is Internet would probably do the job, too. Some scripts could update routing policies from the portal at POP level, which will be managed by skilled sysadmins. Not really "KISS", but it would work.
No database other than the BGP route table would be required. There is a 0.0.0.0/0 route in the route table pointing to the local internet connection, and several routes to participants in the backbone (similar to what we now have on IPIP) which are more specific and are taken when available. We have this setup here for a long time and I can assure you we do nothing special for 44.190. Our route table looks like this:
That would work if all routing takes place on the one device (nice, when you can get that). That's currently not the situation here. I also currently run several networks on the one wire. However, my networking will be rearranged sometime in 2022. Hopefully, I can physically and/or logically separate out the different networks into VLANs.
And with the routing on one device, I would still have the option of setting up a VPN between my subnets, if I wanted to bypass NAT. Currently, that's not necessary for the Internet facing services (they're designed to work with end users behind NAT, for the most part), but it is useful for some internal management tasks.