12 Aug
2021
12 Aug
'21
3:02 a.m.
On 8/12/21 2:53 AM, Tony Langdon via 44Net wrote:
Note that in the proposed structure, anything with a net-44 source address and
an internet destination address can be routed to the backbone network and it will
go to internet without NAT. No need for separate subnets to achieve that.
And because the path via the backbone is efficient, there is no need to add
band-aids like routing internet traffic via a local NAT router. That is what whe
need to get rid of, because that is what is causing the issues that motivated
the creation of the separate 44.190 network. That solution was apparently
not good enough and now we get the proposal of renumbering everything.
Which I predict will not solve the problems either. That is why I propose fixing
it the right way: by setting up a proper backbone network with good connectivity
and easy options to join it (so there is no reason why people would skip it and
use the local NAT shortcut).
Rob
On 11/8/21 8:16 pm, Rob PE1CHL via 44Net wrote:
Yes, of course!
My idea was to announce (mostly) /16 networks from the backbone routers, each
of them in the backbone router(s) closest to the area where that /16 is used.
Others proposed to announce the full space at some places in the backbone
router network.
Essential is that traffic between you and internet crosses over at a router
physically close to you. There should be at least one such connection in
Australia, probably 2 or 3. You would not have to go via San Diego.
As I see it, San Diego could become one of the backbone router sites, nothing
special anymore.
Note that in the Netherlands, our BGP connected subnet and our IPIP
connected subnet is the same. We have fast roundtrip to internet and
still have IPIP connections to those on the mesh. That is functionaly the
same as I see it in the backbone network: it would be a network of routers
interconnected by a tunnel mesh, and also announcing networks to internet.
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. 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.