[HamGateNY] Fwd: Re: [44net] Routing of 44.0.0.0/8 how are routes announced to users?

Charles J. Hargrove n2nov at n2nov.net
Sat Feb 24 07:05:16 EST 2018


A very good explanation of 44Net routing from the gatekeeper himself.


-------- Forwarded Message --------
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

_________________________________________
44Net mailing list
44Net at mailman.ampr.org
https://mailman.ampr.org/mailman/listinfo/44net


-- 
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.

NYC-ARECS/RACES Nets 449.025/123.0 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM
http://www.nyc-arecs.org

NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32

"Information is the oxygen of the modern age. It seeps through the walls 
topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan

"The more corrupt the state, the more it legislates." - Tacitus

"Molann an obair an fear" - Irish Saying
(The work praises the man.)

"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan




More information about the HamGateNY mailing list