11 Aug
2021
11 Aug
'21
7:53 p.m.
On 11/8/21 8:16 pm, Rob PE1CHL via 44Net wrote:
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.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
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: