Some contacts in the CC ------------------------------ John D. Hays K7VE PO Box 1223, Edmonds, WA 98020-1223 <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> <http://www.facebook.com/john.d.hays> On Mon, Jun 16, 2014 at 7:25 PM, Tom Hayward <esarfl@gmail.com> wrote:
On Mon, Jun 16, 2014 at 6:17 PM, Dean Gibson AE7Q <hamwan@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
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org