On Sun, 14 Jun 2015, Brian Kantor wrote:
Date: Sun, 14 Jun 2015 21:45:44 -0700 From: Brian Kantor Brian@ucsd.edu Reply-To: AMPRNet working group 44net@hamradio.ucsd.edu To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On Sun, Jun 14, 2015 at 08:44:05PM -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.
What you seem to suggest would be to put the SHIM essentially in series with the telescope and have amprgw forward all outbound 44/8 traffic to the SHIM - where some of it would be encapsulated to the various tunnel gateways. If I understand what you're proposing, the traffic to the BGP-routed 44 subnets would travel from the SHIM over the GRE tunnel to the ISPs who would then route it appropriately. All inbound 44/8 traffic which didn't pass the filters would be routed to the telescope. This requires that TWO boxes know about the gateway subnets, as well as having the SHIM learn about the BGP-routed subnets via BGP from the ISP over the GRE tunnel. This seems needlessly complex. It also means that all telescope data has to pass through the SHIM box, which could tax an underpowered box. (I'm not familiar with the SHIM box itself.)
Well the "shim" box is there to run the BGP process and GRE termination since it can't be done on the FreeBSD server. True each box would need to pass along the traffic for the default route going up the drawing. But the BGP part of this would be a fully automated/self updating forwarding of routes. Once routes showed up in the global BGP table they appear in the shim box and just start routing without needing to do anything.
A year or more ago we discussed a scheme where each BGP-routed subnet would simply register a route in the gateways table that pointed to a cooperating router (off the UCSD network) which was capable of decapsulating the tunneled packets and routing them appropriately. This has two advantages: it doesn't require any additional hardware and it doesn't require any changes in the UCSD gateway or network. I don't know how hard it would be to set up a general decapsulator in an existing router, but if it's not too difficult this is a simple step to get where we want to go, don't you think? True, it means that each new BGP subnet would have to register a single entry in the portal, but I don't see that as a hassle. What do you think of this alternative?
I remember that, I setup a tunnel but I don't think anyone did any testing with it. We can try that again. So to recap that idea, that would be a IPIP tunnel from a none UCSD router (Router Z) on the internet to the amprgw server. You would then add the current 53 authorized BGP prefixes as static routes on the amprgw to go over that IPIP tunnel and then egress out to the internet from that router Z location. Router Z would need to allow traffic from any 44 IP Address to egress out router Z's ISP internet connectivity.
RE: "advertise /24 summary routes" The only downside to off loading the IPIP tunnels to a ISP is that the telescope project will lose 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.
In the grand scheme of things, even rounded up to /24s, the total allocated ham radio space is miniscule compared to the unallocated space anyway. I think the researchers already factor this in. I also see the number of tunnel gateways decreasing in future.
- Brian
True, I was just thinking of the children here :)
Tim Osburn www.osburn.com 206.812.6214 W7RSZ