14 Jun
2015
14 Jun
'15
11:44 p.m.
On Sun, 14 Jun 2015, Brian Kantor wrote:
Date: Sun, 14 Jun 2015 18:20:22 -0700
From: Brian Kantor <Brian(a)ucsd.edu>
Reply-To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages)
_______________________________________________
On Sun, Jun 14, 2015 at 05:26:26PM -0700, Tim Osburn wrote:
Brian,
I've updated the drawing in response to your private email you sent to
me. Would it be possible to "add" a shim box between the telescope project and
your amprgw server? I think we could still achieve what we're trying to do if
that is something you can do.
RE: "advertise /24 summary routes" The only downside too off loading the
IPIP tunnels to a ISP is that the telescope project will loose out on some
traffic. Example; if a /30 or /32 has been allocated out of a /24 CIDR then the
ISP would need to advertise the whole /24 just for that one small tiny use case.
Where as if you add the shim box then all the traffic outside the allocated
space in that /24 would pass onto the telescope making for better research data.
https://www.osburn.com/amprnet-150614-1.1.0-bgptunnels.jpg
Tim Osburn
www.osburn.com
W7RSZ
This only requires at
least 1 (or more) ISP (or companies running BGP) willing to setup a
BGP over GRE tunnel to Brian's server to make this work. There are
currently two ISP I know of willing to do this if Brian is willing to
do this on the AMPRnet Server shown in the drawing.
I'm willing but not able. The server 'amprgw' is an old FreeBSD system
that doesn't understand GRE. We have been discussing updating it to
a more modern system (both hardware and software) but at this point
it doesn't seem like that's going to happen. We've not been able to
identify ANY router product that can do what the gateway needs to do
in order to replace 'amprgw'.
I have an alternative suggestion, which would be to find an ISP or two
that are willing to take over the IPIP tunnel routing.
They would BGP advertise /24 summary routes for the smaller tunnels, as well
as appropriate routes for the wider tunneled subnets. That way there is
no fixed route that blinds the tunnels to the BGP subnets. UCSD could
still advertise the 44/8 overarching route (which I strongly believe is
essential to preventing prefix hijacks), but since there would be more
specific routes for the BGP and tunnel subnets, that wouldn't matter.
It would only be necessary for the tunneled gateways to change their
tunnel endpoint address -- there is no need for tunneled gateways to
suddenly have to change software or overall configuration.
Flaws?
- Brian 