Scenario D - Transit Routing Through a Hub VCN
This scenario describes a network topology where the on-premises network connects to a VCN on the Compute Cloud@Customer in order to reach resources beyond that VCN. Routing rules in this VCN are configured so that traffic transits through the VCN to its destination.
As a basic example of why you might use transit routing: you have a large organization with different departments, each with their own VCN. The on-premises network needs access to the different VCNs, but you do not want the administration overhead of maintaining a secure connection from each VCN to the on-premises network. Instead, you use VCNs in a hub-and-spoke topology: one VCN acts as the hub to which the on-premises network connects, and the spoke VCNs are peered with the hub VCN. Traffic between the on-premises network and the peered VCNs transits through the hub VCN. The VCNs can be in different tenancies.
Important Aspects of Transit Routing
Transit routing introduces specific component configurations that a network administrator must take into account. These and other important aspects are discussed in this section.
Notable Concepts
If you are already familiar with the Networking service and VCN peering, these are the most important concepts to understand when implementing a transit routing scenario:
-
There are several different gateways involved in transit routing. The hub VCN has a dynamic routing gateway (DRG), which is the communication path with the on-premises network. For each peered spoke VCN, there is a pair of local peering gateways (LPGs) that anchor the peering connection. One LPG is on the hub VCN, and the other is on the spoke VCN.
-
The Networking service does not allow local VCN peering between two VCNs with overlapping CIDRs. That means each spoke must not overlap with the hub. However, the Networking service does not validate whether the spoke VCNs themselves overlap with each other, or if any of the VCNs overlap with the on-premises network. You must ensure that CIDRs for all the subnets that need to communicate with each other don't overlap. Otherwise, traffic might be dropped.
-
For each spoke VCN subnet that needs to communicate with the on-premises network, you must update the subnet's route table with a rule that sets the target, or the next hop, as the spoke VCN's LPG for all traffic destined for the on-premises network.
-
You must add a route table to the hub VCN and associate it with the DRG attachment. For each spoke VCN, add a route rule to the DRG attachment route table for all traffic destined for a given spoke VCN, or a subnet in the spoke VCN; set the target to the hub VCN's LPG for that spoke.
-
You must add another route table to the hub VCN and associate it with the hub VCN's LPG for a given spoke. Add a route rule to the spoke LPG route table for all traffic destined for the on-premises network, or a subnet in that network; set the target to the DRG. The same route table setup is required for each spoke VCN that needs to communicate with the on-premises network.
Routing Restrictions
There are important restrictions to be aware of when implementing transit routing in your environment.
-
Route table for DRG attachment
A route table that is associated with a DRG attachment can have only rules that target an LPG or a private IP.
A DRG attachment can exist without an associated route table. However, after you associate a route table with a DRG attachment, there must always be a route table associated with it. You can associate a different route table. You can also edit the table's rules, or delete some or all of the rules.
-
Route table for LPG
A route table that is associated with an LPG can have only rules that target a DRG.
An LPG can exist without an associated route table. However, after you associate a route table with an LPG, there must always be a route table associated with it. You can associate a different route table. You can also edit the table's rules, or delete some or all of the rules.
-
Traffic through the hub VCN
The route tables discussed here are intended only for moving traffic through the hub VCN between locations in the on-premises network and locations in a spoke VCN. Routing traffic through a private IP in the hub is not supported on Compute Cloud@Customer.
-
Inbound traffic to the hub VCN
Although the purpose of transit routing is to move traffic through the hub VCN, inbound traffic to subnets within the hub VCN is always allowed. No explicit rules are required in the DRG attachment route table or the hub LPG route table.
When this kind of inbound traffic reaches the DRG or the hub LPG, the traffic is automatically routed to its destination in the hub VCN by the VCN local routing. Consequently, for any route table belonging to a given VCN, you cannot create a rule that lists that VCN's CIDR, or a sub-section, as the rule's destination.
Routing Paths in Detail
To further illustrate how transit routing takes place, the different paths of traffic are displayed in the diagram, and described in detail below.

The callouts in the diagram indicate the route tables to be added for this configuration. The route rules required in this example are listed in the table that follows.
Callout |
Route Table |
Route Rules |
---|---|---|
1 |
Hub subnet |
|
2 |
Spoke subnet |
For all spoke subnets, the route target must be the LPG of the parent VCN.
|
3 |
DRG attachment |
|
4 |
Hub LPG |
For each hub LPG (H1, H2, H3), traffic intended for the on-premises network must be sent through the DRG.
|
These are the networking elements used in the example:
-
On-premises network: 10.25.0.0/16
-
Hub VCN: 172.16.0.0/16
The hub VCN has a DRG to connect with the on-premises network. It also has an LPG for each peering connection to a spoke VCN, for example: LPG-H1, LPG-H2 and so on.
-
Spoke VCN-S1: 10.1.0.0/16
The spoke VCN has an LPG for the peering connection to the hub VCN: LPG-S1
The spoke VCN contains subnets, for example: 10.1.1.0/24, 10.1.2.0/24 and so on.
-
Spoke VCN-S2: 10.2.0.0/16
The spoke VCN has an LPG for the peering connection to the hub VCN: LPG-S2
The spoke VCN contains subnets, for example: 10.2.1.0/24, 10.2.2.0/24 and so on.
-
Additional spoke VCNs follow the same pattern as VCN-S1 and VCN-S2.
-
Traffic leaves the on-premises network and reaches the DRG. The traffic's destination is in Subnet-1 of VCN-S1, for example: 10.1.1.5.
-
The DRG attachment's associated route table has a rule for 10.1.0.0/16. It matches the destination and sends the traffic to the route target: LPG-H1.
-
LPG-H1 receives the traffic.
Egress traffic leaving a VCN through an LPG is automatically routed to the LPG's peered LPG, which is LPG-S1 in this situation. That routing occurs automatically because of the peering connection between the two LPGs.
-
LPG-S1 receives the traffic.
Traffic coming in to a VCN through the LPG is automatically routed to the destination within the VCN because of VCN local routing. No explicit route rules are required.
-
Traffic comes from an instance in Subnet-1 of spoke VCN-S1. The traffic's destination is in the on-premises network, for example: 10.25.112.17.
-
Subnet-1's associated route table has a rule for 10.25.0.0/16. It matches the destination and sends the traffic to the route target: LPG-S1.
-
LPG-S1 receives the traffic.
Egress traffic leaving a VCN through an LPG is automatically routed to the LPG's peered LPG, which is LPG-H1 in this situation. That routing occurs automatically because of the peering connection between the two LPGs.
-
LPG-H1 receives the traffic.
LPG-H1's associated route table has a rule for 10.25.0.0/16. It matches the destination and sends the traffic to the route target: the hub VCN's DRG.
-
The DRG receives the traffic.
Egress traffic leaving a VCN through the DRG is automatically routed to the destination in the connected on-premises network. No explicit route rules in the DRG attachment's route table are required.
Subnet-1 in the spoke VCN and LPG-H1 both have route rules with 10.25.0.0/16 as the destination CIDR. Those rules are not required to use the exact same CIDR block, but you must ensure that both rules cover the traffic you want to route from the spoke to the on-premises network. The rule in Subnet-1's route table controls which traffic is routed from Subnet-1 to LPG-H1. The rule in LPG-H1's route table controls which traffic is routed from the spoke VCN to the on-premises network. If LPG-H1's route rule is more restrictive than Subnet-1's route rule, some traffic leaving the subnet could be dropped and not reach the DRG.
Depending on your situation, you might want to enable traffic between instances in the hub VCN and a spoke VCN, in addition to the traffic between the on-premises network and a spoke VCN. This is possible as long as routing only occurs directly between gateways, and not through a private IP in the hub VCN.
This is how traffic would flow from the spoke VCN to a destination with an address in the hub VCN:
-
Traffic comes from an instance in Subnet-1 of spoke VCN-S1. The traffic's destination is in HubSubnet-A of the hub VCN, for example: 172.16.2.85.
-
Subnet-1's associated route table has a rule for 172.16.0.0/16. It matches the destination and sends the traffic to the route target: LPG-S1.
-
LPG-S1 receives the traffic.
Egress traffic leaving a VCN through an LPG is automatically routed to the LPG's peered LPG, which is LPG-H1 in this situation. That routing occurs automatically because of the peering connection between the two LPGs.
-
LPG-H1 receives the traffic.
Traffic coming in to a VCN through the LPG is automatically routed to the destination within the VCN because of VCN local routing. No explicit route rules are required.
A similar series of routing steps occurs for traffic going from HubSubnet-A to Subnet-1, but in the reverse direction. HubSubnet-A's route table has a rule that matches the spoke VCN's CIDR (10.1.0.0/16) and sends the traffic to LPG-H1, which forwards it on to LPG-S1.
Setting Up VCN Transit Routing
To set up a transit routing scenario using direct traffic between gateways, you perform the tasks described below.
-
Create a new VCN.
Specify one or more non-overlapping CIDR blocks for the VCN; for example: 172.16.0.0/16.
-
Optionally, create one or more subnets in the hub VCN. The subnets can contain cloud resources that your on-premises network or the spoke VCN need to use.
Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 172.16.1.0/24.
-
Create a DRG and attach it to the hub VCN.
-
Update the hub VCN route table to allow traffic to flow to the DRG.
Select the on-premises network as the destination CIDR; for example: 10.25.0.0/16.
The route table to be associated with the DRG attachment is created in a later task.
-
Create a new VCN. In this example it is named VCN-S1.
Specify one or more non-overlapping CIDR blocks for the VCN; for example: 10.1.0.0/16.
-
Create one or more subnets in the spoke VCN.
Specify a single, contiguous CIDR block within the VCN's CIDR block; for example: 10.1.1.0/24.
-
Add an LPG to the hub VCN and spoke VCN. In this example they are named LPG-H1 and LPG-S1 respectively.
-
Establish the peering connection between the two LPGs.
-
Update the hub VCN route table to allow traffic to flow to LPG-H1.
Select the spoke VCN-S1 as the destination CIDR: 10.1.0.0/16.
The route table to be associated with LPG-H1 is created in a later task.
-
Create a route table for Subnet-1 in spoke VCN-S1.
Add a route rule to direct traffic destined for the hub VCN (172.16.0.0/16) to LPG-S1.
-
Associate the route table with Subnet-1 in spoke VCN-S1.
-
If other subnets in the spoke VCN need to communicate with the on-premises network, perform steps 4 and 5 with different parameters for each of those subnets in order to set up and associate a similar route table.
-
Edit the route table associated with Subnet-1 in spoke VCN-S1. You created this route table in the previous task.
-
Add a route rule for traffic destined for the on-premises network (10.25.0.0/16). Set the rule target to the LPG of this spoke VCN: LPG-S1.
-
Repeat these steps for other subnets in the spoke VCN that need to communicate with the on-premises network.
-
Create a route table for the DRG attachment.
Add a route rule for traffic destined for the spoke VCN-S1 (10.1.0.0/16). Set the rule target to the hub VCN's LPG for the spoke in question: LPG-H1.
-
Associate the DRG route table with the hub VCN's DRG attachment.
-
Create a route table for the hub VCN's LPG for this spoke: LPG-H1.
Add a route rule for traffic destined for the on-premises network (10.25.0.0/16). Set the rule target to the hub VCN's DRG.
-
Associate the route table with the hub VCN's LPG for the spoke in question: LPG-H1.
-
Repeat tasks 3-5 for the new spoke VCN.
-
Repeat task 6 with these changes:
-
For Step 1: Instead of creating a new route table for the DRG attachment, update the existing route table to include a new rule for the new spoke VCN. The destination CIDR is the spoke VCN's CIDR, or a subnet within). The target is the hub VCN's LPG for the new spoke.
-
For Step 2: Skip this step entirely because the DRG attachment is already associated with its route table.
-
For the entire procedure: use convenient names in accordance with the spokes you are adding. For example, if you are adding spoke VCN-S4, it is helpful to call the two peering gateways LPG-S4 and LPG-H4, and use those gateway names to identify the route tables you associate with them.
-
Turning Off Transit Routing
To turn off transit routing, remove the rules from:
-
The route table associated with the DRG attachment.
-
The route table associated with each LPG on the hub VCN.
A route table can be associated with a resource but have no rules. Without at least one rule, a route table does nothing.
A DRG attachment or LPG can exist without a route table associated with it. However, after you associate a route table with a DRG attachment or LPG, there must always be a route table associated with it. But, you can associate a different route table. You can also edit the table's rules, or delete some or all rules.