All but the first of these basic routing scenarios send traffic from a subnet in the VCN to the DRG. To accomplish this, you must set up a rule in the subnet's route table. The rule's destination CIDR is the CIDR of the network that is being reached through the DRG, and the rule's target is the DRG. For more information, see VCN Route Tables.
These scenarios all allow traffic to flow from one VCN to another.
Advanced scenarios using a single DRG
VCN Ingress Routing: Some of the following advanced scenarios require ingress routing of traffic entering the VCN from a DRG through the VCN attachment. To accomplish this, you must associate a VCN route table (this is a route table created inside your VCN) with the VCN attachment. After a VCN route table is associated with a VCN attachment, there must always be a VCN route table associated with that attachment (that is, you cannot update the field in the corresponding data object to "Null"). Removing the VCN ingress routing functionality from a VCN attachment can only be accomplished by emptying the associated VCN route table or updating the attachment to refer to an empty VCN route table.
- Remote on-ramp (Upgraded DRG)
- Using a DRG to route traffic through a centralized network virtual appliance (Upgraded DRG)
- Private Access to Oracle Services
- Transit Routing inside a hub VCN
Advanced scenario with multiple DRGs and multiple VCNs
There's an extra advanced scenario that illustrates the use of multiple DRGs and VCNs. In this case, each VCN has its own dynamic routing gateway (DRG) and its own FastConnect private virtual circuit . Contrast this with Transit Routing inside a hub VCN, in which there's a single DRG with either Site-to-Site VPN or a single FastConnect private virtual circuit.
Here are some restrictions for using the scenario that has multiple DRGs:
- The scenario works only with FastConnect through a third-party provider or through colocation with Oracle. It is not supported for FastConnect through an Oracle partner.
- The scenario is supported only for VCNs in the same region and same tenancy. This is because all the virtual circuits use a single cross-connect, a regional resource.