MCR Private Cloud Peering
Megaport Cloud Router (MCR) supports multi-cloud architectures that include combinations of private and public cloud peering types, as well as non-cloud connectivity to your data center. This topic describes:
- How the autonomous system numbers (ASNs) work with the Border Gateway Protocol (BGP) routing to advertise traffic routes.
- The MCR private connectivity options supported by the Cloud Service Providers (CSPs).
Understanding the autonomous system numbers
An autonomous system (AS) is a single network or a set of networks and routers that are managed and supervised on behalf of a single administrative entity, such as a business division. An AS is assigned a globally unique number that identifies the network to the world.
The MCR uses BGP to exchange traffic routes between private peering and non-cloud peering types. To reduce the complexity of BGP support for the CSPs, the MCR provides automated configuration and follows standard BGP routing policies and inter-AS routing best practices. Although the MCR follows routing best practices and BGP has built-in loop prevention, an understanding of the autonomous system path list is helpful when assigning ASNs to peers.
Understanding the AS path list
When routes are advertised to an external BGP (eBGP) neighbor, the ASN of the local router is added to the AS path list (AS_PATH). To the receiving autonomous system (AS), this creates a breadcrumb trail to the originating AS. This image shows two routers, R2 and R3, with the same ASN:
When an eBGP peer receives an eBGP route that includes its own AS number as an AS path attribute, it will deny the route and drop it to prevent a BGP route loop. This is the expected behavior with BGP. In this scenario, because R2 and R3 have the same ASN, R3 will drop R2’s routes upon arrival.
Now suppose R4 with an ASN of 65101 is added to the network. In this scenario, routes will be advertised from R3 to R4, and from R2 to R4 via R1. However, R3 will still drop R2’s routes upon arrival because R2 and R3 have the same ASN.
After updating R2’s configuration with a unique AS number, 64515, R3 now accepts the routes being advertised by R2.
Private ASN support
With AWS Direct Connect gateway, you can bring your own private ASN to the Amazon side of the connection. Other cloud service providers require you to peer using their public ASN.
This table summarizes the supported ASNs from each CSP:
| Cloud Provider | Peering Type | Customer Side AS | Cloud Provider Side AS |
|---|---|---|---|
| AWS | PRIV_CLOUD | Private or Public ASN | Private ASN or ASN 7224 |
| Google Cloud | PRIV_CLOUD | Private or Public ASN | ASN 16550 |
| Oracle Cloud | PRIV_CLOUD | Private or Public ASN | ASN 31898 (Gov Cloud 6142) |
| Microsoft Azure | PRIV_CLOUD | Private or Public ASN | ASN 12076 |
To learn more, explore these resources.
- AWS – AWS Direct Connect FAQs
- Google Cloud – Establishing 99.99% Availability for Partner Interconnect
- Oracle Cloud – FastConnect Requirements
- Microsoft Azure – Autonomous System Numbers
Supported connectivity options with MCR
MCR allows you to build a robust architecture that supports private peering to multiple cloud providers. Just be sure to use unique ASNs between the MCR peers, unless you are creating an internal Border Gateway Protocol (iBGP) peer to another MCR or physical router in the data center. You can provide connectivity to the same cloud provider, in different regions, with different on-ramps, as long as you are not routing traffic on an eBGP peering with the same ASN.
This section describes many, but not all, of the supported private peering connectivity architectures with the MCR. Because networks are not identical, the examples provide a starting point for your peering architecture.
AWS private peering between VPCs
AWS provides the ability to route between different AWS Virtual Private Clouds (VPCs) when using your own private ASN and the MCR.
Azure private peering with a single ExpressRoute and multiple VNets
With Azure, you can attach multiple virtual networks (VNets) to the same ExpressRoute and route traffic between the VNets without leaving the Azure network.
Note
Azure private peering with dual ExpressRoute is not supported. In this scenario, BGP loop prevention will prevent routes from being advertised, because Azure will detect its own ASN in the AS path.
Azure private peering with dual ExpressRoute inter-VNet routing
MCR supports an architecture with dual ExpressRoute circuits connecting each VNet to both ExpressRoute circuits. Because the inter-VNet routing occurs without leaving Azure, the AS path is not evaluated. This deployment provides high availability while also allowing for inter-VNet routing.
Google Cloud Platform VPC peering
VPCs in Google Cloud Platform (GCP) are global and include subnets for each region. GCP provides the ability to perform VPC peering to route traffic between two VPCs.
Oracle Cloud Infrastructure VCN peering
Oracle provides remote Virtual Cloud Network (VCN) peering to route between regions. Support includes routing between Oracle Cloud Infrastructure (OCI) and OCI Classic, or between OCI and Oracle Government Cloud.
Note
External routing between OCI commercial regions is not supported.
For more information, see Remote VCN Peering.