Oracle Cloud Infrastructure Documentation

Dynamic Routing Gateways (DRGs)

This topic describes how to manage a An optional virtual router that you can add to your VCN to provide a path for private network traffic between your VCN and on-premises network.. This topic uses the terms dynamic routing gateway and DRG interchangeably. The Console uses the term Dynamic Routing Gateway, whereas for brevity the API uses DRG.

You use a DRG when connecting your existing on-premises network to your virtual cloud network (VCN) with one (or both) of these:

You also use a DRG when peering a VCN with a VCN in a different region:

Warning

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Overview of Dynamic Routing Gateways

You can think of a DRG as a virtual router that provides a path for private traffic (that is, traffic that uses private IPv4 addresses) between your VCN and networks outside the VCN's region.

For example, if you use an IPSec VPN or Oracle Cloud Infrastructure FastConnect (or both) to connect your on-premises network to your VCN, that private IPv4 address traffic goes through a DRG that you create and attach to your VCN. For scenarios for using a DRG to connect a VCN to your on-premises network, see Networking Scenarios. For important details about routing to your on-premises network, see Routing Details for Connections to Your On-Premises Network.

Also, if you decide to peer your VCN with a VCN in another region, your VCN's DRG routes traffic to the other VCN over a private backbone that connects the regions (without traffic traversing the internet). For information about connecting VCNs in different regions, see Remote VCN Peering (Across Regions).

Working with DRGs and DRG Attachments

For the purposes of access control, when creating a DRG, you must specify the compartment where you want the DRG to reside. If you're not sure which compartment to use, put the DRG in the same compartment as the VCN. For more information, see Access Control.

You may optionally assign a friendly name to the DRG. It doesn't have to be unique, and you can change it later. Oracle automatically assigns the DRG a unique identifier called an Oracle Cloud ID (OCID). For more information, see Resource Identifiers.

A DRG is a standalone object. To use it, you must attach it to a VCN. A VCN can be attached to only one DRG at a time, and a DRG can be attached to only one VCN at a time. You can detach a DRG and reattach it at any time. In the API, the process of attaching creates a DrgAttachment object with its own OCID. To detach the DRG, you delete that attachment object.

After attaching a DRG, you must update the routing in the VCN to use the DRG. Otherwise, traffic from the VCN will not flow to the DRG. See To route a subnet's traffic to a DRG.

To delete a DRG, it must not be attached to a VCN or connected to another network by way of IPSec VPN, Oracle Cloud Infrastructure FastConnect, or remote VCN peering. Also, there must not be a route rule that lists that DRG as a target.

For information about the number of DRGs you can have, see Service Limits.

Routing a Subnet's Traffic to a DRG

The basic routing scenario sends traffic from a subnet in the VCN to the DRG. For example, if you're sending traffic from the subnet to your on-premises network, you set up a rule in the subnet's route table. The rule's destination CIDR is the CIDR for the on-premises network (or a subnet within), and the rule's target is the DRG. For more information, see Route Tables.

Advanced Scenarios: Transit Routing

This documentation includes a few basic networking scenarios to help you understand the Networking service and generally how the components work together. See scenarios A, B, and C in Networking Scenarios

Scenarios A–C show your on-premises network connected to a VCN by way of FastConnect or VPN Connect, and accessing only the resources in that VCN.

The following advanced routing scenarios give your on-premises network additional access beyond the resources in the connected VCN. Traffic travels from your on-premises network to the VCN, and then transits through the VCN to its destination. See these topics:

  • Transit Routing: Access to Multiple VCNs in the Same Region: Your on-premises network has access to multiple VCNs in the same region over a single FastConnect private virtual circuit or VPN Connect. The VCNs are in a hub-and-spoke layout, with the on-premises network connected to the VCN that acts as the hub. The spoke VCNs are peered with the hub VCN.
  • Transit Routing: Private Access to Oracle Services: Your on-premises network has private access to Oracle services in the Oracle Services Network by way of the connected VCN and the VCN's An optional virtual router that you can add to your VCN. The gateway enables on-premises hosts or VCN hosts to privately access Oracle services (such as Object Storage and Autonomous Database) without exposing the resources to the public internet.. The traffic does not go over the internet.

In the transit routing scenarios, the VCN has a route table associated with its DRG attachment (typically route tables are associated with a VCN's subnets). That route table lets you manage routing of traffic through the VCN that is connected to the on-premises network.

When you attach a DRG to a VCN, you can optionally associate a route table with the attachment. Or if you already have a DRG attachment, you can associate a route table with it. The route table must belong to the attached VCN. A route table associated with a DRG attachment can contain only rules that use one of the following as a target:

A DRG attachment can exist without a route table associated with it. However, after you associate a route table with a DRG attachment, 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 of the rules.

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a An IAM document that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.

For administrators: see IAM Policies for Networking.

Using the Console

In general, to use a DRG, you must complete these steps:

  1. Create the DRG.
  2. Attach the DRG to your VCN.
  3. Route subnet traffic to the DRG. This involves updating the route table associated with each subnet that must send traffic to the DRG. If all the subnets use the VCN's default route table, you must only update that one table.
To create a DRG
To update a DRG's name
To attach a DRG to a VCN
To route a subnet's traffic to a DRG
To associate a route table with an existing DRG attachment
To detach a DRG from a VCN
To delete a DRG
To manage tags for a DRG
To move a dynamic routing gateway to a different compartment

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

To manage your DRGs, use these operations:

For information about route table operations, see Route Tables.