Local VCN Peering Through an Upgraded DRG
This scenario describes using a mutual connection to an upgraded DRG to enable traffic between two or more VCNs.
Overview
Instead of using local peering connections, you can establish private network communications between two or more virtual cloud networks (VCNs) in the same region by attaching them to a common dynamic routing gateway (DRG) and making appropriate adjustments to VCN and DRG route tables.
This scenario is only available to an upgraded DRG.
If you are using the legacy DRG, you can peer two VCNs in the same region using Local Peering Gateways (LPG) as described in the scenario Local VCN Peering using Local Peering Gateways. Peering two VCNs in the same region through a DRG gives you more flexibility in your routing and simplified management but comes at the cost of microseconds increase in latency due to routing traffic through a virtual router, the DRG.
This sample scenario peers two VCNs. Before you attempt to implement this scenario, be sure that:
- VCN-A is not attached to a DRG
- VCN-B is not attached to a DRG
- VCN-A and VCN-B have non-overlapping CIDRs
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. Most of the steps in this scenario assume the DRG and both VCNs are in the same tenancy.
Steps
Here's the general process for setting up a peering between two VCNs in the same region using a DRG:
- Create the DRG: See Task A: Create a DRG.
- Attach VCN A to the DRG: See Task B: Attach VCN-A to the DRG.
- Attach VCN B to the DRG: See Task C: Attach VCN-B to the DRG.
- Configure route tables in VCN A to send traffic destined to VCN B's CIDR to the DRG: See Task D: Configure route tables in VCN-A to send traffic destined to VCN-B's CIDR to the DRG attachment.
- Configure route tables in VCN B to send traffic destined to VCN A's CIDR to the DRG: See Task E: Configure route tables in VCN-B to send traffic destined to VCN-A's CIDR to the DRG attachment.
- Update security rules: Update each VCN's security rules to enable traffic between the peered VCNs as intended. See Task F: Update security rules.
This page summarizes some access control, security, and performance implications for peered VCNs. You can control access and traffic between two peered VCNs by using IAM policies, route tables in each VCN, route tables in the DRG, and security lists in each VCN.
Summary of Networking components for peering through a DRG
At a high level, the Networking service components required for a local peering through a DRG include:
- Two VCNs with non-overlapping CIDRs, in the same region
- A single Dynamic Routing Gateway (DRG) attached to each peer VCN.
- Supporting route rules to enable traffic to flow over the connection, and only to and from select subnets in the respective VCNs (if wanted).
- Supporting security rules to control the types of traffic allowed to and from the instances in the subnets that need to communicate with the other VCN.
The following diagram illustrates the components.
A given VCN can reach these resources:
- VNICs in the other VCN
- An on-premises network attached to the other VCN, if an advanced routing scenario called transit routing has been set up for the VCNs
Two VCNs interconnected with a DRG cannot reach other cloud gateways (such as an internet Gateway or NAT Gateway) except for transit routing via an LPG. For example, if VCN-1 in the preceding diagram were to have an internet gateway, the instances in VCN-2 could not use it to send traffic to endpoints on the internet. However, VCN-2 could receive traffic from the internet by way of VCN-1. For more information, see Important Implications of VCN Peering.
Important Local Peering Concepts
The following concepts help you understand the basics of VCN peering using a DRG and how to establish a local peering.
- PEERING
- A peering is a relationship between two VCNs that both connect to the same DRG and can mutually route traffic. The local part of local peering indicates that the VCNs are in the same region. A given DRG can have a maximum of 300 local DRG attachments at a time.
- ADMINISTRATORS
- In general, VCN peering can occur only if all involved VCN administrators and DRG administrators agree to it. Depending on the situation, a single administrator might be responsible for all involved DRGs, VCNs, and the related policies.
- ROUTING TO THE DRG
- As part of configuring the VCNs, each administrator must update the VCN's routing to enable traffic to flow between the VCNs. In practice, this looks just like routing you set up for any gateway (such as an internet gateway or dynamic routing gateway). For each subnet that needs to communicate with the other VCN, you update the subnet's route table. The route rule specifies the destination traffic's CIDR and your DRG as the target. Your VCN routes traffic that matches that rule to the DRG, which in turn routes the traffic to the next hop in the other VCN.
- SECURITY RULES
- Each subnet in a VCN has one or more security lists that control traffic in and out of the subnet's VNICs at the packet level. You can use security lists to control the type of traffic allowed with the other VCN. As part of configuring the VCNs, each administrator must determine which subnets in their own VCN need to communicate with VNICs in the other VCN and update their subnet's security lists accordingly.
Setting up this scenario in the console
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.
Clicking the Upgrade DRG button also resets all existing BGP sessions and temporarily interrupt traffic from the on-premises network while the DRG upgrades. Be aware you can't roll back the upgrade.
While working in the same region as the VCNs you want to peer, perform the following steps:
- Open the navigation menu and click Networking. Under Customer connectivity, click Dynamic routing gateway.
- 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.
- Click Create Dynamic Routing Gateway.
-
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.
- 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.
The default upgraded DRG routing tables implement the same routing behavior as legacy DRGs for backward compatibility.
An upgraded DRG can be attached to many VCNs, but a 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 or tenancy as the upgraded 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 upgraded DRG and then choose which VCN to attach. You could instead navigate to the VCN and then choose which DRG to attach.
- Open the navigation menu and click Networking. Under Customer connectivity, click Dynamic routing gateway.
- Click the upgraded DRG you want to attach to VCN A.
- Under Resources, click Virtual cloud network attachments.
- 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.
- (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):
- Click Show Advanced Options.
- Click the VCN route table tab.
- 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.
- 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.
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.
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.
- Open the navigation menu and click Networking. Under Customer connectivity, click Dynamic routing gateway.
- Click the DRG you want to attach to VCN B.
- Under Resources, click Virtual cloud network attachments.
- 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.
- (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):
- Click Show Advanced Options.
- Click the VCN route table tab.
- 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.
- 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:
- Determine which subnets in VCN-A need to communicate with the other VCN.
-
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:
- Open the navigation menu, click Networking, and then click Virtual cloud networks.
- Click the VCN you're interested in, VCN-A.
- Under Resources, click Route Tables.
- Click the route table you're interested in.
-
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.
- 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.
Without the required routing, traffic doesn't flow between the peered VCNs. If a situation occurs where you need to temporarily stop the peering relationship, remove the route rules that enable traffic.
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:
- Determine which subnets in VCN B need to communicate with the other VCN.
-
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:
- Open the navigation menu, click Networking, and then click Virtual cloud networks.
- Click the VCN you're interested in, VCN-B.
- Under Resources, click Route Tables.
- Click the route table you're interested in.
-
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.
- 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.
Without the required routing, traffic doesn't flow between the peered VCNs. If a situation occurs where you need to temporarily stop the peering, you can simply remove the route rules that enable traffic.
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.
The following procedure uses security lists, but you could instead implement the security rules in a network security group and then create the subnet's resources in that NSG.
For each VCN:
- Determine which subnets in your VCN need to communicate with the other VCN.
-
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:
- In the Console, while viewing the VCN you're interested in, click Security Lists.
- Click the security list you're interested in.
- Under Resources, click either Ingress Rules or Egress Rules depending on the type of rule you want to work with.
-
If you want to add a rule, click Add Ingress Rule (or Add Egress Rule).
ExampleLet'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:
- Leave the Stateless checkbox unselected.
- Source Type: Leave as CIDR.
- Source CIDR: Enter the same CIDR block that the route rules use (see Task E: Configure the route tables).
- IP Protocol: Leave as TCP.
- Source Port Range: Leave as All.
- Destination Port Range: Enter 443.
- Description: An optional description of the rule.
- If you want to delete an existing rule, click the , and then click Remove.
- 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.