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 figure shows two routers, R2 and R3, with the same ASN:
AS path

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.
Same AS number

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.
Adding an AS number

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.

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.

Multiple CSPs

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.
Private VPC peering

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.
Azure private peering

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.
Azure dual peering

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.
GCP VPC peering

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.

OCI VCN peering

For details, go to Remote VCN Peering.


Last update: