16 Jul
2013
16 Jul
'13
11:18 a.m.
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