The Megaport Cloud Router (MCR) works in multi-cloud architectures that are connected using different combinations of peering types. In addition to private peering connectivity, the MCR can connect to public peering types such as AWS, Azure, Oracle, and other cloud service providers (CSPs).
This topic describes MCR peering types and the routes advertised by each peering type.
The MCR uses a Virtual Cross Connect (VXC) to connect to other endpoints on the Megaport network. The VXCs support different types of peers. The MCR employs default routing policies aligned with the VXC peering type.
The peering type defined for the VXC determines which routes are advertised.
MCR peering types
The MCR supports the peering types shown in this table:
|Peering Type||Megaport Peering Definition||Routes Advertised|
|Non-cloud||NON-CLOUD||Routes from the Border Gateway Protocol (BGP) peer behind a Megaport.|
|Private cloud||PRIV_CLOUD||Routes from AWS Private, Azure Private Peer, and Google Cloud Platform.|
|Public cloud||PUB_CLOUD||Routes from AWS Public, Azure MS Peer, Salesforce, and other CSPs.|
Note Although you can configure private cloud and public cloud peering types simultaneously,the MCR does not exchange routes between the two.
Non-cloud (NON_CLOUD) VXCs connect to a physical port in the data center. These connections refer to the private network infrastructure within a data center, and can include service providers in Megaport Marketplace. These are connections in which you fully administer both sides, or where you’ve worked out the routing details with the peer organization.
|Megaport Endpoint||Peering Type|
|Physical Megaports||Private VXC|
|Megaport Marketplace||Private VXC|
|B2B VXCs||Service Key|
Private cloud VXCs
Private cloud (PRIV_CLOUD) VXCs connect to private peering options with public CSPs. Private peering typically involves exchanging RFC 1918 routes with the service provider.
|Cloud Service Provider||Peering Type|
|AWS Direct Connect||Private VIF, Transit VIF|
|Azure ExpressRoute||Private Peering|
|Google Cloud Interconnect||Partner Interconnect Attachment|
|Oracle Cloud Infrastructure||FastConnect Private Peering|
Similar connectivity is available from IBM Cloud, Alibaba, SAP HANA Enterprise Cloud, and many other CSPs. For a full list of cloud service providers, go to Cloud Connectivity.
Public cloud VXCs
Public cloud (PUB_CLOUD) VXCs provide direct connectivity to public peering options from public CSPs. Public peering options typically involve exchanging public address space with a service provider.
|Cloud Service Provider||Peering Type|
|AWS Direct Connect||Public VIF|
|Azure ExpressRoute||Microsoft Peering|
|Oracle Cloud Infrastructure||FastConnect Public Peering|
Route advertisement scenarios
Non-cloud and private cloud
A combination of non-cloud and private cloud connectivity is fairly straightforward when it comes to route advertisement. To allow each environment to exchange private RFC 1918 address space, multi-tenant networks use network virtualization and segmentation mechanisms. The private cloud is introduced as a private node on your internal network.
This figure shows a corporation using a firewall to segment its cloud connectivity. The cloud network is connecting from their firewall in the data center to their MCR via a private NON_CLOUD VXC. The MCR is, in turn, connecting to AWS via a PRIV_CLOUD VXC.
The public cloud connectivity option requires the exchange of public address space, similar to peering with an internet service provider (ISP). Large organizations that require connectivity to multiple ISPs employ network engineers and architects that are familiar with all of the nuanced requirements necessary to participate in exchanging public routes on the internet.
The MCR alleviates some of these nuances by providing default policies that ensure you don’t inadvertently advertise public routes belonging to one CSP to another. For example, consider a route advertisement in a network topology with an ExpressRoute Microsoft peering to Azure and a public virtual interface (VIF) to AWS. If any-to-any connectivity were allowed between the two public cloud peerings, all traffic between AWS and Azure would traverse the MCR. Allowing any-to-any connectivity would cause a global service disruption for both CSPs. To avoid service disruption, the CSPs protect their customers with policies that prevent this type of misconfiguration. However, because mistakes can happen, the MCR also has routing mechanisms in place to restrict the public cloud peering types from exchanging public address spaces.
MCR route advertisement configurations
The supported MCR route advertisement configuration types are:
- Public cloud => Non-cloud
- Private cloud => Non-cloud, Private cloud
- Non-cloud => Non-cloud, Private cloud, Public cloud
Support for these peering type configurations results in a globally available platform that allows rapid deployment of routing services on demand, in a safe manner, with best practice routing policies already applied.