Benoit,
Routing for subnets of 44/8 is very complex compared to simple
ISP-style routing. I will try to describe it in general; there are
fine points which I won't go into here.
Routing inside AMPRNet, and to and from the outside world is very
different depending on which kind of AMPRNet subnet you are connected
to.
Note that the UCSD AMPRNet router is known as AMPRGW.
If you are connected via one of the AMPRNet subnets which is directly
connected to the Internet and announced via BGP, or you are on a
non-44 subnet (such as one provided by your ISP), your routing to
addresses on network 44 is handled just like any other Internet
address; it goes via your default route to the Internet backbone
which routes it to the destination. Note that that destination may
be via AMPRGW or it may be another subnet of 44/8 which is directly
connected. (If you look at the global BGP routing tables, you will
see that 44.0.0.0/8 is variably subnetted, with subnets varying in
size from /24 to /15.) There are about 150 44.x.x.x subnets which
are directly connected to the Internet backbone and are announced
via BGP.
But there are some 600 MORE subnets of AMPRNet which are NOT announced
via BGP. They are not directly reachable from the Internet backbone.
Instead, they are announced to the world by the overarching 44/8
route via AMPRGW at UCSD. Packets to them are sent to AMPRGW, which
encapsulates them in a TUNNEL and sends them to a gateway to the
subnet, where the packets are de-encapsulated and placed on the
subnet's LAN.
Packets originating on that LAN are sent, depending on their
destination, either via the tunnel to AMPRGW for injection into the
Internet backbone, or if for another tunnel-connected AMPRNet subnet,
via another tunnel to the appropriate gateway for the destination's
44.x.x.x LAN.
The connectivity *INSIDE* the tunnel-connected AMPRNet is a MESH
with 600+ tunnels connecting the various subnets that are not
BGP-announced. There is, strictly speaking, no single default route
to all of network 44/8. There is a routing table (often referred to
as "the encap table") which lists the tunnel-connected subnets and
the Internet address of the gateway which serves it. A few lines of
this table look like this:
44.0.0.1/32 via 169.228.34.84
44.10.2.0/27 via 66.85.73.59
44.102.1.112/30 via 68.40.58.30
44.102.1.0/24 via 23.115.92.204
There is no BGP announcement for subnet 44.10.2.0/27, except the
one for all of 44/8 at AMPRGW. So non-44 hosts, and those on
BGP-announced 44 subnets would send packets for (eg) 44.10.2.1 to
AMPRGW, which they would be encapsulated into a tunnel whose endpoint
(as shown in the table above) is 66.85.73.59. Response packets
would take the reverse route back via AMPRGW.
44-net hosts which are tunnel connected would consult their local
routing table and see that packets to 44.10.2.1 would need to be
encapsulated and sent to the tunnel between that host (or its
gateway) and 66.85.73.59, where they would be de-encapsulated and
placed on the 44.10.2.0/27 LAN.
Packets to non-existent subnets of 44/8 are dropped, either by AMPRGW
if they get that far, or by the local tunnel gateways.
In addition, in order to reduce the amount of garbage reaching
AMPRNet hosts, and to isolate those that don't want to be connected
to the main Internet, AMPRGW filters inbound packets at the /32 level
before encapsulating them. If you're not in the filter table (which
is driven by the
AMPR.ORG DNS tables), you won't get any traffic
from the Internet via AMPRGW.
Doing this mesh routing in a conventional router (by Cisco, Mikrotik,
Juniper, FreeBSD, etc) is painful. You need some 450 separate
tunnels each with their own endpoint, to some 600+ destination
subnets. As these can change hourly, maintaining this is hard.
However, the Linux kernel 'iptables' has a mechanism where you can
set up a single tunnel interface which can have a per-packet endpoint
address, so once the 'encap' routing table is loaded, only one
tunnel interface is needed. Most people do it this way. There is
a periodic transmission from the AMPRGW gateway to all the tunnel
gateways which updates the routing table automatically, a little
like RIP would.
I hope this helps.
- Brian
[NB: you say you are connected to 'hamnet'. There are several different
hamnets; I don't know the specifics of the one you're connected to.]
On Sat, Feb 24, 2018 at 10:09:44AM +0100, Benoit Panizzon wrote:
Dear List
I'm pretty newly connected to hamnet, and also work at an ISP.
I always assumed 44.0.0.0/8 would not be announced to the internet, but
only routed privately on hamnet.
Now I see routing issues I don't quite understand as for me this looks
like routing is completely broken...
[...]