16 Jul
2013
16 Jul
'13
10:54 p.m.
On 7/16/13 11:00 AM, Brian Kantor wrote:
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.
Admittedly, I've been a bit tardy in getting my BGP
session up with my
provider (summer is always busy for me), but perhaps there is a better way to
do this.
What I envision would be to have a few regional AMPR BGP routers/peering
points. AMPR would need and ASN of course (I'd be willing to put up the money
for this from ARIN), some hardware and a few friendly providers across the
globe. I have one friendly provider, and I'm sure we could find a few more.
Hardware is up to us, I'd prefer an actual router (ALU/Cisco/JNPR), but there
is no reason openbgpd on a *nix box wouldn't work.
So you would have each peering point announcing 44/8 but behind the peering
routers would be a set of (GRE) tunnels between all the routers. The 44net
BGP routers would run I-BGP across these tunnels (or ISIS/OSPF, but I feel
IBGP would make more sense to manage redistribution of routes as it's got more
"policy knobs" than OSPF and to a lessor extent ISIS.) The 44net non bgp
users would then have IP-IP tunnels to their closest 44net peering router.
For optimized routing (as it makes no sense to me for .AU users to tunnel
through UCSD) we could have routing between the 44net routers announce more
specific routes for directly connected subnets. We'd have to manage this, as
I'm sure we don't want to add another 1000 routes to the global table (and
then have filtering), but I don't see it being that many routes when a /16 is
for a whole continent, which has 1 or 2 peering routers in this design. This
also avoids black holes caused by 44net directly connected peers being
filtered by sites that filter at less than a /24 block (don't laugh, I've seen
large companies filter at a /19)
Admittedly this is a very "back of a napkin" design, but it's a start.
Thoughts?
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net