[HamWAN PSDR] Internet Maintenance Notification

[Tom Hayward]

On Mon, Jun 16, 2014 at 6:17 PM, Dean Gibson AE7Q <hamwan at ae7q.com> wrote:
> Speaking of outages, there has been no fix (I'm not saying that anyone in
> HamWAN is at fault) for the loss of connectivity to 44.x.x.x nodes in (for
> example) Germany, for almost a week.  This isn't urgent, but where's the
> best place to escalate that to, 44net???

Dean,

I'm not sure how closely you follow the 44net mailing list, but we're
sort of at an impasse with our AMPR gateway. Here's an explanation of
the issue with a lot of background.

IPv4 addresses are scarce, and the organization that has offered
HamWAN free IPv4 address space for use on the Internet is AMPR. These
happen to be addresses from the 44.0.0.0/8 network, and we use various
subnets within this block. 44.24.240.0/20 is our primary network and
is accessible from the internet.

Most AMPR networks are not fortunate enough to have upstream providers
that let them announce their own address space on the Internet, so
they use gateways to tunnel 44.x.x.x packets between AMPR subnets. A
list of AMPR subnets and their gateways is published, and gateway
operators must keep their gateways in sync with this list. Even though
we are accessible from the internet without tunnels, we have to host a
tunnel gateway so that these networks can talk to us using 44.x.x.x
source addresses. We use another AMPR address, 44.24.221.1, as our
AMPR gateway. We announce this, too, so that anyone with Internet
service can access this gateway. Our gateway's subnet, 44.24.221.1/24,
is not listed as an AMPR route, so routing to 44.24.221.1 should fall
onto their default route from their ISP.

Unfortunately, there are some popular AMPR configuration scripts that
use a shortcut to make their routing simpler: they hard code a route
44.0.0.0/8 via UCSD. This hard-coded route gets priority over the
default route, so packets to our 44.24.221.1 gateway get forwarded to
UCSD, instead of through the default internet path. This is wrong.

You might ask, why can't UCSD just send the packet our way? It turns
out UCSD also has some routers with hard-coded 44.0.0.0/8 routes
pointing away from the Internet.

The solution is two-fold:
1. Avoid relying in UCSD whenever possible. The current AMPR design
does this by creating tunnels directly between every AMPR gateway.
2. Don't hard code routes. Get all routes from automatic routing
protocols or, when necessary, the route file distributed by AMPR.

In the case of your loss of connectivity to German sites, we see the
packets leave our network and never come back. This looks to me that
they have a routing issue on the return path, very likely the problem
I describe above. All six of the "broken" examples you gave use
141.75.245.225 as a gateway, so I'd start there.

Tom KD7LXL