Local VCN Peering (Within Region)

This topic is about local VCN peering. In this case, local means that the VCNs reside in the same region. If the VCNs are in different regions, see Remote VCN Peering (Across Regions).

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 Local VCN Peering

Local VCN peering is the process of connecting two VCNs in the same region so that their resources can communicate using private IP addresses without routing the traffic over the internet or through your on-premises network. The VCNs can be in the same Oracle Cloud Infrastructure tenancy  or different ones. Without peering, a given VCN would need an internet gateway and public IP addresses for the instances that need to communicate with another VCN.

For more information, see Access to Other VCNs: Peering.

Summary of Networking Components for Peering

At a high level, the Networking service components required for a local peering include:

  • Two VCNs with non-overlapping CIDRs, in the same region
  • A local peering gateway (LPG) on each VCN in the peering relationship.
  • A connection between those two LPGs.
  • Supporting route rules to enable traffic to flow over the connection, and only to and from select subnets in the respective VCNs (if desired).
  • 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.

This image shows the basic layout of two VCNs that are locally peered, each with a local peering gateway.

Note

A given VCN can use the peered LPGs to 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

A VCN can't use its peered VCN to reach other destinations outside of the VCNs (such as the internet). 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, be aware that VCN-2 could receive traffic from the internet by way of VCN-1. For more information, see Important Implications of VCN Peering.

Explicit Agreement Required from Both Sides

Peering involves two VCNs that might be owned by the same party or two different ones. The two parties might both be in your company but in different departments. Or the two parties might be in entirely different companies (for example, in a service-provider model).

Peering between two VCNs requires explicit agreement from both parties in the form of Oracle Cloud Infrastructure Identity and Access Management policies that each party implements for their own VCN's compartment  or tenancy. If the VCNs are in different tenancies, each administrator must provide their tenancy OCID and put in place special policy statements to enable the peering.

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. As part of the scenario, the VCN that is acting as the hub has a route table associated with each LPG (typically route tables are associated with a VCN's subnets).

When you create an LPG, you can optionally associate a route table with it. Or if you already have an existing LPG without a route table, you can associate a route table with it. The route table must belong to the LPG's VCN. A route table associated with an LPG can contain only rules that use the VCN's attached DRG as the target.

An LPG can exist without a route table associated with it. However, after you associate a route table with an LPG, 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.

Important Local Peering Concepts

The following concepts help you understand the basics of VCN peering and how to establish a local peering.

PEERING
A peering is a single peering relationship between two VCNs. Example: If VCN-1 peers with three other VCNs, then there are three peerings. The local part of local peering indicates that the VCNs are in the same region. A given VCN can have a maximum of ten local peerings at a time.
Warning

The two VCNs in the peering relationship must not have overlapping CIDRs. However, if VCN-1 is peered with three other VCNs, those three VCNs can have overlapping CIDRs with each other. You would set up the subnets in VCN-1 to have route rules that direct traffic to the targeted peered VCN.
VCN ADMINISTRATORS
In general, VCN peering can occur only if both of the VCN administrators agree to it. In practice, this means that the two administrators must:
  • Share some basic information with each other.
  • Coordinate to set up the required Oracle Cloud Infrastructure Identity and Access Management policies to enable the peering.
  • Configure their VCNs for the peering.
Depending on the situation, a single administrator might be responsible for both VCNs and the related policies.
For more information about the required policies and VCN configuration, see Setting Up a Local Peering.
ACCEPTOR AND REQUESTOR
To implement the IAM policies required for peering, the two VCN administrators must designate one administrator as the requestor and the other as the acceptor. The requestor must be the one to initiate the request to connect the two LPGs. In turn, the acceptor must create a particular IAM policy that gives the requestor permission to connect to LPGs in the acceptor's compartment . Without that policy, the requestor's request to connect fails.
LOCAL PEERING GATEWAY (LPG)
A local peering gateway (LPG) is a component on a VCN for routing traffic to a locally peered VCN. As part of configuring the VCNs, each administrator must create an LPG for their VCN. A given VCN must have a separate LPG for each local peering it establishes (maximum ten LPGs per VCN). To continue with the previous example: VCN-1 would have three LPGs to peer with three other VCNs. In the API, a LocalPeeringGateway is an object that contains information about the peering. You can't reuse an LPG to later establish another peering.
PEERING CONNECTION
When the requestor initiates the request to peer (in the Console or API), they're effectively asking to connect the two LPGs. The requestor must have information to identify each LPG (such as the LPG's compartment and name, or the LPG's OCID). Each administrator must put the required IAM policies in place for their compartment or tenancy.
Either VCN administrator can terminate a peering by deleting their LPG. In that case, the other LPG's status switches to REVOKED. The administrator could instead render the connection non-functional by removing the route rules or security rules that enable traffic to flow across the connection (see the next sections).
ROUTING TO THE LPG
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 LPG as the target. Your LPG routes traffic that matches that rule to the other LPG, which in turn routes the traffic to the next hop in the other VCN.
In the following diagram, VCN-1 and VCN-2 are peered. Traffic from an instance in Subnet A (10.0.0.15) that is destined for an instance in VCN-2 (192.168.0.15) is routed to LPG-1 based on the rule in Subnet A's route table. From there the traffic is routed to LPG-2, and then from there, on to its destination in Subnet X.
This image shows the route tables and path of traffic routed from one local peering gateway to the other.
Note

As mentioned earlier, a given VCN can use the peered LPGs to reach VNICs in the other VCN, or the on-premises network if transit routing is set up for the VCNs. But a VCN can't use the peered VCN to reach other destinations outside of the VCNs (such as the internet). For example, in the preceding diagram, VCN-2 cannot use the internet gateway attached to VCN-1.

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.
If you use network security groups (NSGs) to implement security rules, notice that you have the option to write security rules for an NSG that specify another NSG as the source or destination of traffic. However, the two NSGs must belong to the same VCN.

Important Implications of VCN Peering

If you haven't yet, read Important Implications of Peering to understand important access control, security, and performance implications for peered VCNs.

Setting Up a Local Peering

Here's the general process for setting up a peering between two VCNs in the same region:

  1. Create the LPGs: Each VCN administrator creates an LPG for their own VCN.
  2. Share information: The administrators share the basic required information.
  3. Set up the required IAM policies for the connection: The administrators set up IAM policies to enable the connection to be established.
  4. Establish the connection: The requestor connects the two LPGs.
  5. Update route tables: Each administrator updates their VCN's route tables to enable traffic between the peered VCNs as desired.
  6. Update security rules: Each administrator updates their VCN's security rules to enable traffic between the peered VCNs as desired.

If desired, the administrators can perform tasks E and F before establishing the connection. In that case, each administrator must know the CIDR block or specific subnets from the other's VCN and share that in task B. After the connection is established, you can also get the CIDR block of the other VCN by viewing your own LPG's details in the Console. Look for Peer Advertised CIDR. Or if you're using the API, see the peerAdvertisedCidr parameter.

Task A: Create the LPGs

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

Note

Required IAM Policy to Create LPGs

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 LPGs. Otherwise, here's an example policy giving the necessary permissions to a group called LPGAdmins. The second statement is required because creating an LPG affects the VCN it belongs to, so the administrator must have permission to manage VCNs.

Allow group LPGAdmins to manage local-peering-gateways in tenancy
Allow group LPGAdmins to manage vcns in tenancy
  1. In the Console, confirm you're viewing the compartment that contains the VCN that you want to add the LPG to. For information about compartments and access control, see Access Control.
  2. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  3. Click the VCN you're interested in.
  4. Under Resources, click Local Peering Gateways.
  5. Click Create Local Peering Gateway.
  6. Enter the following:

    • Name: A friendly name for the LPG. 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 LPG, if different from the compartment you're currently working in.
    • Associate with Route Table (optional): Only if you're setting up the advanced routing scenario called transit routing. Select the compartment that contains the route table you want to associate with the LPG, and the route table itself. You can skip this part and associate the LPG with a route table later if you like.
    • Tags: Optionally, you can apply tags. If you have permissions to create a resource, 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 if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  7. Click Create Local Peering Gateway.

    The LPG is then created and displayed on the Local Peering Gateways page in the compartment you chose.

Task B: Share information

If you're the requestor, give this information to the acceptor (for example, by email or other out-of-band method):

  • If the VCNs are in the same tenancy: Name of the IAM group that should be granted permission to create a connection in the acceptor's compartment. In the example in the next task, the group is RequestorGrp.
  • If the VCNs are in different tenancies: OCID for your tenancy, and OCID for the IAM group that should be granted permission to create a connection in the acceptor's compartment. In the example in the next task, it's the OCID for the RequestorGrp.
  • Optional: Your VCN's CIDR, or specific subnets for peering with the other VCN.

If you're the acceptor, give this information to the requestor:

  • If the VCNs are in the same tenancy: OCID for your LPG. Optionally, also the names of your VCN, LPG, and the compartment each is in.
  • If the VCNs are in different tenancies: OCID for your LPG, and OCID for your tenancy.
  • Optional: Your VCN's CIDR, or specific subnets for peering with the other VCN.
Task C: Set up the IAM policies (VCNs in same tenancy)

In this version of task C, both VCNs are in the same tenancy. If they're in different tenancies, instead see Task C: Set up the IAM policies (VCNs in different tenancies).

Both the requestor and acceptor must ensure that the right policies are in place:

  • Policy R (implemented by the requestor):

    Allow group RequestorGrp to manage local-peering-from in compartment RequestorComp

    The requestor is in an IAM group called RequestorGrp. This policy lets anyone in the group initiate a connection from any LPG in the requestor's compartment (RequestorComp). Policy R can be attached to either the tenancy (root compartment) or to RequestorComp. For information about why you would attach it to one versus the other, see Policy Basics.

  • Policy A (implemented by the acceptor):

    Allow group RequestorGrp to manage local-peering-to in compartment AcceptorComp
    
    Allow group RequestorGrp to inspect vcns in compartment AcceptorComp
    
    Allow group RequestorGrp to inspect local-peering-gateways in compartment AcceptorComp
    

    The first statement in the policy lets the requestor connect to any LPG in the acceptor's compartment (AcceptorComp). This statement reflects the required agreement from the acceptor for the peering to be established. Policy A can be attached to either the tenancy (root compartment) or to AcceptorComp.

    Tip

    The second and third statements in Policy A let the requestor list the VCNs and LPGs in AcceptorComp. The statements are required for the requestor to use the Console UI to select from a list of VCNs and LPGs in AcceptorComp and establish the connection. The following diagram focuses only on the first statement, which is the critical one that permits the connection.

This image shows the two policies for VCNs in the same tenancy.

Both Policy R and Policy A give RequestorGrp access. However, Policy R has a resource-type called local-peering-from, and Policy A has a resource-type called local-peering-to. Together, these policies let someone in RequestorGrp establish the connection from an LPG in the requestor's compartment to an LPG in the acceptor's compartment. The API call to create the connection specifies which two LPGs.

Tip

The permission granted by Policy R might already be in place if the requestor has permission in another policy to manage all of the Networking components in RequesterComp. For example, there might be a general Network Admin policy like this:

 Allow group NetworkAdmin to manage virtual-network-family in compartment RequestorComp

If the requestor is in the NetworkAdmin group, then they already have the required permissions covered in Policy R (the virtual-network-family includes LPGs). And further, if the policy is instead written to cover the entire tenancy instead of only compartment RequestorComp, then the requestor already has all the required permissions in both compartments to establish the connection. In that case, policy A is not required.

Task C: Set up the IAM policies (VCNs in different tenancies)

In this version of task C, the VCNs are in different tenancies (in other words, it's a cross-tenancy peering). If the VCNs are in the same tenancy, instead see Task C: Set up the IAM policies (VCNs in same tenancy).

Both the requestor and acceptor must ensure that the right policies are in place:

  • Policy R (implemented by the requestor):

    Define tenancy Acceptor as <acceptor_tenancy_OCID>
    
    Allow group RequestorGrp to manage local-peering-from in compartment RequestorComp
    
    Endorse group RequestorGrp to manage local-peering-to in tenancy Acceptor
    
    Endorse group RequestorGrp to associate local-peering-gateways in compartment RequestorComp
       with local-peering-gateways in tenancy Acceptor

    The requestor is in an IAM group called RequestorGrp. This policy lets anyone in that group initiate a connection from any LPG in the requestor's compartment (RequestorComp).

    The first statement is a "define" statement that assigns a friendly label to the acceptor's tenancy OCID. The statement happens to use "Acceptor" as the label, but it could be a value of the requestor's choice. All "define" statements in a policy must be the first ones (at the top).

    The second statement lets the RequestorGrp establish a connection from an LPG in the requestor's compartment.

    The third and fourth statements are special ones required because the LPGs are in different tenancies. They let the RequestorGrp connect an LPG in the requestor's tenancy to an LPG in the acceptor's tenancy.

    If the desire is to give the RequestorGrp permission to connect to an LPG in any tenancy, the policy would instead look like this:

    
    Allow group RequestorGrp to manage local-peering-from in compartment RequestorComp
    
    Endorse group RequestorGrp to manage local-peering-to in 
    
    any-tenancy
    
    
    
    Endorse group RequestorGrp to associate local-peering-gateways in compartment RequestorComp
        with local-peering-gateways in 
    
    any-tenancy
    
    

    Regardless, Policy R must be attached to the requestor's tenancy (root compartment), and not the requestor's compartment. Policies that enable cross-tenancy access must be attached to the tenancy. For more information about attachment of policies, see Policy Basics.

  • Policy A (implemented by the acceptor):

    Define tenancy Requestor as <requestor_tenancy_OCID>
    
    Define group RequestorGrp as <RequestorGrp_OCID>
    
    Admit group RequestorGrp of tenancy Requestor to manage local-peering-to in compartment AcceptorComp
    
    Admit group RequestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy Requestor
        with local-peering-gateways in compartment AcceptorComp

    Similar to the requestor's policy, this policy first uses "define" statements to assign friendly labels to the requestor's tenancy OCID and the RequestorGrp OCID. As mentioned earlier, the acceptor could use other values for those labels if desired.

    The third and fourth statements let the RequestorGrp connect to an LPG in the acceptor's compartment (AcceptorComp). These statements reflect the critical agreement required for the peering to be established. The word Admit indicates that the access applies to a group outside the tenancy where the policy resides.

    Policy A must be attached to the acceptor's tenancy (root compartment), and not the acceptor's compartment.

This image shows the two policies for VCNs in different tenancies.

Task D: Establish the connection

The requestor must perform this task.

Prerequisite: The requestor must have the OCID of the acceptor's LPG.

Tip

If you're using the Console and the peering is between two VCNs in the same tenancy: Instead of specifying the acceptor's LPG OCID, you can instead pick the acceptor's VCN and LPG from lists of resources in the tenancy. However, you need to know both the name and compartment for the acceptor's VCN and LPG instead of the LPG's OCID. For reference, see Task B: Share information.
  1. In the Console, view the details for the requestor LPG that you want to connect to the acceptor LPG.
  2. For the requestor LPG, click the Actions icon (three dots), and then click Establish Peering Connection.
  3. Specify which LPG you want to peer with:

    • If the VCNs are in different tenancies: Select Enter Local Peering Gateway OCID, and enter the acceptor LPG's OCID.
    • If the VCNs are in the same tenancy: Do one of the following:

      • Select Enter Local Peering Gateway OCID, and enter the acceptor LPG's OCID.
      • Select Browse Below, and then select the acceptor's VCN and LPG from the lists provided. Remember that the VCN and LPG each might be in a different compartment than the one you're currently working in.
  4. Click Establish Peering Connection.

The connection is established and the LPG's state changes to PEERED.

At this point, the details of each LPG update to show the Peer VCN CIDR Block for the other VCN. This is the CIDR of the other VCN across the peering from the LPG. Each administrator can use this information to update the route tables and security rules for their own VCN.

Task E: Configure the route tables

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. If the connection is already established, look at the Peer VCN CIDR Block for your LPG in the Console. Otherwise, get the information from the other administrator by email or other method.

For your own VCN:

  1. Determine which subnets in your VCN 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 LPG:

    1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
    2. Click the VCN you're interested in.
    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: Local Peering Gateway.
      • Destination CIDR Block: The other VCN's CIDR block. If you want, you can specify a subnet or particular subset of the peered VCN's CIDR.
      • Target Compartment: The compartment where the LPG is located, if not the current compartment.
      • Target: The LPG.
      • 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 LPG. For more information about setting up route rules, see Route Tables.

Later, if you no longer need the peering and want to delete your LPG, you must first delete all the route rules in your VCN that specify the LPG as the target.

Tip

Without the required routing, traffic doesn't flow between the peered LPGs. If a situation occurs where you need to temporarily stop the peering, you can simply remove the route rules that enable traffic. You don't need to delete the LPGs.
Task F: Configure the security rules

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, you should 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.
Note

The following procedure uses security lists, but you could instead implement the security rules in a network security group and then create all of the subnet's resources in that NSG.

For your own 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 desired 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 new 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 check box 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 icon (three dots), and then click Remove.
    6. If you wanted to edit an existing rule, click the Actions icon (three dots), and then click Edit.

For more information about security rules, see Security Rules.

Using the Console

To associate a route table with an existing local peering gateway

This task is related to an advanced routing scenario called transit routing.

An LPG can exist without a route table associated with it. However, after you associate a route table with an LPG, 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.

Prerequisite: The route table must exist and belong to the VCN that the LPG belongs to.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Local Peering Gateways.
  4. For the LPG you're interested in, click the Actions icon (), and then click either: 

    • Associate With Route Table: If the LPG has no route table associated with it yet.
    • Replace Route Table Association: If you're changing which route table is associated with the LPG.
  5. Select the compartment where the route table resides, and select the route table itself.
  6. Click Associate.
To delete a local peering gateway

Prerequisite: First delete all the route rules in your VCN that specify the LPG as the target. Deleting those rules stops the routing in your VCN to the LPG. However, the LPG's state may still be PEERED if the other LPG still exists. Whenever an LPG is deleted, the LPG at the other side of the peering changes to the REVOKED state.

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Click the VCN you're interested in.
  3. Click Local Peering Gateways.
  4. For the LPG you want to delete, click the Actions icon (three dots), and then click Terminate.
  5. Confirm when prompted.
Note

After deleting an LPG (and thus terminating a peering), it's recommended you review your security rules to remove any rules that enabled traffic with the other VCN.

To manage tags for a local peering gateway
  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Local Peering Gateways.
  4. Click the Actions icon (three dots) for the local peering gateway, and then click View Tags. From there you can view the existing tags, edit them, and apply new ones.

For more information, see Resource Tags.

To move a local peering gateway to a different compartment

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

  1. Open the navigation menu. Under Core Infrastructure, go to Networking and click Virtual Cloud Networks.
  2. Click the VCN you're interested in.
  3. Under Resources, click Local Peering Gateways.
  4. Click the Actions icon (three dots) for the local peering gateway, and then click Move Resource.
  5. Choose the destination compartment from the list.
  6. 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.