The existing mesh of tunnel routes is no problem to maintain. Setting up the gateway involves setting up the initial encapsulation tunnel routes. Whether that list contains one tunnel or 2 or 200 or 2000 doesn't really matter. In other words, the number of tunnels does not change the configuration complexity. I certainly don't think it's a good idea to route every internal connection through some centralized gateway somewhere, even if more than one exists. It puts a failure point between me and my destination and it degrades the performance into and out of that gateway. Yes, it increases physical diversity, but it also depends on iBGP and multiple network managers doing the right thing. So removes some failure modes while introducing others. It also makes troubleshooting more of a problem. Today, if I can't reach another gateway, I talk to the person directly. If everything goes through some other point, there's a third location to test with. That would be impractical. I DO think it's important to have more than one Internet gateway. However, I'm not sure how well JNOS can handle an alternate route. For example, is it able to discover if one of the tunnels is down and switch to the alternate? Can it deal with two equal cost paths or will we need to cost them differently? Currently, we can't even tell if our tunnel to amprgw is up because it won't respond to pings to 44.0.0.1 from another 44.x address. Michael N6MEF -----Original Message----- From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Bryan Fields Sent: Wednesday, July 24, 2013 11:07 AM To: AMPRNet working group Subject: Re: [44net] Distributed BGP Announce (Please trim inclusions from previous messages) _______________________________________________ On 7/24/13 1:02 PM, Neil Johnson wrote: We have really two networks here. The internal 44-net and the external internet facing net. I'd propose to have a few points around the globe where we can peer the whole 44 internet facing net. Each of these locations would announce 44/8 and more specific routes for what's close to them. Behind this in the 44-net internal the gateway routers would be meshed over GRE tunnels running an IGP (IS-IS). There of course would need to be IBGP sessions between all the BGP speakers, but this would allow end user networks to tunnel to a given 44/net router, and not need to keep a full route table of the 44-net internal space. (I hate end stations needing to do routing, that's why we have routers!) This would provide full access to the 44/net from outside, easy access from the AMPR users, and full visibility between directly routed netblocks and the rest of 44-net with out having to maintain a full mesh. I'd imagine the more specific announcements from the peering points would be statically configured, but there is a way to do a limited redistribution from the IGP into the BGP. I think it would be easier to do it manually (and more stable), but given some time in the lab at work I could get this going. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

How would local gateways connect ? A Tunnel(s) to the global gateways ? I'm trying to imagine explaining to someone how to configure an IGP (especially IS-IS) :-) -Neil On Wed, Jul 24, 2013 at 1:06 PM, Bryan Fields <Bryan(a)bryanfields.net> wrote: -- Neil Johnson -N0SFH http://erudicon.com