Skip to content
Advanced - Solutions Architect 45 minutes

MCR Routing

Provision a Megaport Cloud Router, attach VXC spokes, and manage BGP prefix filter lists for multi-cloud traffic engineering

Prerequisites

  • Megaport CLI installed and authenticated
  • Understanding of VXCs (Connect to AWS / Connect to Azure tutorials)
  • Basic BGP knowledge recommended

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

ParameterValuesNotes
--port-speed1000, 2500, 5000, 10000, 25000, 50000, 100000 MbpsTotal throughput capacity
--mcr-asn64512–65534 (private) or public ASNAuto-assigned private ASN if omitted
--marketplace-visibilitytrue / falsefalse = private, not listed to other customers
--diversity-zonee.g. blue, redFor 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> \
  --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"}'

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.

Create a prefix filter list

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

FieldRequiredDescription
actionYes"permit" or "deny"
prefixYesCIDR notation (e.g. 10.0.0.0/8)
geNoMinimum prefix length to match (greater-than-or-equal)
leNoMaximum 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 — 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?