I really see both of these uses of 44 net as different projects in the same band. Think 440mhz some people do ssb, others FM, while others do SSTV some folks do packet some people do Fast Scan TV. There is not really a need for a 100meg bursting to 1gig connection to interface with a 1200 baud system. Your not going to be able to do much with the content. SIP cant run over 1200baud, you would kill your local lan if you tried to download a 100meg file from an FTP server. I actually think you would want to prevent access to some of what we are going to do.
Now as far as providing an additional de-centralized access to the internet for the tunnels, yes we have said we are happy to help with that in any way and it is really needed. Don't take this the wrong way Brian, but if the big one(earth quake) hits SoCal the whole 44net cant talk to each other anymore. As UCSD is very close to one of the major fault lines in SoCal I would say this is not an if but a when situation. http://en.wikipedia.org/wiki/San_Andreas_Fault
Lin N4YCI
On Tue, Jul 16, 2013 at 11:54 AM, Bryan Fields Bryan@bryanfields.net wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html