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:
I'm a network engineer at another University in
the midwest US and I
*might* be able to convince our routing guru to let us be a BGP peer
and I could setup another tunnel end point box.
I would need explicit details on how this would work and a the
potential risks and plans for their mitigation before I approach him.
We don't have earthquakes, just tornados and floods :-)
No promises however.
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