When connecting two Oracle Cloud Infrastructure (OCI) regions using Megaport, a common approach involves deploying Two Megaport Cloud Routers (MCRs)—one in each region—to ensure maximum flexibility and clear route separation. While effective, this setup may not be the most cost-efficient for every use case.
In this post, we explore an alternative method to connect two OCI regions using a single MCR. We’ll demonstrate how to maintain essential inter-region connectivity while minimizing infrastructure costs, and how to address BGP limitations through the strategic use of static routes.
Architecture:
To implement this solution, we assume the following infrastructure is already provisioned:
Ashburn Region:
VCN CIDR: 10.10.0.0/16
Compute IP: 10.10.10.56
BGP Subnet: 172.16.0.0/30
Phoenix Region:
VCN CIDR: 10.20.0.0/16
Compute IP: 10.20.10.150
BGP Subnet: 172.16.0.4/30
Megaport MCR:
Megaport ASN: 133937
Oracle ASN: 31898 (fixed)
Dynamic Routing Gateways (DRGs)
Each VCN is attached to a DRG with appropriate routing and security lists in place.
Compute Instances
Ashburn VM: 10.10.10.56
Phoenix VM: 10.20.10.150
Megaport Configuration Access
An active Megaport account with the ability to deploy and manage an MCR.
Solution:
To set up FastConnect with Megaport Cloud Routers (MCRs), you can follow the standard configuration steps outlined in this guide. However, for our scenario, we skip the steps involving a private VXC connection between regions. Instead, we use static routes to work around BGP’s autonomous system (AS) loop prevention mechanisms.
Static Routing as a Workaround for Ashburn region:
In our design, we configure static routes on the MCR to map destination CIDRs to their corresponding BGP peer IPs. To reach the Ashburn VCN (10.10.0.0/16), we configure a static route on the MCR’s “Ashburn-Connection” interface pointing to the DRG IP 172.16.0.2.
By default, the MCR is set to automatically redistribute static and connected routes into BGP. This means any static route you configure on the MCR will be advertised to other BGP peers—such as the Phoenix region in our case.
As a result, the Ashburn VCN route is successfully redistributed and advertised to Phoenix as a local static route by the MCR, enabling inter-region communication.
Select the “Ashburn-Connection” and configure the static route as shown below.
Implementing Static Routing as a Workaround for Phoenix region
Similarly, to enable connectivity to the Phoenix VCN (10.20.10.0/16), we configure a static route on the same MCR—this time on the “Phoenix-Connection” interface. The static route points to the Phoenix DRG BGP peer IP (172.16.0.6).
Since the MCR automatically redistributes static routes into BGP, this route is also advertised to the Ashburn region. This ensures that both regions can communicate seamlessly, despite using a single MCR and avoiding BGP loop prevention issues.
Select the “Phoenix-Connection” and configure the static route as shown below.
This approach allows traffic to flow between OCI regions, avoiding ASN conflicts and maintaining network stability. The BGP session is still in use between MCR and OCI.
Verification:
OCI BGP and Virtual Circuit configuration on Ashburn.
OCI BGP and Virtual Circuit configuration on Phoenix
In the below traceroute and ping output confirms successful connectivity from the Ashburn compute instance (10.10.10.56) to the Phoenix instance (10.20.10.150) via the single Megaport Cloud Router. Intermediate hops, including BGP peer IPs (172.16.0.2 and 172.16.0.6), validate the static route-based forwarding path.
Conclusion:
While Oracle’s recommended approach for inter-region connectivity is using Remote Peering over DRGs, some customer scenarios—especially those involving third-party network providers like Megaport—may require alternative solutions.
Using a single Megaport Cloud Router to connect two OCI regions can be a simplified option. Although this setup introduces routing challenges due to OCI’s fixed AS numbers, implementing static routes on the MCR provides a reliable workaround. For the right use cases, this method offers a practical balance between cost savings and functional connectivity.