Megaport Cloud Router (MCR)

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.

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 can request an MCR instance by clicking the ‘Create MCR’ button on the dashboard:

The ‘Select Location’ screen appears. You can 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, register for that market before proceeding to checkout.

When you click Next, the MCR will be placed in your cart; select Check-Out and then Deploy Now to build the MCR instance. The MCR instance will be built in real time and will initially be displayed with a red highlight which changes 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:

KnowledgeBase articles for Amazon Web Services (Direct Connect) and Microsoft Azure (ExpressRoute) via MCR are available and linked separately.

The remainder of this article describes 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 want 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 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 option 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. Some use cases might require multiple inner VLANs exposed to this Port via QinQ/802.1ad and the following options are 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 and it is not detailed in this example.

Setting up a BGP connection

Here 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; 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 ( 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.

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 ( 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 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 ( 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:

BGP SetupPlease 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 onthe 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.

Step by step instructions on how to create a Private VXC between MCR and Megaport:

©2020 Megaport. Megaport, Virtual Cross Connect, VXC and MegaIX are registered trademarks of Megaport (Services) Pty Ltd ACN 607 432 646.

Log in with your credentials

Forgot your details?