17 Jun
2015
17 Jun
'15
2:48 p.m.
Subject:
Re: [44net] AMPRNet Interoperability with BGP
From:
Brian Kantor <Brian(a)UCSD.Edu>
Date:
06/17/2015 08:01 AM
To:
AMPRNet working group <44net(a)hamradio.ucsd.edu>
On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote:
The reason (1 and 2) is that for a typical system that has both a public IP and an
AMPRnet
IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet
IP to be reachable from public IP addresses on internet.
Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet
traffic is to go out via the IPIP tunnels.
When such a system is on a source-address filtered internet connection, the default route
for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh
system
that has unfiltered internet access. Typically the system at UCSD.
It is preferred that the varying gateway systems are configured only via RIP (usually in
a
separate route table), and that it is not required to make specific policy routing
configuration for
gateways. So the policy routing is static for 44.0.0.0/8.
This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed
by
the routing policy (which is used both for the actual traffic and the encapsulated
packets).
When people see a way around that (I don't completely oversee if Jann's suggestion
will
achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please
see
the example configuration for Linux systems in the wiki and suggest a way how that could
be made working without manual "ip rule" entries dedicated to specific gateways.
Or else,
those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine
as well.
Aside from that, of course it should still be validated that tunnel endpoints are not
within
the subnet being tunneled (3). That is simply an error condition. There were some
networks
that were claimed to be reachable via a tunnel at their first address (Sweden, for
example)
and there were some entries with tunnel endpoint == tunneled address. The portal should
refuse that so that applicants are made aware of their error before such entries are
broadcast
via RIP and result in encapsulation loops.
Rob
>Good question! No, a change to the portal
around the same time
>prohibits adding 44.xx.xx.xx addresses as gateways. I believe there
>was some noise on this list about it at the time.
That change was made
because
1) it was reported that 44.x gateway addresses didn't work
2) it was reported that 44.x gateway addresses caused problems
3) people were entering 44.x gateway addresses for their IPIP tunnels
instead of the proper commercial IP address of the endpoint.