12 Aug
2021
12 Aug
'21
6:38 a.m.
On 12/8/21 5:02 pm, Rob PE1CHL via 44Net wrote:
Mostly
OK so far. :)
On 8/12/21 2:53 AM, Tony Langdon via 44Net wrote:
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.
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. 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).
There is one aspect that might be a potential issue, and that is where
the 44net IP is on amateur links. Open access to the Internet could be
problematic, from a legal point of view. I know our authorities are
very conservative in this area, and in fact, it took a while to get
Winlink approved for use here, that was a long running saga. They're
fine with using the Internet as a carrier for amateur traffic (e.g. RoIP
networks like IRLP, Echolink, etc), or the IPIP tunnels, but not so keen
where non amateur traffic could enter the amateur frequencies. This
implies there will need to be some fairly straightforward firewall
options available. I could easily use iptables, but others might need
something more user friendly. I would have 3 classes of IP in my networks:
1. Public, BGP routed (direct connection). Basically my existing
44.190 allocation is a prime example of this. These IPs are to provide
Internet facing services.
2. Backbone routed IPs on LAN (or local wifi). These are mainly for
intranet use, but not being on air, connection to Internet hosts is
tolerated. For example, these addresses would be a good place to run an
IRLP or Echolink node.
3. Radio based IPs. Here, I would be very selective what to allow by
default - other Intranet addresses, possibly at least some of the public
BGP routed 44net space. Individual hosts on radio may even have cause
to communicate with specific Internet IP addresses (e.g. the end point
for some other amateur link), on a case by case basis. Or I may allow
specific ports/protocols only to the general Internet (e.g. Echolink,
IRLP, etc).
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com