Article 09 – Cross-Region VCN Peering: RPC and Global Backbone Architecture

1. Introduction to Global Cross-Region Connectivity

Global enterprise cloud architectures often deploy workloads across multiple Oracle Cloud Infrastructure (OCI) regions—such as us-ashburn-1 (Primary Data Center) and eu-frankfurt-1 (Disaster Recovery site)—to satisfy geographic latency demands, high availability SLAs, and data residency compliance.

Connecting VCNs across different regions requires a high-performance private connection that bypasses the public internet.

In OCI, Cross-Region VCN Peering is achieved by linking two Dynamic Routing Gateways (DRG v2) across regions using Remote Peering Connections (RPCs).

Cross-region RPC traffic traverses Oracle’s private global fiber backbone, providing encrypted, low-latency, SLA-backed transit without public IP addresses or IPSec VPN overhead.

2. Core Architectural Mechanics of RPC Peering

1. The Remote Peering Connection (RPC) Object

An RPC is a logical sub-component created inside a Dynamic Routing Gateway (DRG v2).
* To peer VCN-Ashburn with VCN-Frankfurt, you create RPC-Ashburn inside DRG-Ashburn and RPC-Frankfurt inside DRG-Frankfurt.
* Once an RPC connection is established between the two RPC OCIDs, OCI links the underlying DRGs across the global network backbone.

2. Encryption and Physical Security

All traffic moving across Oracle’s inter-region backbone fiber is automatically encrypted at the physical layer (MACsec) by custom hardware before leaving data center facilities.

Architects do not need to deploy software IPsec tunnels or manage encryption keys to secure cross-region RPC traffic.

3. Routing and Dynamic BGP Propagation across RPCs

When RPC peering is established, DRG v2 route distributions automatically handle route propagation:
* DRG-Ashburn advertises its local VCN CIDRs (10.1.0.0/16) across the RPC to DRG-Frankfurt.
* DRG-Frankfurt advertises its local DR VCN CIDRs (10.2.0.0/16) back to DRG-Ashburn.

3. Disaster Recovery (DR) Network Design Pattern

A common cross-region RPC pattern is real-time database replication (e.g., Oracle Data Guard or MySQL InnoDB Cluster) between primary and secondary regions.

Key Network Parameters for DR:

• Low Jitter & Predictable Latency: Dedicated fiber paths guarantee minimal ping variance, preventing database sync timeouts.
• Non-Overlapping CIDRs Mandatory: Ashburn (10.1.0.0/16) and Frankfurt (10.2.0.0/16) must use distinct IP CIDR blocks.

4. OCI Web Console (GUI) Step-by-Step Walkthrough

Follow these steps to establish Cross-Region RPC Peering between us-ashburn-1 and eu-frankfurt-1.

Step 1: Creating an RPC in Region 1 (Ashburn)

1. Log in to the Console and set region selector to US East (Ashburn).
2. Navigate to Networking ➔ Dynamic Routing Gateways ➔ Click DRG-Ashburn.
3. Under Resources, click Remote Peering Connection Attachments.
4. Click Create Remote Peering Connection:
5. Name: RPC-To-Frankfurt
6. Compartment: Network-Compartment
7. Click Create Remote Peering Connection.
8. Copy the newly generated OCID of RPC-To-Frankfurt (ocid1.remotepeeringconnection.oc1.iad...).

Console Path: [Region: Ashburn] ➔ [Networking] ➔ [DRGs] ➔ [DRG Details] ➔ [Remote Peering Connections]

Step 2: Creating an RPC in Region 2 (Frankfurt)

1. Change region selector in the top bar to Germany Central (Frankfurt).
2. Navigate to Networking ➔ Dynamic Routing Gateways ➔ Click DRG-Frankfurt.
3. Under Resources, click Remote Peering Connection Attachments.
4. Click Create Remote Peering Connection:
5. Name: RPC-To-Ashburn
6. Compartment: Network-Compartment
7. Click Create Remote Peering Connection.

Step 3: Establishing the Cross-Region Connection

1. On the RPC-To-Ashburn details page in Frankfurt, click Establish Connection.
2. Select Specify Remote Peering Connection OCID.
3. Paste the Ashburn RPC OCID (ocid1.remotepeeringconnection.oc1.iad...) copied in Step 1.
4. Select Remote Region: US East (Ashburn).
5. Click Establish Connection.
6. Status updates to Peered across both regions within seconds.

Step 4: Updating VCN Route Tables for Cross-Region Access

1. In Ashburn VCN-Ashburn-Prod, open Subnet Route Table RT-Private-Ashburn.
2. Add Route Rule:
3. Target Type: Dynamic Routing Gateway
4. Destination CIDR: 10.2.0.0/16 (Frankfurt VCN Range)
5. Target DRG: DRG-Ashburn
6. Repeat in Frankfurt VCN-Frankfurt-DR route table, adding destination 10.1.0.0/16 ➔ DRG-Frankfurt.

5. Common Architectural Misconceptions & Pitfalls

Misconception 1: “Cross-Region RPC Traffic Crosses the Public Internet”

• Reality: Cross-region RPC traffic never enters the public internet. All packets are routed over Oracle’s private global fiber network, backed by end-to-end hardware encryption (MACsec).

Misconception 2: “Cross-Region RPC Connections Are Free”

• Reality: While local in-region DRG attachments are free, outbound cross-region data transfer over RPC incurs standard OCI inter-region data transfer charges (which remain among the lowest in the public cloud industry).

6. OCI Cross-Region Connectivity vs. Other Cloud Platforms