action.skip
Megaport Documentation
Resizing or Moving an MCR
Copy for LLM ▼
Copy Page Content Open in ChatGPT Open in Claude Open in VS Code View Markdown
PDF

Resizing or Moving an MCR

This topic describes how to resize a Megaport Cloud Router (MCR) to a different rate limit or move an MCR to a different data center within the same metro. Because the MCR rate limit is fixed for the duration of the service and you cannot change its location, both operations require creating a new MCR and migrating your Virtual Cross Connects (VXCs) to the new instance.

The Move VXC feature transfers VXCs from one MCR to another within the same metro without recreating them. For more information, see Moving VXCs.

When to resize or move an MCR

Common scenarios for resizing or moving an MCR include:

  • Upgrading capacity – Your bandwidth requirements have grown beyond the current MCR rate limit.
  • Downsizing – Your traffic has decreased and you want to reduce costs by moving to a smaller rate limit.
  • Data center migration – Moving to a different data center within the same metro for improved latency, diversity, or other operational reasons.
  • Diversity requirements – Deploying MCRs in different diversity zones to improve resilience. For more information, see MCR Diversity.

Before you begin

Before starting the migration, gather the following information about your existing MCR:

  • Current configuration – The MCR ASN, BGP default state, and any service level reference numbers.
  • VXC inventory – Document all VXCs connected to the MCR, including their rate limits and VLAN assignments.
  • BGP configuration – All BGP peer configurations, including peer IP addresses, peer ASNs, and BGP passwords.
  • Route filters – Export or document any prefix filter lists and BGP peer filters configured on the MCR.
  • Packet filters – Any packet filter lists configured on the new MCR.
  • Static routes – Any static routes configured on the MCR.
  • IP addressing – Interface IP addresses for each VXC.

Note

Prefix filter lists and packet filter lists are transferred between MCRs when you move VXCs. The MCR name, ASN, and BGP Default State must be configured on the new MCR; all other VXC configuration is transferred automatically during the move.

Tip

You can obtain this information from the Terraform configuration file if you are using Terraform, or your preferred AI tool. For more information, see Creating a Megaport Terraform Provider Configuration File and Megaport MCP Server Overview.

Planning the migration

Preparation steps

  1. Verify VXC eligibility – Confirm that your VXCs can be moved. VXCs can only be moved between services of the same type within the same metro. For the full list of conditions, see Conditions for moving a VXC.

  2. Plan IP addressing – Determine whether you will maintain the same IP addressing scheme on the new MCR. The interface IP addresses are configured per VXC and transferred with the VXC when moved.

  3. Document the configuration – Use the MCR Looking Glass to capture your current routing state before migration. For more information, see Viewing Traffic Routing through MCR Looking Glass.

  4. Coordinate with Cloud Service Providers (CSPs) - If your MCR connects to CSPs, review any provider-specific requirements that might affect the migration.

  5. Schedule a maintenance window - Moving VXCs will cause a brief traffic interruption as the connection is transferred to the new MCR.

Understanding outage expectations

When you move a VXC from one MCR to another:

  • Traffic interruption – Traffic stops flowing through the VXC during the move. The VXC briefly goes offline and then comes back online on the new MCR. The interruption typically lasts from a few seconds to a few minutes, depending on provisioning times and routing configuration.

  • BGP session reset – BGP sessions drop during the move and re-establish after the VXC is live on the new MCR. Recovery time depends on your BGP timer configuration and the number of routes being exchanged.

  • Cloud provider VXCs – Connections to CSPs such as AWS, Azure, and Google Cloud experience the same brief outage. BGP sessions drop and re-establish after the move.

Plan to move VXCs during a scheduled maintenance window when a brief traffic interruption is acceptable.

Migration workflow

Step 1 – Create the new MCR

Create a new MCR with your required configuration:

  1. Create the MCR with the new rate limit or in the new data center location.
    For more information, see Creating an MCR.

  2. Configure the same ASN as your existing MCR to maintain consistent BGP identity, or use a different ASN if required.

    Note

    The new MCR can use a different ASN from the existing MCR if all VXCs are configured with a local-as value. In this scenario, BGP peers continue to see the local-as configured on the VXC rather than the MCR ASN. All VXCs must have local-as configured for this approach to work.

  3. Set the BGP Default State to Shut Down if you want to preconfigure BGP sessions before enabling route exchange.

Note

We recommend setting the BGP Default State to Shut Down on the new MCR. This prevents BGP sessions from establishing during VXC migration before routing policies and filters are applied, reducing the risk of unintended route advertisements, particularly to CSPs with route limits or quotas. You can choose a different approach if appropriate for your environment.

Step 2 – Move VXCs to the new MCR

Move your VXCs from the old MCR to the new one:

  1. In the Megaport Portal, go to the Services page and select the original MCR.

  2. Click the Move Connections icon.

  3. Select the VXCs you want to move.

  4. Select the new MCR as the destination in the Move To area.

  5. Review your selections and click Move, then Confirm.

For more information, see Moving VXCs.

Tip

You can move multiple VXCs at once. Consider whether to move all connections simultaneously for a single maintenance window or move them in phases.

Step 3 – Check filters and verify BGP

After moving each VXC:

  1. Edit the VXC on the new MCR and confirm that any prefix filter lists and packet filter lists were successfully moved to the new MCR.

  2. If you set the BGP Default State to Shut Down, enable the BGP sessions.

  3. Verify that BGP sessions establish successfully by checking the BGP status in the VXC configuration or the MCR Looking Glass.

For more information, see Configuring an MCR.

Step 4 – Verify routing and connectivity

After moving VXCs:

  1. Open the MCR Looking Glass for the new MCR.

  2. Verify that BGP sessions show as established (green check mark).

  3. Check the routing table to confirm expected routes are present.

  4. Verify that routes are being advertised and received correctly by viewing neighbor routes.

  5. Test end-to-end connectivity through the new MCR.
    You can use the MCR Looking Glass or ping and traceroute tests to verify traffic is flowing correctly through the new MCR.

For more information, see Viewing Traffic Routing through MCR Looking Glass and Troubleshooting an MCR Routing Issue.

Step 5 – Terminate the old MCR

After all VXCs have been moved and verified on the new MCR:

  1. Confirm that no VXCs remain on the original MCR.

  2. Terminate the old MCR.
    For more information, see Terminating an MCR.

Note

Terminating an MCR on a contract term will result in an early termination fee (ETF) equivalent to 100% of the remainder of the term. For more information, see MCR Pricing and Contract Terms.

Helpful references