A successful cloud deployment often involves well designed cloud networking that can meet current and future growth in complexity. Connecting various Virtual Cloud Networks (VCNs) and extending them to on-premises or other Cloud providers datacenters are no longer something that good to have, but one of foundational requirements. By leveraging transit routing, Oracle Cloud Infrastructure (OCI) enables VCN connectivity across regions and customer on-premises.
Recently, I was working on a multi-region OCI setup POC for a customer that required routing traffic between on-premises datacenter and workloads deployed across OCI Phoenix and Chicago regions. The architecture needed to support:
- Hub-and-spoke VCN connectivity in Phoenix region
- Transit routing from on-premises to OCI regions and VCNs
- Future cross-region traffic between OCI Chicago region via Phoenix as a hub
To simplify the configuration with minimal changes at customer’s on-premises datacenter, we simulated an on-premises environment, deployed a LibreSwan VPN appliance in Ashburn region and connected it to the Phoenix region via IPSec site-to-site VPN service. Why are we doing this way? Well, we have learned that by simulating on-premises traffic using an actual Linux-based VPN was more flexible than relying on native test tools, especially when it came to routing validation. It eliminates other factors that are not associating with the POC and keep the configuration straight forward, while helped expose assumptions we’d made about route propagation and return paths.
We started as a typical OCI networking design, using VCNs and subnets with default route tables, quickly became a deeper exploration of OCI’s routing capabilities, especially around the enhanced Dynamic Routing Gateway or DRG. This post shares some practical takeaways and architectural insights, not just what worked, but why one path might be better than another.
What Transit Routing is All About?
Transit routing enables connectivity across VCNs deployed in multiple regions and with customer on-premises network through a central VCN deployed in a hub-and-spoke topology. We leverage components like Local Peering Gateway (LPGs), Dynamic Routing Gateway (DRGs), route tables, DRG attachments and Route Distributions to stitch together these paths. This also becomes something you would keep in mind when you design the transit routing network as OCI has been evolving its network architecture, and that means there are multiple ways to solve the same problem.
Two Approaches
To enable traffic flow between our simulated on-premises site in Ashburn region and workloads in Phoenix, we experimented with two distinct routing models.
1. The Classic LPG-Based Local Peering Connection
This model uses OCI Local Peering Gateways (LPGs) to connect VCNs within the same region. Only the hub VCN connects to the DRG, and the spoke VCNs peer into it via LPGs.
While technically sound, this approach required quite a bit of plumbing:
- Explicit LPG setup and routing between each VCN and route tables
- DRG route tables that know about every spoke CIDRs and how to reach them through LPGs
- Careful management of route propagation between DRG and LPG attachments
Although it worked — but felt a bit brittle. Each new spoke required manual updates in multiple VCNs and route tables.
2. The Enhanced DRG with VCN Attachment
On May 17,2021, OCI released an upgraded version of Dynamic Routing Gateway that can have many VCNs attached to it within the same region. Local VCN to VCN traffic can pass through a mutually connected DRG instead of Local Peering Gateway. With this upgraded version DRG, the need for LPG can be eliminated. Same region VCN peering configuration is simplified with a single DRG and its VCN attachments.
By assigning a dedicated DRG attachment to each VCN and associating a DRG route table with it, you can cleanly define how traffic should flow between each attachment. Even better, route distributions allow attachments to dynamically learn about one another — reducing the need for static configuration.
As a result:
- No LPGs needed
- No cross-resource dependencies between VCNs
- Better visibility and manageability as the environment scales
DRG Route Table and Import Route Distributions
At its core, transit routing function relies on DRG to learn route paths between VCNs and external site connection, i.e IPSec VPN. In traditional on-premises environments, this might be handled with MPLS, BGP route, or Software-Defined WAN controllers. But in OCI, we use Import Route Distribution that attach to a DRG Route Table on the IPSec VPN tunnel attachments.
Route distributions are imported using statement that defines what action to take for a specified match type at certain priority.
- Priority: A number between 1 and 65535 in ascending order, lower numbers have a higher priority.
- Match Type: Attachment type, Attachment, or Match all. When using Attachment Type, the import route distribution includes routes from all attachments for the selected Attachment type, where Attachment selects specific attachment.
This approach not only met our functional needs but also made it easier to extend routing policies down the road, especially as we looked toward connecting multiple regions.
Things to Keep in Mind
If you’re working in OCI today and building anything resembling a multi-VCN or hybrid network, here are a few things to keep in mind:
- Prefer the new DRG model whenever possible — it reduces architectural complexity and scales better.
- Treat LPGs as a fallback option — still valid in some contexts, but less optimal for larger designs.
- Test with realistic traffic flows — especially when simulating on-prem routes, use real packet flows (ICMP, TCP) to verify end-to-end behavior.
Coming Next: Cross-Region Transit Routing
In Part II, I’ll walk through how we connected the Chicago region using Remote Peering Connections (RPCs) — extending the same hub-and-spoke principles across OCI’s regional boundaries, and the quirks we encountered when layering on inter-region traffic. We will explore how to scale this architecture across regions using Remote Peering Connections and the design decisions, and real-world validation that came with it. If you are building hybrid or multi-region OCI networks, you don’t want to miss it. Subscribe or follow the blog to get notified when it drops and start leveling up your OCI networking game.
To learn more about Oracle Cloud Infrastructure networking, click here