To me, the reason for having more than one peering point is not only to avoid a singular point of failure, but also all sorts of performance and security issues. Besides robustness, it is about keeping local traffic local. There should be a route between all amprnet addresses in different non-directly connected subnet islands, either via Internet, if the spaces of the different islands are only announced via eBGP, or via intranet links on a per network level, tunnels or direct links whatever, in which case border routers should inform each other via iBGP and all be encap/decap-capable to satisfy anti-spoofing filters. As long as this is properly managed to avoid routing loops, asymmetric routing, etc, we should be able to mix them if there is a reason to do so. I would be prepared to participate in tests of schemes for this if anyone is interested. I am also keeping my eyes open for opportunities of having direct intranet links to other ampr islands.
On 07/16/2013 05:00 PM, Brian Kantor wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jul 16, 2013 at 04:48:57PM +0300, Heikki Hannikainen wrote:
Also, doesn't amprgw at UCSD drop net-44 packets on the floor unless they're in encap.txt? Or is there an exception for BGP announced networks?
We would drop them since they're not in the encap database, but they don't show up here from the Internet in the first place since the narrower BGP subnets override the larger /8 network and the packets aren't routed here.
It'd be really unfortunate if the BGP sites would be only accessible from the Internet and not from the rest of the amprnet.
That's a choice the BGP-announced subnets have to make. In order to avoid the amprgw connection point as a single point of failure they have chosen to make themselves individual connection points, with all that entails.
44net-only tunnel-connected hosts HAVE to route back to the Internet through amprgw because of the anti-spoofing filters in place on most of their providers' networks, and once the packets are here and decapsulated they're treated as any other packets, which means that if the destination is one of the BGP-routed ("directly-connected") 44net subnets that isn't also participating in the tunnel mesh, the traffic has to flow over the commercial Internet to get there.
I've long thought that tunnels were about the only way to go for internal connectivity in the AMPRNet, but as it's an experimental network and people were getting rather shrill about allowing directly-connected subnets, I figured we might as well try it.
The question reduces to one of internal versus external connectivity.
A solution would be to have the border router at each of the directly-connected subnets also have a full set of tunnel routes and interfaces installed, as it could then participate in the tunnel mesh and should then be in the encap file. I don't see commercial internet providers doing that.
So this means that in order for the the directly-connected subnets to also participate in the tunnel mesh, there has to be a tunnel-enabled router downstream of the connection to the commercial Internet. Thus the only advantage of being directly-connected is simply an independent (quite possibly higher-bandwidth) connection to the commercial Internet backbone. It doesn't improve internal connectivity in the AMPRNet at all. We still need the tunnels for that.
- Brian