Transit Routing on OCI

As an OCI estate grows past a handful of virtual cloud networks, the cost of connecting everything point to point becomes obvious. Every new VCN that needs to reach every other VCN and every on premises site adds another set of peering relationships and another pile of route entries. Transit routing solves this. It lets a single VCN, or the Dynamic Routing Gateway itself, sit in the middle and forward traffic on behalf of the networks attached to it.

This article explains what transit routing actually is on OCI, the two main ways to build it, the route table rules that make it work, and the failure modes that trip teams up. If you are new to the underlying components, read our guide to the Dynamic Routing Gateway first, because the modern transit model is built almost entirely on the upgraded DRG.

What transit routing means on OCI

Transit routing is the ability for traffic to pass through an intermediary network or gateway to reach a destination that is not directly attached to the source. Without it, two spoke VCNs that are both peered to a hub cannot talk to each other, because peering on its own is not transitive. Transit routing makes that hop possible in a controlled way.

There are two common reasons to want this. The first is hub and spoke consolidation, where shared services such as identity, logging, patch repositories and inspection live in a central VCN and every workload VCN reaches them through the hub. The second is on premises connectivity, where a single FastConnect or VPN attachment terminates in the hub and many spoke VCNs reach the corporate network through that one path rather than each buying its own circuit.

OCI supports transit routing in two architectures. The older model routes through a hub VCN using route tables attached to the VCN gateways. The newer model routes inside the upgraded Dynamic Routing Gateway itself, using DRG route tables and route distribution statements. For most new builds the DRG based model is the right default.

Hub and spoke through a hub VCN

In the VCN based pattern, a central hub VCN holds the connection to on premises through a DRG and is locally peered to each spoke VCN. The trick is the route table you associate with the gateways. A route table on the DRG attachment points traffic destined for spoke ranges at the local peering gateway, and a route table on each local peering gateway points on premises ranges back at the DRG. The hub VCN becomes a transit point even though no compute in it ever sees the packets.

This pattern predates the upgraded DRG and you will still find it in older estates. It works, but it asks you to manage routing logic across several gateway attached route tables, which is easy to get wrong as the number of spokes grows. If you inherited a network like this, document every gateway route table before you change anything.

Hub and spoke through the upgraded DRG

The upgraded DRG is itself a routing device. It can attach to many VCNs, multiple IPSec tunnels, multiple FastConnect virtual circuits and remote peering connections, all at once. Each attachment has an import route table and the DRG distributes routes between attachments according to rules you define. This means you no longer need a transit VCN to forward traffic between spokes. The DRG does it.

The design becomes much simpler. Every workload VCN attaches directly to one DRG. On premises connectivity attaches to the same DRG. You then write route distribution statements that say, for example, that VCN attachments learn on premises routes and the on premises attachment learns VCN routes. You can segment which spokes can reach which other spokes by giving them different DRG route tables, which is how you build separate production and non production routing domains on a single DRG.

Comparing the two transit models

One case still favours a hub VCN: when you need traffic to pass through a network appliance such as a firewall or inspection instance that lives in the hub. In that design the hub VCN is not just a router, it is a service insertion point, and the packets really do traverse compute in the hub before continuing. Many teams combine both, using the DRG for plain routing and a hub VCN for traffic that must be inspected.

A practical design framework

Common failure modes

The most frequent problem is asymmetric routing, where traffic leaves by one path and tries to return by another, and a stateful firewall in the middle drops the return packets because it never saw the outbound flow. This usually means a route table somewhere advertises a more specific route than you intended. Map the full path in both directions before you blame the application.

The second is overlapping address space. Transit routing cannot disambiguate two VCNs that both use the same CIDR range. If you are consolidating networks that were built independently, plan for re addressing or for network address translation at the boundary. The subnet design guide covers how to allocate ranges so this never happens in the first place.

The third is silent loss of spoke to spoke traffic after a migration from the hub VCN model to the DRG model, because an old gateway route table still points at the local peering gateway. Always remove the legacy routing once the DRG is carrying the traffic, and verify with the Network Path Analyzer that the live path matches the design.

Segmentation through DRG route tables

One of the most valuable things the upgraded DRG gives you is the ability to keep networks separate by default. Each attachment imports a route table you assign, and an attachment can only reach destinations that appear in the routes it imports. By giving production VCNs one route table and non production VCNs another, you create two routing domains on a single DRG that cannot reach each other unless you deliberately add the routes. This is segmentation expressed as routing policy rather than as a wall of firewall rules, and it is far easier to audit because the entire reachability picture lives in a small number of route tables you can read in one sitting.

A common production layout uses at least four routing domains: production workloads, non production workloads, shared services, and on premises. Shared services typically need to be reachable from both production and non production, so the shared services attachment imports routes to both, while production and non production each import shared services and on premises but not each other. Drawing this table once, before any attachment exists, saves a great deal of rework. When the policy is written as infrastructure as code it also becomes a reviewable artifact, so a change to who can reach whom goes through the same scrutiny as any other change.

Route distribution and dynamic learning

The DRG does not only hold static routes. It can learn routes dynamically from on premises over BGP and distribute them to the attachments you choose. Route distribution statements control which attachments learn which routes, so you can say that VCN attachments learn the on premises ranges advertised over FastConnect, while the on premises attachment learns the VCN ranges. This dynamic behaviour is what makes failover work without manual intervention. If a FastConnect circuit drops and a VPN backup takes over, the routes shift automatically and traffic continues, provided you designed the distribution to allow both paths.

The discipline here is to advertise only what genuinely needs to cross. Over advertising ranges from on premises into OCI, or the reverse, creates a larger reachability surface than intended and makes troubleshooting harder, because more routes mean more places for a flow to go wrong. Treat route advertisement as a deliberate allow list, not a convenience.

Validating a transit design before you trust it

A transit design is only correct if the live paths match the intent, and the only way to know is to test them. After building the attachments and route tables, walk through each routing domain and confirm that the networks which should reach each other do, and equally important, that the networks which should not reach each other cannot. The Network Path Analyzer is the right tool, because it evaluates the configured virtual path and reports exactly where a flow would be allowed or blocked without you needing to generate live traffic. Run it for representative source and destination pairs in every domain, including the negative cases, and keep the results as evidence that segmentation holds.

Revisit this validation whenever the topology changes. Adding a spoke, changing a route table or migrating from a legacy hub VCN model all carry the risk of a stale route quietly opening or closing a path you did not intend. A transit network that was correct at build time drifts like any other configuration, so periodic re validation belongs in the operating routine, not just the project.

Where transit routing fits the bigger picture

Transit routing is rarely a goal in itself. It is the plumbing that lets a landing zone scale without turning into a tangle of peerings. If you are designing a new estate, treat the DRG as the routing core from day one, attach everything to it, and express the routing domains as policy rather than as a growing set of manual route tables. If you are running an estate that grew organically, a transit redesign is often the single change that most improves both clarity and security.

For a full picture of how the gateways, route tables, peering and connectivity options fit together, start with the complete OCI networking guide, then layer transit routing on top once the fundamentals are clear.