Introduction to Megaport Cloud Router (MCR) – Release 2.0
Megaport Cloud Router (MCR) is a Layer 3 capable product offering that provides a routing capable virtual instance on the Megaport Network.
Features of MCR
Megaport Cloud Router (MCR) instances can be set up in various locations across the Megaport Network worldwide and are physically homed to one of the Megaport core locations. It is important to note that an MCR instance is not physically cross-connected as a standard Megaport would be although, like a physical Megaport, it can host Layer 2 VXC connections which may extend to any other physical Megaport or Cloud Service Provider.
An MCR instance may be used either with or without a physical Megaport connection. If you are looking at multi-region deployments (with a single CSP) or multi-cloud deployments (with multiple CSPs), MCR will enable these functionalities. Likewise, if you combine the MCR functionality with a current or new physical Megaport, you may derive benefits such as reduced latencies for inter-region or inter-cloud connectivity combined with connecting to a physical Port.
Major changes in v2.0 MCR product offering from v1.x (previous 7 speed-tier offering)
- Three speed tiers, capable of 2.5Gbps, 5Gbps or 10Gbps (asymmetric) routing throughput, or 1.25/1.25Gbps at 2.5Gbps tier, 2.5/2.5Gbps at 5Gbps tier and 5/5Gbps at 10Gbps tier for symmetric routing throughput
- Addition of Bidirectional Forwarding Detection (BFD) option for BGP per attached VXC
- Addition of Multiple Exit Discriminator (MED) value options for BGP per attached VXC
- Addition of user-controlled BGP on/off toggle per attached VXC
Ordering an MCR
Follow the detailed step-by-step instructions here and watch the video tutorial at the bottom of this page.
You simply need to visit the Megaport Portal to order an MCR instance. Once you have logged in (and have an active ordering account via completing the Company and Market registrations sections), you will be able to request an MCR instance by clicking the ‘Create MCR’ button as detailed below on the dashboard.
This will bring up the ‘Select Location’ screen as per below. You may filter by country to see the MCR locations available or scroll through the entire list.
Completing New MCR Form Fields
Rate Limit: This specifies the overall ‘throughput limiter’ for the asymmetric routing maximum of the instance and is available at 2.5Gbps, 5Gbps and 10Gbps options. Charging rates (per monthly values) will be displayed underneath the ‘Next’ button based on location and rate limit. Note: Throughput figures are based on an lMIX workload (see: https://en.wikipedia.org/wiki/Internet_Mix), using other traffic mixes may result in performance attainment at less than these maximum values.
MCR Name: This is the ‘friendly name’ that will be displayed for the given MCR in your Portal dashboard.
Invoice Reference: If you have a specific billing identifier that you require to be added to your invoices, please input this here (note: this is not a mandatory field).
MCR ASN: This can be populated with an ‘override’ value of your choosing, should you hold a public ASN and wish to reflect this for the MCR routing domain in all BGP advertisements. Otherwise, if you don’t hold an ASN and/or wish to use the Megaport default, you may keep this value at 133937.
Please also note that you will only be able to create MCR instances in billing markets that you have registered in. To create an MCR in a different market, please register for that market before proceeding to checkout.
Once you click ‘Next’, the MCR will be placed in your cart; select ‘Check-Out’ and then ‘Deploy Now’ to proceed with building the MCR instance. The MCR instance will be built in real time and will initially be displayed with a red highlight which will change to green once it is fully available.
Bidirectional Fowarding Detection (BFD) is a protocol that may be enabled to provide fast forwarding path failure detection times, allowing for a faster BGP routing re-convergence time. It is best practice to enable BFD for fast link failure detection and failover when connecting to services that support BFD on the remote peer. Enabling BFD for your VXC connection allows a Border Gateway Protocol (BGP) neighbour relationship to be torn down quickly after notifications from BFD, failing over to another BGP neighbour on the MCR or via an alternative path such as VPN tunnel. If not enabled, this failover will only occur after the default BGP timer interval which is generally three keep-alive window failures of 60 seconds each.
- BFD is supported natively by AWS Direct Connect connections:
Asynchronous BFD is automatically enabled for AWS Direct Connect virtual interfaces on the cloud service provider side. However, you must configure MCR VXCs to AWS Direct Connect for BFD to enable it for your connection. The AWS BFD liveness detection minimum interval is 300 ms and the multiplier is three. Support may be provided for other peers outside of the above, however you will need to confirm this with your CSP as well as specific default values.
- BFD is supported natively by Azure ExpressRoute on private peering:
BFD is configured by default under all the newly created ExpressRoute private peering interfaces on the MSEEs. However, you must configure MCR VXCs to Azure ExpressRoute private peering for BFD to enable it for your connection. Between BFD peers, the slower of the two peers determine the transmission rate. MSEEs BFD transmission/receive intervals are set to 300 milliseconds. In certain scenarios, the interval may be set at a higher value of 750 milliseconds. By configuring higher values, you can force these intervals to be longer; but, not shorter. (Microsoft Docs)
Addition of Multiple Exit Discriminator (MED) values – Option
A BGP Multiple Exit Discriminator (MED) value provides a dynamic way to influence a connected BGP peer Autonomous System (AS) in the way to reach a certain route when there may be multiple entry points for that connected AS. BGP will follow a systematic procedure for choosing the best path. Other BGP attributes such as weight, local preference, originate route, and AS path that will be taken in to account before considering the MED attribute. When all other factors are equal, the exit point with the lowest MED is preferred.
- Google Cloud Platform Cloud Router egress is determined by the first condition that is met:
All egress traffic is sent to the route with the shortest AS path length. If routes have the same AS path lengths, all egress traffic is sent to the one with the lowest Multi-Exit Discriminator (MED) value (the lowest route metric). If routes have the same AS path lengths and MED values (the same route metrics), egress traffic is balanced across all routes by using Equal-cost multi-path (ECMP). Support may be provided for other peers outside of the above, however you will need to confirm this with your CSP and any specific routing metric influence options that may have a higher priority than MED.