[HamWAN PSDR] Internet Maintenance Notification

[John D. Hays]

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 at gmail.com> wrote:

> 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
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140616/0a7d00f5/attachment.html>