-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear YLs and OMs,
I would like to restart the discussion about a decentralized BGP setup for the 44net. I have thought about some kind of trial to test several aspects of a non-central gateway approach.
So far I have come up with a few "challenges" for the trial.
- - AS Number (I can provide one for the trial, we may decide later on what to do if and when this project goes to production) - - IP Network (for the trial the test range 44.128.0.0/16 might be a suitable candidate) - - BGP Peers providing BGP session, bandwidth and a static IP address for the trial (I can provide one peer in LX) - - Inter-Gateway Tunnel setup (which protocol should we use? How do we cope with lowered MTU and filtered ICMP Packet-to-big messages?) - - Downstream tunnels (What kind of tunnel technology/protocols are we offering? Can a subnet have upstream tunnels to several gateways?) - - iBGP setup (How do we handle gateways with different available upstream bandwidth? How do we redistribute routes for connected subnets?) - - Packet filtering (Will we be using the current model of RDNS activates access to/from the Internet? RDNS could be useful even for hosts that shouldn't have access to/from the Internet, eventually access to/from the Internet should be decoupled from RDNS.) - - Test scenarios, how are we going to test different situations? - - probably much more issues to handle (I haven't thought about the details as long as the basics haven't been discussed)
What are your thoughts and who is willing (and able) to help with the trial (as a gateway and/or a subnet tunnel server)?
73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel
On Tue, Jul 23, 2013 at 5:03 PM, Marc, LX1DUC lx1duc@rlx.lu wrote:
What are your thoughts and who is willing (and able) to help with the trial (as a gateway and/or a subnet tunnel server)?
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.
-Neil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/07/2013 19:02, 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.
Great one more OM on board.
I would need explicit details on how this would work and a the potential risks and plans for their mitigation before I approach him.
Very valid point. Out of the box I can think of a few risks (bandwidth usage, # of routes announced, BGP flapping, routing loops, unauthorized announcements, etc) that we need to discuss. This is also one of the reasons I proposed this as a trial using for example 44.128.0.0/16 and not the whole 44.0.0.0/8.
We don't have earthquakes, just tornados and floods :-)
That's another part of the risk analysis but also a reason why multiple gateways might be a good idea.
73 de Marc, LX1DUC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24/07/2013 19:02, Neil Johnson wrote:
Great one more OM on board.
Very valid point. Out of the box I can think of a few risks (bandwidth usage, # of routes announced, BGP flapping, routing loops, unauthorized announcements, etc) that we need to discuss. This is also one of the reasons I proposed this as a trial using for example 44.128.0.0/16 and not the whole 44.0.0.0/8.
That's another part of the risk analysis but also a reason why multiple gateways might be a good idea.
73 de Marc, LX1DUC