Dynamic Routing Gateways (DRGs)

This topic describes how to manage a dynamic routing gateway (DRG) . 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.

A DRG is a virtual router to which you can attach the following resources:

A DRG can have multiple network attachments of each of the following types:

  • VCN attachments: you can attach multiple VCNs to a single DRG. Each VCN can be in the same or different tenancies as the DRG.
  • RPC attachments: you can peer a DRG to other DRGs (including DRGs in other regions) using remote peering connections.
  • IPSEC_TUNNEL attachments: you can use Site-to-Site VPN to attach two or more IPSec tunnels to your DRG to connect to on-premises networks. This is also allowed across tenancies.
  • VIRTUAL_CIRCUIT attachments: you can attach one or more FastConnect virtual circuits to your DRG to connect to on-premises networks.

Creating DRG route tables and DRG route distributions allows you to define routing policies that route traffic between attachments. Routes can be dynamically imported and exported through these attachments. A route table must be associated with an attachment for that table's configuration to be applied, but an unassociated routing table can exist. DRG route distributions are of an explicit type (either import or export) and do not inherit an action that depends on where they are associated.

Overview of Dynamic Routing Gateways

A DRG acts as a virtual router, providing a path for traffic between your on-premises networks and VCNs, and can also be used to route traffic between VCNs. Using different types of attachments, custom network topologies can be constructed using components in different regions and tenancies. Each DRG attachment has an associated route table which is used to route packets entering the DRG to their next hop. In addition to static routes, routes from the attached networks are dynamically imported into DRG route tables using optional import route distributions.

Working with DRGs and DRG attachments

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

You might 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.

To use a DRG, it must be attached to other network resources. In the API, the process of attaching creates a DrgAttachment object with its own OCID. The DrgAttachment has a type field which denotes the type of object being attached to the DRG. The type field can be set to one of the following values:

  • VCN
  • VIRTUAL_CIRCUIT
  • IPSEC_TUNNEL
  • REMOTE_PEERING_CONNECTION

To attach a VCN to a DRG, use the CreateDrgAttachment operation or the console to explicitly create the DRG attachment object. Attachments for virtual circuits, IPSec tunnels, and remote peering connections are created (and deleted) automatically on your behalf when you create (or delete) the network object.

Working with DRG Route Tables and Route Distributions

A packet entering a DRG is routed using rules in the DRG route table assigned to that attachment. You can assign the same route table to multiple DRG attachments or create a dedicated route table for each attachment depending on the routing policies you want.

When you create a DRG, two default route tables are created for you: one for VCN attachments and one for all other attachments. When a route table is set as the default route table for an attachment type, the table is assigned to newly created attachments of that type unless an alternate table is explicitly specified. Route tables specified as the default for any type cannot be deleted. Ensure that a route table is not currently set as a default route table for an attachment type before trying to delete it.

A VCN attachment has two route tables: One DRG routing table for traffic entering the DRG, and one VCN routing table for traffic entering the VCN. The DRG route table exists in the DRG and is used to route packets entering the DRG through the attachment. The VCN route table is used to route packets entering the VCN through the attachment. If a VCN routing table is not defined, a hidden implicit table always provides connectivity to all subnets in the VCN.

Dynamic Route Import Distributions

A distribution is a list of declarative statements that contain a match criteria (such as an OCID or an attachment type) and an action. You can use route distributions to specify how routes get imported from or exported to a DRG attachment.

DRG route tables contain both static and dynamic routes. Static routes are inserted into tables using the API, while dynamic routes are imported from attachments and inserted using an import route distribution. When a statement's criteria matches on an attachment, the routes associated with the network object being attached to the DRG are dynamically imported into the DRG route table assigned to the containing distribution. If the statement is removed from the distribution, the routes are withdrawn from the DRG route tables. Statements in a route distribution are evaluated in priority order: the lowest number has the highest priority. The order in which statements are evaluated doesn't affect the preference set for the routes they import.

When building route distribution statements in the console, you can create a statement whose match type is "Match All". In the API, encode a "match all" statement by setting the match criteria to the empty list.

How do dynamic routes arrive at an attachment?

Routes to your on-premises networks are advertised from the CPE to IPSec tunnel and virtual circuit attachments using BGP. Routes are dynamically propagated from an RPC attachment on one DRG to an RPC attachment on another DRG through connected RPCs. Dynamic routes in a VCN include either all of the subnet CIDRs or all of the VCN CIDRs and all static route CIDRs configured on the VCN route table associated with the DRG attachment. The vcnRouteType property of the VCN attachment determines whether the subnet CIDRs or VCN CIDRs are propagated into the VCN attachment. The default behavior is to import the subnet CIDRs, but this behavior can be modified when creating or updating the VCN attachment.

Dynamic Route Export Distributions

When an attachment is assigned to a DRG route table, the contents of that table can be dynamically exported to the attachment. If the default export route distribution is assigned to an attachment, the entire contents of the attachment's assigned DRG route table are dynamically exported to the attachment. If you want to disable dynamic route exports to an attachment, use the API operation removeExportDrgRouteDistribution to set the attachment's exportDrgRouteDistributionId field to NULL. Dynamic route export to VCN attachments is not supported.

Route propagation restrictions

Routes imported from an IPSec tunnel or virtual circuit are never exported to other IPSec tunnel or virtual circuit attachments, regardless of how the export route distribution is configured. In a similar vein, packets which enter a DRG through an IPSec tunnel or virtual circuit attachment can never leave through an IPSec tunnel or virtual circuit attachment. Packets are dropped if routing is configured such that packets originating from IPSec tunnel or virtual circuit attachments are sent to IPSec tunnel or virtual circuit attachments.

ECMP

Equal-cost multi-path routing (ECMP) is a feature which allows flow-based load balancing of network traffic over multiple FastConnect virtual circuits or multiple IPSec tunnels (but not a mix of circuit types) using BGP. ECMP allows active-active load balancing and failover of network traffic between a maximum of eight circuits.

Oracle utilizes the protocol, destination IP, source IP, destination port, and source port to distinguish flows for load balancing purposes using a consistent and deterministic algorithm. Therefore, multiple flows are necessary to utilize all available bandwidth.

ECMP is off by default and can be enabled on a per-route table basis. Oracle only considers routes with identical route preference as eligible for ECMP forwarding. See Route Conflicts for more.

Route Source

DRG routes originate as either static routes or as dynamic routes from VCN, IPSec tunnel, FastConnect virtual circuit, or RPC attachments. This origin defines their source, which is an immutable characteristic of the route. In the API, the source is referred to as the routeProvenance of a DrgRouteRule.

Routes are propagated between DRGs using RPC attachments.

Routes with a source of IPSEC_TUNNEL or VIRTUAL_CIRCUIT are not exported to IPSec tunnel or virtual circuit attachments, regardless of the attachment's export distribution.

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 VCN Route Tables.

Required IAM Policy

Peering VCNs using a DRG requires specific IAM permissions. See IAM policies related to DRG peering for details on the permissions needed.

DRG versions

DRGs created before May 17, 2021 use the legacy software, and can be upgraded to the most recent version. DRGs created after that have the upgraded features by default.

The following summarizes the difference between an upgraded and legacy DRG:

A legacy DRG:

  • Has no programmable route tables. It has a default routing behavior where all traffic is forwarded from on-premises to an associated VCN and from the VCN to on-premises.
  • Can attach to a single VCN. The DRG can only be used for remote VCN peering using an RPC.
  • Can attach FastConnect or Site-to-Site VPN, or both. You can only reach resources in the local region using these connections.
  • Can support an RPC connection with a remote DRG-VCN pair in the same tenancy.

An upgraded DRG:

  • Has two route tables by default, and more can be added later.
  • Can have many VCNs attached to it within the same region. Local VCN to VCN traffic can pass through a mutually connected DRG instead of an LPG.
  • Can attach to on-premises using FastConnect orSite-to-Site VPN, or both. You can reach resources in both local and remote regions using these connections.
  • Supports an RPC connection with a DRG/VCN pair in the same or another tenancy.

The rest of this article has recently been updated to reflect the capabilities of an upgraded DRG, as have the common networking scenarios.

Before you upgrade a DRG

To take advantage of enhanced DRG features, upgrade your DRG. The DRG upgrade process is automated, but you must have the required permissions to initiate an upgrade.

Upgrading a DRG is a one-way process with no option to roll back to a legacy DRG after the upgrade process has been initiated.

Expect there to be a traffic outage for all the DRG's attachments during the upgrade process. Each attachment is updated in turn, forcing each upgrading attachment into a provisioning state where it will no longer forward traffic. If you have redundant connections, traffic will failover to other circuits while one is undergoing upgrade. If you only have one circuit, it could go down for about 20 minutes. Any existing BGP sessions for your on-premises connections (FastConnect or Site-to-Site VPN) are also reset while the attachment and any Site-to-Site VPN IPSec tunnels are also brought offline.

For example, if your DRG has two FastConnect virtual circuit attachments, one virtual circuit is upgraded first, causing it to drop connectivity while traffic can pass over the other virtual circuit. After that update has finished, the upgrade process upgrades the second virtual circuit attachment and the completed virtual circuit is brought back online. Expect the upgrade process to last up to 30 minutes per on-premises attachment.

Remote peering connections do not need to be reset like virtual circuit or IPSec tunnel connections do, and do not take the same length of time to upgrade.

Note

Expect a traffic outage during the upgrade process for any components attached to the DRG. Oracle recommends upgrading your DRG during a maintenance window.

After the DRG upgrade process has completed, any Site-to-Site VPN IPSec tunnels are brought back online and all BGP sessions for FastConnect and Site-to-Site VPN are re-established. By default, the upgraded DRG has two autogenerated DRG route tables and import route distributions enabled for your attachments. These resources are designed for backward compatibility with your legacy DRG and allow for all previous communication to resume in the same manner as before the upgrade without any additional user intervention.

For step-by-step instructions on how to upgrade your DRG refer to Upgrading a DRG.

Note

If the DRG upgrade process gets stuck for any reason, create a service request ticket, and mark the ticket as high severity.

Scenarios

We have provided some detailed networking scenarios to help you understand the role of a DRG in the Networking service and how the components work together in general.

DRG Routing

Route Conflicts

If two routes with identical CIDRs are observed the same DRG route table, the DRG resolves the conflict using the following criteria:

  1. Static routes always have higher preference than dynamic routes.

    Note

    You cannot manually specify two static routes with the same CIDR in the same DRG route table, but it's possible for more than one route with the same CIDR to be imported dynamically.
  2. Conflicts between dynamic routes are resolved by first analyzing the route's AS Path:
  3. Otherwise, the attachment type that imported the route is evaluated according to the following priority based on the attachment type:
    1. VCN: the DRG makes an arbitrary but stable selection.
    2. VIRTUAL_CIRCUIT: If ECMP is disabled, the DRG makes an arbitrary but stable selection. If ECMP is enabled, all routes will be added to the route table and the DRG makes routing choices using ECMP. The maximum supported ECMP width inside a DRG is 8.
    3. IPSEC_TUNNEL: If ECMP is disabled, the DRG makes an arbitrary but stable selection.If ECMP is enabled, all routes will be added to the route table and the DRG makes routing choices using ECMP. The maximum supported ECMP width inside a DRG is 8.
    4. REMOTE_PEERING_CONNECTION: The DRG will choose the route with the lowest network distance.

      If two routes have identical network distances, the DRG selects the route with the highest priority route source (STATIC > VCN > VIRTUAL_CIRCUIT> IPSEC_TUNNEL).

      If two routes have the same route source, the DRG makes an arbitrary but stable selection.

  4. If conflicting routes are imported from attachments of the same type, the conflict is resolved differently depending on the attachment type:
    1. VCN attachments: If identical CIDRs are imported from two VCN attachments, only one is selected using an arbitrary but stable decision procedure.
    2. VIRTUAL_CIRCUIT and IPSEC_TUNNEL attachments: If multiple routes with the same CIDR and different AS_PATH lengths are imported into a DRG route table, the route with the lowest AS_PATH length is selected. Otherwise, one route is chosen using an arbitrary but stable decision procedure.
    3. RPC attachments: If identical CIDRs are imported from two RPC attachments, one of them is chosen using an arbitrary stable decision procedure.

You can observe the results of conflict resolution by listing the contents of the route table. Deprecated routes are marked with the "conflict" status.

Using BGP to prefer routes from Oracle to your on-premises network

This section describes in greater detail how the BGP AS_PATH attribute can be used to influence route selection in the context of a single DRG route table.

If the routes for the different paths are the same, Oracle uses the shortest AS path when sending traffic to your on-premises network, regardless of which path was used to initiate the connection to Oracle. Therefore asymmetric routing is allowed. Asymmetric routing here means that Oracle's response to a request can follow a different path than the request. For example, depending on how your edge device (also called your customer-premises equipment, or CPE) is configured, you could send a request over Site-to-Site VPN, but the Oracle response could come back over FastConnect. If you want to force routing to be symmetric, Oracle recommends using BGP and AS path prepending with your routes to influence which path Oracle uses when responding to and initiating connections.

Oracle implements AS path prepending to establish preference on which path to use if your edge device advertises the same route and routing attributes over multiple different connection types between your on-premises network and VCN. The details are summarized in the following table. Unless you're influencing routing in some other way, when the same route is advertised over multiple paths to the DRG at the Oracle end of the connections, Oracle prefers the paths in the following order:

Oracle preference Path Details of how Oracle prefers the path Resulting AS path for the route
1 FastConnect Oracle prepends no ASNs to the routes that your edge device advertises, for a total AS path length of 1. Your ASN
2 Site-to-Site VPN with BGP routing Oracle prepends a single private ASN on all the routes that your edge device advertises over Site-to-Site VPN with BGP, for a total AS path length of 2. Private ASN, Your ASN
3 Site-to-Site VPN with static routing Oracle prepends 3 private ASNs on the static routes that you've provided (Oracle advertises those routes to the dynamic routing gateway (DRG) at the Oracle end of Site-to-Site VPN). This results in a total AS path length of 3. Private ASN, Private ASN, Private ASN

The preceding table assumes you are sending a single autonomous system number in your AS path. Oracle honors the complete AS path you send. If you use static routing, and also send an AS path that has "Your ASN" plus two or more other ASNs, it can cause unexpected behavior because Oracle's routing preference might change.

While policy-based VPN static routing behavior is documented earlier, Oracle also recommends that if you use FastConnect connections with VPN backup, you employ BGP on your IPSec route-based VPN. This strategy allows you to have full control of failover behavior.

Other relevant links

Using the Console

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

  1. Create the DRG.
  2. Attach the DRG to one or more VCNs. You can also attach a DRG to your on-premises network using FastConnect virtual circuits and Site-to-Site VPN IPSec tunnels.
  3. Route subnet traffic to the DRG by updating the route table associated with each subnet that must send traffic to the DRG.
Creating a DRG
Note

A DRG created before April 2021 isn't able to perform transit routing between on-premises networks and multiple VCNs, or provide peering between VCNs. If you require that functionality and you see an Upgrade DRG button, click it. Upgrading the DRG resets all existing BGP sessions and temporarily interrupts traffic from the on-premises network. Once it starts, you can't roll back the upgrade. See Upgrading a DRG.
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
  3. Click Create Dynamic Routing Gateway.
  4. Enter the following items:

    • Create in Compartment: The compartment where you want to create the DRG, which could be different from the compartment you're currently working in.
    • Name: A descriptive name for the DRG. It doesn't have to be unique, and it can be changed later. Avoid entering confidential information.
    • Tags: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
  5. Click Create Dynamic Routing Gateway.

The new DRG is created and then displayed on the Dynamic Routing Gateways page of the compartment you chose. The new DRG is in the "Provisioning" state for a short period. You can connect it to other parts of your network only after provisioning is complete.

Provisioning includes creating two DRG route tables: one route table for connected VCNs and one for other resources such as virtual circuits and IPSec tunnels.

Note

The two default routing tables created implement the same routing behavior used by DRGs created before May 2021 for backward compatibility.
Upgrading a DRG

A DRG created before June 2021 (or April 2021 in San Jose and Montreal regions) must be upgraded before you can connect it to multiple VCNs, use it in cross-tenancy peering scenarios, or modify the internal routing policies. This upgrade process does not change the DRG's OCID. Review Before you upgrade a DRG for more details.

Note

You can't roll back the change to the DRG. Upgrading the DRG resets existing BGP sessions for both Site-to-Site VPN and FastConnect.
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you want to upgrade.
  3. Click Upgrade DRG.
  4. A message appears reminding you the action can't be reversed. Click Upgrade DRG.
  5. The upgrade takes place in the background. You can continue to make configuration settings while the upgrade takes place. You are notified when the upgrade is complete.
  6. When the upgrade finishes, refresh the page to gain access to the new DRG capabilities. Click Refresh page.
Updating the name of a DRG
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you want to update.
  3. Click Edit.
  4. Edit the display name. Avoid entering confidential information.
  5. Click Save Changes.
Attaching a VCN to a DRG
Note

A DRG can be attached to many VCNs, but VCN can be attached to only one DRG at a time. The attachment is automatically created in the compartment that holds the VCN. A VCN does not need to be in the same compartment as the DRG.

Sometimes, you can choose to connect VCNs in the same region using a single DRG instead of local peering gateways. If left unmodified, the default routing policies in a DRG allow traffic to be routed between all VCNs attached to it.

If you are attaching a DRG to a VCN in another tenancy, you need to have IAM configurations in both tenancies as described in IAM policies related to DRG peering.

The following instructions have you navigate to the DRG and then choose which VCN to attach. You could instead navigate to the VCN and then choose which DRG to attach.

  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you want to attach to a VCN.
  3. Under Resources, click Virtual Cloud Networks Attachments.
  4. Click Create Virtual Cloud Network Attachment.
    • (Optional) Give the attachment point a friendly name. If you don't specify a name, one is created for you.
    • Select a VCN from the list. You can also click Change compartment and choose a different compartment that contains a VCN you want to attach to your DRG, then select a VCN from the list.
  5. (Optional) If you're setting up an advanced scenario for transit routing, you can associate a VCN route table with the DRG attachment (you can do this later):
    1. Click Show Advanced Options.
    2. Click the VCN route table tab.
    3. Select the route table that you want to associate with the VCN attachment on the DRG. If you select None, the default VCN route table is used.
  6. If you are planning to use transit routing and need to associate a specific DRG route table to the attachment:
    1. Click Show Advanced Options.
    2. From the DRG route table tab, choose an existing DRG route table. See To create a DRG route table.
  7. (Optional) If you need to specify that you want to import VCN CIDRs into a DRG route table from the VCN attachment:
    1. Click Show Advanced Options.
    2. From the VCN Route type tab, choose VCN CIDRs.

    If you don't explicitly choose VCN CIDRs, Subnet CIDRs is chosen for you and the subnet CIDRs are imported into a DRG route table from the VCN attachment. Routes from the VCN ingress route table are always imported.

  8. When you are finished, click Create VCN attachment.

The attachment is in the "Attaching" state for a short period.

When the attachment is ready, create a route rule in the subnet's route table directing subnet traffic to the DRG. See To route a subnet's traffic to a DRG.

Updating a VCN attachment
  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.
  2. Click the DRG with the attachment you want to update.
  3. Under Resources, click Virtual Cloud Networks attachments.
  4. Click the name of the attachment you want to update.
  5. Click the Edit button.
  6. Change the name of the attachment.
  7. (Optional) Click Show advanced options to change the DRG route table, the VCN route table, or the VCN route type associated with the attachment.
  8. When finished, click Save changes.
Deleting a VCN attachment

How to delete a VCN attachment.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.
  2. Click the DRG with the attachment you want to delete.
  3. Under Resources, click Virtual cloud network attachments.
  4. Click the name of the attachment you want to delete.
  5. Click the Delete button.
  6. Confirm that you want to delete the attachment. Click Delete.
Moving a virtual circuit to a different DRG

When you set up FastConnect, the virtual circuits are attached to a DRG you select. You can move the FastConnect virtual circuits to a different DRG by moving the resource. Moving the virtual circuit deletes an existing attachment and creates an attachment that uses the new DRG's default route table for that attachment type.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.
  2. Select the compartment where the connection resides, and then click a connection to view its details.
  3. Click Move resource or Edit and make your changes. You can change the name of the virtual circuit and change the DRG to which it attaches. Avoid entering confidential information.
    When you move a virtual circuit from one DRG to another DRG, the original DRG attachment is deleted and a new DRG attachment is created. The new attachment uses the target DRG's default route table for that attachment type.
  4. Click Save Changes.
Creating a remote peering connection on a DRG

How to create a remote peering connection attachment from a DRG.

Each administrator creates an RPC for their own VCN's DRG. "You" in the following procedure means an administrator (either the acceptor or requestor).

Note

Required IAM Policy to Create RPCs

If the administrators already have broad network administrator permissions (see Let network admins manage a cloud network), then they have permission to create, update, and delete RPCs. Otherwise, here's an example policy giving the necessary permissions to a group called RPCAdmins. The second statement is required because creating an RPC affects the DRG it belongs to, so the administrator must have permission to manage DRGs.

Allow group RPCAdmins to manage remote-peering-connections in tenancy
Allow group RPCAdmins to manage drgs in tenancy
  1. In the Console, confirm you're viewing the compartment that contains the DRG that you want to add the RPC to. For information about compartments and access control, see Access Control.
  2. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.
  3. Click the DRG you're interested in.
  4. Under Resources, click Remote Peering Connections.
  5. Click Create Remote Peering Connection.
  6. Enter the following:
    • Name: A friendly name for the RPC. It doesn't have to be unique, and it cannot be changed later in the Console (but you can change it with the API). Avoid entering confidential information.
    • Create in compartment: The compartment where you want to create the RPC, which could be different from the compartment you're currently working in.
  7. Click Create Remote Peering Connection.
    The RPC is then created and displayed on the Remote Peering Connections page in the compartment you chose.
  8. If you're the acceptor, record the RPC's region and OCID to later give to the requestor.
  9. If the two VCNs are in different tenancies, record your tenancy OCID (found on the bottom of the page in the Console). Give the OCID to the other administrator so they can create a matching RPC on their DRG.
Editing a DRG attachment
  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Dynamic Routing Gateways.
  2. Click the name of the DRG with the attachment you want to edit.
  3. Under Resources, click the type of the attachment you want to edit.
    • Virtual cloud network attachments
    • Virtual circuit attachments
    • IPSec tunnel attachments
    • Remote peering connection attachments
  4. Click the name of the attachment.
  5. Click Edit.
  6. In the screen that appears, you can rename the attachment and change the associated DRG route table.
To route a subnet's traffic to a DRG

For each VCN subnet that must send traffic to the DRG, you must add a route rule to the VCN route table associated with that subnet. If all the subnets in the VCN use the default route table, you must add a rule to only that one table.

If all non-intra-VCN traffic that's not covered by another rule in the table must be routed to the DRG, add this new rule:

  • Target Type: Dynamic Routing Gateway. The VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself.
  • Destination CIDR Block = 0.0.0.0/0. If you want to limit the rule to a specific network (for example, your on-premises network), then use that network's CIDR instead of 0.0.0.0/0.

For step-by-step instructions, see To update rules in an existing route table.

To create a DRG route table
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
  3. Click the DRG for which you want to create a route table.
  4. Under Resources, click DRG route tables.
  5. Click Create DRG Route Table.
  6. Enter the following items:

    • Name: (Optional) A descriptive name for the route table. Avoid entering confidential information.
    • Destination CIDR: The route table must include at least one destination. You can either enter a destination CIDR, enable import route distribution, or enter nothing and the default CIDR 0.0.0.0/32 is applied, allowing all traffic.
    • Next Hop Attachment Type: Choose between Virtual Cloud Network or Remote Peering Connection, as appropriate for the intended target of the static rule.
    • Next Hop attachment: Choose a VCN, virtual circuit, IPSec tunnel, or remote peering connection attachment.
  7. (Optional) You can also select the following advanced options:
    • Enable Import Route Distribution: This option allows you to assign an import route distribution to the route table so it dynamically learns new routes based on BGP advertisements.
    • Enable ECMP: Equal-cost multi-path routing (ECMP) can be enabled to disambiguate routing decisions when the same destination can be reached from multiple paths.
    • Tags: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
  8. Click Create DRG Route Table.
Viewing the contents of your DRG route table
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
  3. Click the DRG with the route table you want to view.
  4. Under Resources, click DRG route tables.
  5. Click the name of the route table you want to view.
  6. Click Get All Route Rules. The list of routes includes both static routes inserted into the table and all dynamic routes which have been imported from other attachments and inserted using an import route distribution.

    You can use this page to validate and troubleshoot the next hop behavior of traffic entering your DRG. For example, use this functionality to confirm the behavior of traffic destined for your on-premises by validating the routes received by way of your Site-to-Site VPN IPSec tunnel or FastConnect virtual circuit.

  7. Click Close when you are finished.
To associate a VCN route table with an existing DRG attachment
Important

Perform this task only if you're setting up an advanced scenario for transit routing. See Transit Routing inside a hub VCN and Private Access to Oracle Services.

A DRG attachment always has a route table associated with it, but you can associate a different route table, edit the table's rules, or delete some or all rules.

Prerequisites: the VCN that the DRG is already attached to must have a route table.

  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG that is attached to the VCN that has the route table you want to use with the attachment.
  3. Click the Actions menu, and then click either:

    • Associate Route Table: If the DRG attachment has no route table associated with it yet.
    • Associate Different Route Table: If you're changing which route table is associated with the DRG attachment.
  4. Select the route table.
  5. Click Associate Route Table.

The route table is now associated with the DRG attachment.

To add a static rule to a DRG route table
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you're interested in.
  3. Under Resources, click Route Tables.
  4. Click the route table you're interested in.
  5. If you want to create a route rule, click Add Route Rule and enter the following:

    • Target Type: See the list of target types in Overview of Routing for Your VCN. If the target type is a DRG, the VCN's attached DRG is automatically selected as the target, and you don't have to specify the target yourself. If the target is a private IP, before you specify the target you must first disable the source/destination check on the private IP's VNIC. For more information, see Using a Private IP as a Route Target.
    • Destination CIDR Block: Only if the target is not a service gateway. The value is the destination CIDR block for the traffic. A value of 0.0.0.0/0 means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
    • Destination Service: Only if the target is a service gateway. The value is the service CIDR label that you're interested in.
    • Compartment: The compartment where the target is located.
    • Target: The target. If the target is a private IP, enter its OCID. Or you can enter the private IP address itself, in which case the Console determines the corresponding OCID and uses it as the target for the route rule.
    • Description: An optional description of the rule.
  6. If you want to delete an existing rule, click the Actions menu, and then click Remove.
  7. If you wanted to edit an existing rule, click the Actions menu, and then click Edit.
To attach an IPSec connection to a DRG

This process is required when creating a Site-to-Site VPN connection, and is documented in Task 2c: Attach the DRG to the VCN

To delete a DRG

Prerequisites:

  • The DRG can't be currently attached to a VCN.
  • The DRG can't be currently connected to another network by way of Site-to-Site VPN, FastConnect, or remote peering.
  • There can't be a route rule that lists the DRG as a target.
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you're interested in.
  3. Click Terminate.
  4. Confirm when prompted.

The DRG is in the "Terminating" state for a short period while being deleted. The DRG route tables and DRG route distributions contained in the DRG are deleted along with it.

To manage tags for a DRG
  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Click the DRG you're interested in.
  3. Click the Tags tab to view or edit the existing tags. Or click Add Tags to add new ones.

For more information, see Resource Tags.

To move a DRG to a different compartment

You can move a dynamic routing gateway from one compartment to another. When you move a dynamic routing gateway to a new compartment, inherent policies apply immediately.

  1. Open the navigation menu and click Networking. Under Customer Connectivity, click Dynamic Routing Gateway.

  2. Find the DRG in the list, click the Actions menu, and then click Move Resource.
  3. Choose the destination compartment from the list.
  4. Click Move Resource.

For more information about using compartments and policies to control access to your cloud network, see Access Control. For general information about compartments, see Managing Compartments.

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 VCN Route Tables.

Limitations

Some functions might appear to be possible based on the structure of the resource interaction model, but the following functions are not currently allowed:

  1. Explicit creation or deletion of RPC, IPSec tunnel, or virtual circuit attachments
  2. Static routes in DRG route tables with next-hop of IPSec tunnel or virtual circuit attachments
  3. Use of non-default export route distributions
  4. Dynamic route export to VCN attachments
  5. Propagating a route through more than 3 DRG route tables
  6. Routes propagating via RPC through more than 4 DRGs