MCR Routing — Megaport CLI

The Megaport Cloud Router (MCR) is a virtual Layer 3 router hosted in the Megaport fabric. It lets you route traffic between clouds and sites using BGP — without deploying physical router hardware. This tutorial provisions an MCR, attaches cloud VXC spokes, and configures prefix filter lists to control route advertisement.

What MCR enables

Without MCR, each cloud connection requires a direct VXC between two specific endpoints. With MCR as a transit hub:

AWS ↔ Azure traffic stays on the private Megaport fabric (avoiding cloud egress charges)
On-premises connects once to MCR and reaches all clouds through BGP
Prefix filter lists give you per-cloud route control without touching BGP configs on each cloud side

Architecture

🔌PortNextDC S1 Sydney

⚡VXC

🌐MCRASN 64512 · 5 Gbps

⚡VXCsto each cloud

☁️AWS / Azure / GCPDirect Connect · ExpressRoute · Interconnect

Step 1 — Provision an MCR

Interactive

bash

megaport-cli mcr buy --interactive

Flags

bash

megaport-cli mcr buy \
  --name "Cloud Router SYD" \
  --location-id 3 \
  --port-speed 5000 \
  --term 12 \
  --marketplace-visibility false \
  --mcr-asn 64512

JSON file

bash

megaport-cli mcr buy --json-file ./mcr-config.json

Example mcr-config.json:

json

{
  "name": "Cloud Router SYD",
  "locationId": 3,
  "portSpeed": 5000,
  "term": 12,
  "marketPlaceVisibility": false,
  "mcrAsn": 64512
}

Parameter reference

Parameter	Values	Notes
`--port-speed`	1000, 2500, 5000, 10000, 25000, 50000, 100000 Mbps	Total throughput capacity
`--mcr-asn`	64512–65534 (private) or public ASN	Auto-assigned private ASN if omitted
`--marketplace-visibility`	true / false	`false` = private, not listed to other customers
`--diversity-zone`	e.g. `blue`, `red`	For redundant MCR pairs at the same location

💡

ASN selection

Use a private ASN (64512–65534) unless you have a registered public ASN and plan to peer publicly. Private ASNs work fine for all cloud provider BGP sessions.

Step 2 — Verify MCR provisioning

bash

# Full MCR details
megaport-cli mcr get <MCR-UID>

# Just the provisioning status
megaport-cli mcr status <MCR-UID>

# See it in your list
megaport-cli mcr list

The MCR starts as CONFIGURED and transitions to LIVE once fabric provisioning completes.

Step 3 — Attach VXC spokes

The MCR is the A-End for all cloud VXC connections. Each cloud gets its own VXC.

VXC to AWS Direct Connect

bash

megaport-cli vxc buy \
  --name "MCR → AWS Direct Connect" \
  --a-end-uid <MCR-UID> \
  --b-end-uid <AWS-PARTNER-PORT-UID> \
  --a-end-vlan 100 \
  --rate-limit 1000 \
  --term 12 \
  --b-end-partner-config '{"connectType":"AWS","ownerAccount":"123456789012","type":"private","asn":65000}'

VXC to Azure ExpressRoute

bash

megaport-cli vxc buy \
  --name "MCR → Azure ExpressRoute" \
  --a-end-uid <MCR-UID> \
  --a-end-vlan 200 \
  --rate-limit 1000 \
  --term 12 \
  --b-end-partner-config '{"connectType":"AZURE","serviceKey":"your-expressroute-service-key"}'

For Azure, the partner port is auto-discovered from the serviceKey. AWS, Google, and Oracle require an explicit --b-end-uid (the partner port UID from partners list).

Use a different VLAN for each VXC on the MCR A-End. See the Connect to AWS and Connect to Azure tutorials for full cloud-side setup.

Step 4 — Manage BGP prefix filter lists

Prefix filter lists let you control which routes the MCR advertises over each BGP session — without modifying configurations on the cloud side.

bash

# Permit only RFC1918 private ranges — deny everything else
megaport-cli mcr create-prefix-filter-list <MCR-UID> \
  --description "Allow RFC1918 only" \
  --address-family IPv4 \
  --entries '[
    {"action":"permit","prefix":"10.0.0.0/8"},
    {"action":"permit","prefix":"172.16.0.0/12"},
    {"action":"permit","prefix":"192.168.0.0/16"},
    {"action":"deny","prefix":"0.0.0.0/0"}
  ]'

More specific filtering with ge/le

Use ge (greater-than-or-equal) and le (less-than-or-equal) to match a range of prefix lengths:

bash

# Permit 10.0.0.0/8 but only for /16 through /24 subnets
megaport-cli mcr create-prefix-filter-list <MCR-UID> \
  --description "10.x subnets /16-/24 only" \
  --address-family IPv4 \
  --entries '[{"action":"permit","prefix":"10.0.0.0/8","ge":16,"le":24},{"action":"deny","prefix":"0.0.0.0/0"}]'

Prefix filter entry fields

Field	Required	Description
`action`	Yes	`"permit"` or `"deny"`
`prefix`	Yes	CIDR notation (e.g. `10.0.0.0/8`)
`ge`	No	Minimum prefix length to match (greater-than-or-equal)
`le`	No	Maximum prefix length to match (less-than-or-equal)

ℹ️

Address family is immutable

The --address-family (IPv4 or IPv6) cannot be changed after creation. Create separate lists for IPv4 and IPv6 routes. Entries inherit the address family of the list.

💡

Always end with a deny

Include {"action":"deny","prefix":"0.0.0.0/0"} as the last entry to ensure a default-deny. Without it, unmatched prefixes may pass through.

Inspect and manage lists

bash

# List all prefix filter lists on this MCR
megaport-cli mcr list-prefix-filter-lists <MCR-UID>

# Get details on a specific list (including all entries)
megaport-cli mcr get-prefix-filter-list <MCR-UID> <LIST-ID>

# Update entries on an existing list (replaces all entries)
megaport-cli mcr update-prefix-filter-list <MCR-UID> <LIST-ID> \
  --entries '[{"action":"permit","prefix":"10.0.0.0/8","ge":16,"le":32},{"action":"deny","prefix":"0.0.0.0/0"}]'

# Delete a list
megaport-cli mcr delete-prefix-filter-list <MCR-UID> <LIST-ID>

Step 5 — Inspect BGP and routing with Looking Glass

Once VXC spokes are attached and BGP sessions are up, use the MCR Looking Glass to confirm peer state and inspect what the MCR is actually receiving and forwarding. All Looking Glass commands are read-only.

Confirm BGP sessions are up

bash

megaport-cli mcr looking-glass bgp-sessions <MCR-UID>

Example output:

text

SESSION ID  NEIGHBOR ADDRESS  NEIGHBOR ASN  LOCAL ASN  STATUS       UPTIME      PREFIXES IN  PREFIXES OUT  VXC NAME       DESCRIPTION
sess-001    169.254.10.1      65000         64512      ESTABLISHED  00:42:13    42           7             MCR → AWS     primary peer
sess-002    169.254.20.1      12076         64512      ESTABLISHED  00:38:47    18           5             MCR → Azure   primary peer

Save the Session ID — bgp-neighbor-routes takes it as a positional argument. If a session shows IDLE, ACTIVE, or OPENSENT long after provisioning, BGP isn't completing — re-check the peer IP, ASN, MD5 password, and any prefix filter on the cloud side.

See what the MCR is learning over BGP

bash

# Every BGP-learned route from every peer
megaport-cli mcr looking-glass bgp-routes <MCR-UID>

# Filter JSON output to a specific peer or AS path
megaport-cli mcr looking-glass bgp-routes <MCR-UID> --output json --query "[?next_hop=='169.254.10.1']"

Routes from one specific neighbor

Pass the session ID (from bgp-sessions) and a direction — either advertised (routes the MCR is sending to the peer) or received (routes the MCR is hearing from the peer):

bash

# Routes received from this peer
megaport-cli mcr looking-glass bgp-neighbor-routes <MCR-UID> <SESSION-ID> received

# Routes advertised to this peer
megaport-cli mcr looking-glass bgp-neighbor-routes <MCR-UID> <SESSION-ID> advertised

# Filter to a specific prefix
megaport-cli mcr looking-glass bgp-neighbor-routes <MCR-UID> <SESSION-ID> received --ip 10.0.0.0/8

Useful when several peers are advertising overlapping prefixes and you want to confirm which one wins best-path selection.

The MCR's IP routing table (FIB)

bash

megaport-cli mcr looking-glass ip-routes <MCR-UID>

This is what the MCR is actually using to forward traffic — after BGP best-path selection and any local prefix filtering. A prefix that appears in bgp-routes but not in ip-routes is being learned but not installed; a prefix-filter-list or a better-path peer has masked it.

💡

Troubleshooting after a filter change

After updating a prefix-filter-list with mcr update-prefix-filter-list, re-run looking-glass ip-routes to confirm the FIB now reflects your intent. Routes can persist briefly during reconvergence.

Step 6 — Add IPsec encryption (optional)

For sensitive workloads that need encryption between the MCR and a remote site, attach an IPsec add-on. The add-on provisions a fixed pool of tunnel slots that you then terminate against your own VPN device.

Add the IPsec add-on

bash

# Default tunnel count (10)
megaport-cli mcr add-ipsec-addon <MCR-UID> --tunnel-count 10

# Larger pool — 20 or 30 tunnels
megaport-cli mcr add-ipsec-addon <MCR-UID> --tunnel-count 20

# JSON input
megaport-cli mcr add-ipsec-addon <MCR-UID> --json '{"tunnelCount":30}'

Resize the tunnel pool

bash

megaport-cli mcr update-ipsec-addon <MCR-UID> <ADDON-UID> --tunnel-count 30

Disable the add-on

Setting tunnel count to 0 removes the add-on from the MCR:

bash

megaport-cli mcr update-ipsec-addon <MCR-UID> <ADDON-UID> --tunnel-count 0

ℹ️

Tunnel counts are fixed tiers

Valid values are 10, 20, and 30. Pricing scales by tier — pick the smallest tier that covers your peak concurrent tunnel count.

Step 7 — Update the MCR

bash

# Rename
megaport-cli mcr update <MCR-UID> --name "Cloud Router SYD-PROD"

# Add cost centre
megaport-cli mcr update <MCR-UID> --cost-centre "INFRA-001"

# Extend contract term (no --term flag; use JSON)
megaport-cli mcr update <MCR-UID> --json '{"contractTermMonths":24}'

Best practices

ASN planning

Use a private ASN (64512–65534) for all MCR deployments unless you have a registered public ASN
Each MCR gets one ASN — plan it before provisioning as it cannot be changed

Prefix filter strategy

Always include a final deny 0.0.0.0/0 entry as a catch-all
Create per-cloud filter lists (one for AWS routes, one for Azure routes) for granular control
Use ge/le to constrain prefix lengths and prevent route pollution

Redundancy

For production, deploy a second MCR in the same metro with a different diversity zone
Connect each cloud VXC to both MCRs for failover

Speed sizing

MCR port speed is the total throughput cap across all attached VXCs
5 Gbps covers most multi-cloud architectures; scale up as traffic grows

What's next?

Multi-Cloud Connectivity — build the full AWS + Azure + GCP architecture with MCR
Connect to AWS — detailed AWS Direct Connect setup
Connect to Azure — detailed Azure ExpressRoute setup
Resource Types — MCR — MCR concept overview