Local VCN Peering Through an Upgraded DRG

A DRG created before May 2021 is not able to perform routing between on-premises networks and multiple VCNs, or provide local peering between VCNs. If you require that functionality and you see an Upgrade DRG button, click it.

While working in the same region as the VCNs you want to peer, perform the following steps:

1. Open the navigation menu  and select Networking. Under Customer connectivity, select Dynamic routing gateway.
2. Under List Scope, select a compartment that you have permission to work in.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:

   • Name: A descriptive name for the DRG. 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 DRG, which could be different from the compartment you're currently working in.
   • 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're not sure whether to apply tags, skip this option or ask an administrator. You can apply tags later.
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 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 route tables: one route table for connected VCNs and one for other resources such as virtual circuits and IPSec tunnels. The default route tables can't be deleted, but they can be edited. If left unmodified, the default routing policies in a DRG allow traffic to be routed between all VCNs attached to it.

You can eliminate local peering connections from your overall network design if you connect several VPNs in the same region to the same DRG and configure the DRG routing tables appropriately.

Peering VCNs in different tenancies requires more IAM policies for cross-tenancy authorization. See IAM Policies for Routing Between VCNs for details on the permissions needed. When you attach a VCN in a different region to a DRG, use the steps in Attaching a DRG to a VCN in a Different Tenancy.

The following instructions have you navigate to the upgraded 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 select Networking. Under Customer connectivity, select Dynamic routing gateway.
2. Click the upgraded DRG you want to attach to VCN A.
3. Under Resources, click Virtual cloud network attachments.
4. Click Create VCN attachment.
   • (Optional) Give the attachment point a friendly name. If you don't specify a name, one is created for you.
   • Select VCN A from the list. You can also click Change compartment and choose a different compartment if VCN is not in the current compartment, then select VCN A 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. Click Create VCN attachment.

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

When the attachment is ready, create a route rule that directs subnet traffic to this DRG. See To route a subnet's traffic to a DRG.

You can eliminate local peering connections from your overall network design if you connect several VPNs in the same region to the same DRG and configure the DRG routing tables appropriately.

Peering VCNs in different tenancies requires more IAM policies for cross-tenancy authorization. See IAM Policies for Routing Between VCNs for details on the permissions needed. When you attach a VCN in a different region to a DRG, use the steps in Attaching a DRG to a VCN in a Different Tenancy.

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 select Networking. Under Customer connectivity, select Dynamic routing gateway.
2. Click the DRG you want to attach to VCN B.
3. Under Resources, click Virtual cloud network attachments.
4. Click Create VCN attachment.
   • (Optional) Give the attachment point a friendly name. If you don't specify a name, one is created for you.
   • Select VCN B from the list. You can also click Change compartment and choose the compartment that contains VCN B, then select VCN B 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. Click Create VCN attachment.

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

When the attachment is ready, create a route rule that directs subnet traffic to this DRG. See To route a subnet's traffic to a DRG.

As mentioned earlier, each administrator can do this task before or after the VCN is attached to the DRG.

Prerequisite: Each administrator must have the CIDR block or specific subnets for the other VCN.

For VCN A:

1. Determine which subnets in VCN-A need to communicate with the other VCN.

2. Update the route table for each of those subnets to include a new rule that directs traffic destined for the other VCN's CIDR to your DRG:

   1. Open the navigation menu , select Networking, and then select Virtual cloud networks.
   2. Click the VCN you're interested in, VCN-A.
   3. Under Resources, click Route Tables.
   4. Click the route table you're interested in.

   5. Click Add Route Rule and enter the following:

      • Target Type: Dynamic Routing Gateway.
      • Destination CIDR Block: VCN-B's CIDR block. If you want, you can specify a subnet or particular subset of VCN-B's CIDR.
      • Target Compartment: The compartment where the other VCN is located, if not the current compartment.
      • Target: The DRG.
      • Description: An optional description of the rule.
   6. Click Add Route Rule.

Any subnet traffic with a destination that matches the rule is routed to your DRG. For more information about setting up route rules, see VCN Route Tables.

If in the future you no longer need the peering and want to end the peering relationship, first delete all the route rules in your VCN that specify the other as the target.

As mentioned earlier, each administrator can do this task before or after the VCN is attached to the DRG.

Prerequisite: Each administrator must have the CIDR block or specific subnets for the other VCN.

For VCN-B:

1. Determine which subnets in VCN B need to communicate with the other VCN.

2. Update the route table for each of those subnets to include a new rule that directs traffic destined for the other VCN's CIDR to your DRG:

   1. Open the navigation menu , select Networking, and then select Virtual cloud networks.
   2. Click the VCN you're interested in, VCN-B.
   3. Under Resources, click Route Tables.
   4. Click the route table you're interested in.

   5. Click Add Route Rule and enter the following:

      • Target Type: Dynamic Routing Gateway.
      • Destination CIDR Block: VCN-A's CIDR block. If you want, you can specify a subnet or particular subset of VCN A's CIDR block.
      • Target Compartment: The compartment where the other VCN is located, if not in the current compartment.
      • Target: The DRG.
      • Description: An optional description of the rule.
   6. Click Add Route Rule.

Any subnet traffic with a destination that matches the rule is routed to your DRG. For more information about setting up route rules, see VCN Route Tables.

If later on you no longer need the peering and want to end the peering relationship, delete all the route rules in your VCN that specify the other VCN as the target.

As mentioned earlier, each administrator can do this task before or after the connection is established.

Prerequisite: Each administrator must have the CIDR block or specific subnets for the other VCN. In general, use the same CIDR block you used in the route table rule in Task E: Configure the route tables.

What rules should you add?

• Ingress rules for the types of traffic you want to allow from the other VCN, specifically from the VCN's CIDR or specific subnets.
• Egress rule to allow outgoing traffic from your VCN to the other VCN. If the subnet already has a broad egress rule for all types of protocols to all destinations (0.0.0.0/0), then you don't need to add a special one for the other VCN.

For each VCN:

1. Determine which subnets in your VCN need to communicate with the other VCN.

2. Update the security list for each of those subnets to include rules to allow the intended egress or ingress traffic specifically with the CIDR block or subnet of the other VCN:

   1. In the Console, while viewing the VCN you're interested in, click Security Lists.
   2. Click the security list you're interested in.
   3. Under Resources, click either Ingress Rules or Egress Rules depending on the type of rule you want to work with.

   4. If you want to add a rule, click Add Ingress Rule (or Add Egress Rule).

      Example

      Let's say you want to add a stateful rule that enables ingress HTTPS (port 443) traffic from the other VCN's CIDR. Here are the basic steps you take when adding a rule:

      1. Leave the Stateless checkbox unselected.
      2. Source Type: Leave as CIDR.
      3. Source CIDR: Enter the same CIDR block that the route rules use (see Task E: Configure the route tables).
      4. IP Protocol: Leave as TCP.
      5. Source Port Range: Leave as All.
      6. Destination Port Range: Enter 443.
      7. Description: An optional description of the rule.
   5. If you want to delete an existing rule, click the Actions menu (), and then click Remove.
   6. If you wanted to edit an existing rule, click the Actions menu (), and then click Edit.

For more information about security rules, see Security Rules.