In Part I of this series, we explored how Oracle Cloud Infrastructure (OCI) enables transit routing between on-premises networks and regional VCNs using a hub-and-spoke model. We tested multiple approaches, from the classic LPG-based design to OCI’s enhanced DRG with VCN attachments and saw how route tables and import route distributions streamline traffic flow across complex topologies.
Now let’s take the next step.
Expanding to Multi-Region Connectivity
After validating transit routing within a single region (Phoenix), our next goal was to connect an additional region — Chicago — while keeping Phoenix as the central hub. This setup mimics what many organizations are doing today: anchoring the cloud networking in a primary region, while extending workloads and capabilities to other geographies.
We need to make sure traffic between the simulated on-premises environment (hosted in Ashburn), Phoenix, and Chicago all routes predictably and securely using Oracle’s Remote Peering Connections (RPCs).
Simulating On-Premises with a VPN in Ashburn
To avoid interfering with the customer’s real production network, we simulated an on-premises site in the OCI Ashburn region using a LibreSwan VPN appliance. This gave us full control over the routing logic, letting us inspect and manipulate packets in both directions.
By connecting the LibreSwan VPN to Phoenix via an IPSec tunnel, we effectively emulated an on-premises environment, without the unpredictability or dependency on actual enterprise routers or circuits.
This setup turned out to be more than a workaround — it helped surface design edge cases, like CIDR overlaps and route paths, that might otherwise go unnoticed in more abstract simulations.
Building the Remote Peering Connection (RPC)
To connect Phoenix (our hub) to Chicago (the spoke), we established a Remote Peering Connection (RPC) between their respective DRGs. Each DRG had its own attachments and DRG route tables, and the RPC served as a logical bridge between regions.
The routing logic needed careful attention. In Phoenix, the DRG route table for the RPC attachment needed to know about Chicago CIDRs, and vice versa. Fortunately, OCI’s Import Route Distributions helped here — we used match types and priorities to propagate only the necessary routes between attachments.
Routing Highlights:
- The IPSec tunnel from Ashburn terminated on Phoenix DRG, and routes to Ashburn CIDRs were imported into Phoenix DRG route tables.
- Phoenix DRG route tables then propagated selected routes to the RPC attachment, effectively extending the on-premises view into Chicago.
- Chicago DRG, upon receiving the routes via RPC, made them available to its attached VCNs through associated DRG route tables.
As a result, the Chicago VCNs could communicate with the simulated on-premises network in Ashburn without needing direct IPSec tunnels or overlapping route configurations.
Lessons Learned from Multi-Region Design
As we extended the architecture, we began to appreciate how OCI’s enhanced DRG model brings clarity and control to what could otherwise be a tangle of static routes. But that doesn’t mean the design is free of quirks.
Here are a few practical insights that emerged:
- Route visibility matters. Use
tracerouteand system-level logging inside VPN appliances to confirm which routes are actually being used. - DRG and its supported attachments: Understand each type of attachments on the DRG to define route table for each attachment and traffic routing. (See Figure: DRG Attachments & Route Table)
- DRG route table priorities are powerful. Use them to define fallback paths and avoid route conflicts — especially when the same CIDR may be reachable via multiple attachments.
- RPCs do not perform NAT. You need to be careful about overlapping address spaces and ensure consistent CIDR planning across regions.
Final Thoughts
Transit routing across regions isn’t just about connecting dots on a diagram. It’s about designing for operational simplicity, policy control, and scale. Fortunately, OCI’s routing tools — DRG attachments, route tables, import/export policies, and peering give us the flexibility to build toward those outcomes, but understanding how and when to apply them takes iteration and experimentation.
This POC helped us validate that the hub-and-spoke model, combined with DRG-based routing and Remote Peering, provides a strong foundation for hybrid and multi-region architectures.
To learn details of the implementation and configuration, follow the step-by-step tutorial here
To learn more about Oracle Cloud Infrastructure networking, click here