Introduction to Megaport Cloud Router (MCR)
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 across the worldwide Megaport Network 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 Megaport or MCR.
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 multicloud 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.
Ordering a MCR
Follow the detailed step-by-step instructions here and watch the 7-minute video tutorial at the bottom of this page.
You simply need to visit the 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 given instance and is available at 2.5 Gbps, 5 Gbps, and 10 Gbps. Charging rates (per monthly values) will be displayed based on location and rate limit.
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).
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.
Step by step instructions on how to create a MCR:
Attaching Services/VXCs to your MCR Instance
Once you’ve successfully checked out your MCR instance, it will become available on your dashboard. As with a Megaport, you may use the ‘+Connection’ item to add a VXC. Or, if there are currently no services attached to your MCR instance, you may select one of the quick target destinations as shown below:
The remainder of this article will describe adding a VXC to an existing physical Port instance and the options that can be specified.
After clicking the ‘+Connection’ button on the specific MCR that you wish to connect to the physical Megaport, you will be presented with the connection target selection screen as per the below ‘1) Select Type’ screen:
In Step ‘2) Select Port’, you will be presented with a list of all ‘ self-owned’ Ports, or Megaport targets and MCRs, that are local to the current company’s account. In the instance below, the ‘DemoPort’ Port will be selected. Please note that the logos are different for physical Ports versus MCRs:
Step ‘3) Connection Details’ requests some basic information in order to configure the speed and displayed data for the requested VXC. Once again, the ‘Name Your Connection’ field is the name that will be displayed on the Megaport dashboard and ‘Rate Limit’ is the speed of the VXC expressed in Mbps. Please note that the maximum value will be calculated from the smallest of the two endpoints involved in the connection (MCR or physical Port in this case).
‘Preferred B-End VLAN’ is also configurable to specify the dot1q VLAN tag that will be applied at the target Megaport end. If it is left blank, one will be selected and configured automatically:
Step ‘4) MCR A End’ is where specific details relating to the Layer 3 routing requirements are set up and will be covered in detail below:
MCR Configuration Options
QinQ Connection/Not QinQ Connection (toggle): This selection item allows either a single VLAN (non-QinQ/802.1q) or multiple/dual-stacked VLANs (QinQ/802.1ad) to be carried over the given VXC. In most cases, a single VLAN would be used and would be exposed on the target physical Port as a trunked Port instance allowing this Port to contain multiple VXCs to destinations other than the MCR being configured here. For certain use cases, however, it may be required to have multiple inner VLANs exposed to this Port via QinQ/802.1ad. The below options will be available for individual configuration for each sub-VLAN/C-TAG if this option is configured as QinQ capable.
BGP Connections: This option should be used where dynamic route table updates are to be propagated from the MCR instance across the VXC to the given Port. Selection of this option where the device connected to the physical Port is BGP capable would be preferred to allow automatic updates of any route table changes in downstream VXCs from a given MCR without manual intervention.
Static Routes: This option would generally be used in place of BGP connections where a customer device is not capable of speaking BGP or the target device requires known, manually configured addressing and routes.
NAT IP Addresses: If ‘Network Address Translation’ is required for a given connection (either for static or dynamic/BGP routing), it can be configured in this tab. Generally, this will be used for public/private NAT or inter-customer isolation so it is not detailed in this example.
Setting up a BGP connection
Below is an example of a worked configuration that, for this MCR/Megaport VXC, will result in a BGP session target being configured on the host MCR routing instance:
The mandatory ‘IP Addresses’ field is the key to populating the data in this panel. The IP addressing should be entered in CIDR format and, though you may have multiple ranges, they must not overlap. In this example, the range that has been configured is 10.10.10.10/31; for BGP connectivity, the /31 (2 x IP addresses) would be the minimum size range that would be configured as both a local (MCR side) and peer (target side) address. Once the IP range (10.10.10.10/31) is input and accepted (by clicking the blue ‘+’ button), a small trash can icon will appear –this is used if you input the wrong data or want to delete that particular CIDR entry.
A new BGP connection (1) tab is then opened by clicking the blue ‘+’ icon in the ‘BGP Connections’ area. Please note that, once this is done, the counter will change from 0/10 to 1/10 (number of this type of config/maximum number supported), therefore, it is possible to have multiples of each type of configuration per VLAN.
In the instance above, all fields are mandatory with the exception of the BGP Authentication/MD5 key. ‘Local ASN’ is the AS number that will be configured on the MCR instance for this connection and, in this example, the value 133937 has been chosen as this is the ‘native MCR AS’ registered to Megaport that can be used for all MCR connections. Should you wish to use your own public AS number, or choose to use a private ASN (e.g. 64512 – 65534), this is also supported and can be configured here. The above is also true for the ‘Peer ASN’ value – this is the AS number that will need to be configured on the target routing device to appropriately terminate the BGP connection.
Please note that, in this case, the ‘Local IP’ is selected via a pull-down field which is populated from the IP addresses input before commencing this configuration step. If there are multiple available CIDR ranges, these will all be available for selection but it is mandatory to have first input the address ranges and for the associated peer IP to be within this range. In this example, the next available IP within the /31 range (10.10.10.11) has been manually input into the ‘Peer IP’ field – this is a manual/freeform text entry field – however, it should also be entered in CIDR notation format.
Using a CIDR calculator tool such as Subnet-Calculator.com will ensure that all data input will be valid and within range:
Once the above connection was accepted and checked-out completely, it would then build the configuration onto your MCR towards the selected physical Megaport. The next steps would be to configure the peer IP (10.10.10.11/31) on the physically-connected router (having ASN 65001), which is connected to the physical Megaport, and also tell it to establish the BGP session with remote peer ASN 133937 as per the following example:
Please note that this information is general in nature only and each customer routing device will be configured differently. Please consult your documentation/vendor for specific requirements on your equipment.
When this connection is live, you may view the BGP status (up/down) from the MCR perspective by clicking on the VXC connection in the Portal dashboard and visiting the ‘Details’ tab:
Confirming the same (BGP up) status from the physically-connected device should also be the next step in commissioning a connection as well as interrogating the routes that are being received via this connection. Any other VXCs that are connected to the MCR, that this service is attached to, will now automatically propagate routes across this link.