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 Overview of Networking.

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 dynamic routing gateway.

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 Scenario: Transit Routing

There's an advanced routing scenario called transit routing that enables communication between an on-premises network and multiple VCNs over a single Oracle Cloud Infrastructure FastConnect or IPSec VPN. The VCNs must be in the same region and locally peered in a hub-and-spoke layout. The VCN that is acting as the hub is connected to the on-premises network by way of an attached DRG. That 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 to the spoke VCNs.

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 a local peering gateway (LPG) on the attached VCN as the 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 dynamic routing gateway
To attach a dynamic routing gateway to a VCN
To route a subnet's traffic to a dynamic routing gateway
To associate a route table with an existing dynamic routing gateway attachment
To detach a dynamic routing gateway from a VCN
To delete a dynamic routing gateway
To manage tags for a dynamic routing gateway

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.