Note:

• This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
• It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.

Set up RPC Connection between Two Tenants and their Dynamic Routing Gateways

Introduction

In a multi-tenant Oracle Cloud Infrastructure (OCI) environment, enabling secure and efficient communication between different tenants is crucial for hybrid and distributed network architectures. One way to achieve this is by setting up a Remote Peering Connection (RPC) between two tenants and their corresponding Dynamic Routing Gateways (DRGs).

Objectives

• Configure an RPC between two DRGs in separate OCI tenants, ensuring seamless connectivity across networks. By the end, you will have a working RPC setup that allows secure traffic flow between the tenants, helping you build robust multi-tenant architectures in OCI.

Prerequisites

• Access to Two OCI Tenants: You need administrator or appropriate permissions in both OCI tenants to configure networking components.

• DRGs in Both Tenants: Each tenant must have a DRG already created and attached to a Virtual Cloud Network (VCN).

• Region Compatibility: The DRGs must be in the same or different OCI commercial regions that support RPC. Cross-region RPC is supported, but both regions must be accessible. The Requestor needs to be subscribed to the Acceptor region.

• Public or Private Connectivity: Decide whether you will allow communication over private IPs and ensure proper subnet CIDR blocks are planned to avoid conflicts.

• VCNs and Routing Configuration: The VCNs in both tenants should have properly configured route tables and security lists to allow traffic over the RPC.

• Policies for Cross-Tenant Peering: Ensure that Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) policies are in place to allow DRG peering across different OCI tenants. You may need to define policies for both tenants to establish trust.

Task 1: Determine the Requestor and the Acceptor Tenant

In Oracle Cloud Infrastructure (OCI), when setting up cross-cloud communications or resource sharing, it is critical to define which tenant is the Requestor and which is the Acceptor in terms of OCI IAM policies. These roles are governed by OCI IAM policies, which define permissions for users, groups, and compartments.

By defining the Requestor and Acceptor roles clearly within OCI IAM policies, you ensure that permissions are correctly set up to allow secure, controlled access to resources across OCI tenants and compartments. Both tenants need to work together to ensure that the appropriate permissions are granted and that OCI IAM policies are set in a way that adheres to security best practices.

• Requestor Tenant: The Requestor is the OCI tenant (or specific compartment within a tenant) that initiates a request for access to resources from another OCI tenant or compartment. The Requestor’s OCI IAM policies must grant the necessary permissions to access the Acceptor’s resources. For example, the Requestor might need to create a policy that allows their users to access a resource in the Acceptor tenant.

  The Requestor must also ensure that the right OCI IAM roles are assigned to the users or groups making the request.

• Acceptor Tenant: The Acceptor is the OCI tenant (or compartment) that receives the access request and grants the necessary permissions to the Requestor. The Acceptor’s OCI IAM policies must define which actions the Requestor can perform and which resources they can access. The Acceptor’s policies should also specify the users or groups who are allowed to accept such requests, ensuring that access is securely managed.

  In addition to granting access, the Acceptor should configure OCI IAM policies to specify what the Requestor is authorized to do, ensuring proper scope and least privilege principles are followed.

The following image shows an example of two tenants that are connected with each other with RPC where one of them is defined as the Requestor (REQ) and the other is the Acceptor (ACC).

Task 2: Subscribe the Acceptor Region to the Requestor Region

In the context of setting up RPC between two OCI tenants, the Requestor needs to be subscribed to the Acceptor tenants region, while the Acceptor does not need to be subscribed to the Requestor region. Here is why:

Why the Requestor needs to be subscribed to the Acceptor tenant:

• Initiating Communication: The Requestor tenant is the entity that initiates the RPC by sending requests to the Acceptor tenant. To allow for this communication, the Requestor needs to be subscribed to the Acceptor, which enables it to recognize and connect to the Acceptor’s network and services.

• Establishing Trust and Connectivity: By subscribing to the Acceptor tenant, the Requestor tenant establishes the necessary trust and connectivity to interact with the Acceptor’s environment. The subscription ensures that the Requestor can route traffic and requests properly to the Acceptor’s services over the peering connection.

Why the Acceptor does not need to be subscribed to the Requestor tenant:

• Passive Role of the Acceptor: The Acceptor tenant only receives requests from the Requestor tenant; it does not initiate any communication. Because the Acceptor is only responding to the requests made by the Requestor, it does not need to subscribe to the Requestor. It simply needs to be accessible and configured to handle incoming requests.

• One-Way Communication: RPCs are typically set up with a one-way communication flow where the Requestor is the initiator. The Acceptor does not require a subscription to the Requestor tenant, as it does not need to initiate or manage outgoing connections.

In summary, the Requestor must subscribe to the Acceptor to initiate RPCs and establish connectivity, while the Acceptor only needs to be configured to respond to requests and does not require a subscription to the Requestor tenant.

In the following image you will see an example of the Requestors OCI Console. Notice that the Requestor is subscribed to the Acceptors region.

In the following image you will see an example of the Acceptors OCI Console. Notice that the Acceptors are not subscribed to the Requestors region.

Task 3: Gather the Required Parameters

Gather the required parameters to create the OCI IAM policy for the Requestor and the Acceptor side. Here is the table showing the fields required in the OCI IAM policy for both the Acceptor and Requestor tenants when setting up Remote Procedure Call access in OCI:

Information Required	Requestor Tenant	Acceptor Tenant
Tenancy OCID	X	X
Group Name	X
Group OCID	X
Compartment Name	X	X

Make sure that this information is gathered from both sides before creating the OCI IAM policy.

Task 4: Create and Configure the OCI IAM Policy on the Requestor and the Acceptor Side

The official OCI IAM policy documentation to make the RPC work can be found here: Remote Peering with an Upgraded DRG.

When you look at the policies you will see that in the OCI IAM policy for the Requestor, some information is required from the Acceptor, and for the Acceptor OCI IAM policy some information is required from the Requestor. This makes it sometimes confusing to create the policies, and if the policies are not correct the RPC will not come up, and troubleshooting will be hard.

To overcome this problem, we have created the RPC IAM Policy Tool. There are more RPC network architectures available but the RPC IAM Policy Tool can only be used if you are trying to create an RPC between two different OCI tenants where each tenant has their own DRG.

In the following image you will see the form that the RPC IAM Policy Tool will provide you to insert all the required details. The form will ask for more information that is actually required, but it is good practice to have all the information in one place before you start configuring the RPC and the OCI IAM policies on the Acceptor and Requestor side.

The Requestor information and parameters are marked with the Red color and the Acceptor information and parameters are marked with the Blue color.

The following image shows an example of all the information filled in. Enter all the required fields and click Submit.

The tool will generate the following information:

• A diagram with the parameters you used to put things into perspective.
• A table with all the parameters you used (so you can screenshot this, or copy-paste this into your notes for reference later).
• The OCI IAM policy for the Requestor.
• The OCI IAM policy for the Acceptor.

Task 4.1: Create and Configure the OCI IAM Policy on Requestor Side

1. Log in to the OCI Console, navigate to Identity & Security and click Policies.

2. Make sure to select the root compartment and click Create Policy.

   

3. Enter the following information and click Create.

   • Enter a Name and a Description for the policy.
   • Select Show manual editor.
   • Copy/paste the policy statements for the Requestor side into the policy.

   

   When you create the policy you will see the policy statements configured.

   

   When you go back to the policy overview page you will see the policy configured.

   

Task 4.2: Create and Configure the OCI IAM Policy on Acceptor Side

1. Log in to the OCI Console, navigate to Identity & Security and click Policies.

2. Make sure to select the root compartment and click Create Policy.

   

3. Enter the following information and click Create.

   • Enter a Name and a Description for the policy.
   • Select Show manual editor.
   • Copy/paste the policy statements for the Requestor side into the policy.

   

   When you create the policy you will see the policy statements configured.

   

   When you go back to the policy overview you will see the policy configured.

   

Task 5: Configure the DRG Attachments on the DRG on the Requestor and the Acceptor side

We need to create a RPC on the Requestor and Acceptor side.

Task 5.1: Create RPC on Requestor Side

1. Go to the OCI Console, navigate to Networking and click Dynamic Routing Gateways.

2. Click Remote peering connection attachments and Create remote peering connection.

   

3. Enter name and click Create remote peering connection.

   

Task 5.2: Create RPC on Acceptor Side

1. Go to the OCI Console, navigate to Networking and click Dynamic Routing Gateways.

2. Click Remote peering connection attachments and Create remote peering connection.

   

3. Enter name and click Create remote peering connection.

   

4. Collect the RPC OCID from the Acceptor side as we need to use this OCID to establish the RPC connection from the Requestor side.

   

Task 6: Establish the Connection from the Requestor Side

1. Go to the OCI Console from Requestor side, navigate to Networking, Dynamic Routing Gateways and click Remote peering connection attachments.

2. Click the remote peering connection (configured for the Acceptor side) created in Task 5.

3. Click Establish connection.

   

4. Enter the following information and click Establish connection.

   • Select the Region of the Acceptor.
   • Paste the RPC OCID collected in Task 5.

   

   If the Requestor is subscribed to the Acceptor region and the right OCI IAM policies are configured and the right RPC OCI the peering status should change to Peered on the Requestor side.

   

   You can click the RPC to look at additional information on the peering.

   • Note that the Peer Status is Peered.
   • Note that the Peer Region is Jeddah.
   • Note that this is a Cross Tenancy Peering.

   

5. We can also verify the peering status on the Acceptor side.

   1. Go to the OCI Console from Acceptor side, navigate to Networking, Dynamic Routing Gateways and click Remote peering connection attachments.

   2. Click the remote peering connection configured for the Requestor side.

   3. Note that the Peering status is also set to Peered on the Acceptor side.

   

   You can click the RPC to look at additional information on the peering.

   • Notice the Peer Status is Peered.
   • Notice the Peer Region is Riyadh.
   • Notice that this is a Cross Tenancy Peering.

   

Task 7: Design RPC Architectures with Three or More Tenants

It is also possible to create RPC connections between more than two sites or tenants.

• In the following image you can see we have used three different tenants:

  • OCI Riyadh (Requestor)
  • OCI Jeddah (Acceptor)
  • OCI Dubai (Acceptor)

  In this example, Riyadh will be some kind of hub site that will act as the Requestor for two Acceptors.

  

• In the following image you can see we have used three different tenants:

  • OCI Riyadh (Requestor)
  • OCI Jeddah (Requestor + Acceptor)
  • OCI Dubai (Acceptor)

  In this example, Riyadh will be the Requestor for Jeddah and Jeddah will be the Requestor for Dubai.

  

• In the following image you can see we have used three different tenants:

  • OCI Riyadh (Requestor + Acceptor)
  • OCI Jeddah (Acceptor)
  • OCI Dubai (Requestor)

  In this example, Riyadh will be the Requestor for Jeddah and the Acceptor for Dubai.

  

Conclusion

Setting up a RPC between two OCI tenants requires careful planning, precise configuration, and the correct OCI IAM policies. By following this step-by-step tutorial, you have successfully established a secure and functional RPC between two DRGs in separate tenants. This connection enables seamless communication across networks, a crucial component for building scalable and multi-tenant OCI architectures.

To simplify the process and eliminate potential policy errors, the RPC IAM Policy Tool provides an easy way to generate the required OCI IAM policies for both the Requestor and Acceptor tenants. Ensuring that your policies, DRG attachments, and regional subscriptions are correctly configured will guarantee a smooth peering setup.

Beyond basic RPC configurations, designing multi-tenant architectures with three or more tenants adds further flexibility and scalability to your OCI network. Understanding the role of each tenant—whether as a Requestor, Acceptor, or both—allows you to build robust, interconnected environments that support hybrid and distributed workloads efficiently.

By leveraging OCI’s networking capabilities, you can create secure, scalable, and high-performance cross-tenant architectures that align with enterprise networking best practices. If you encounter issues, revisiting OCI IAM policies and DRG configurations is a great first step in troubleshooting.

With this knowledge in hand, you are now well-equipped to establish and expand RPC connections in Oracle Cloud Infrastructure to meet your organization’s networking requirements.

Acknowledgments

• Author - Iwan Hoogendoorn (OCI Network Specialist)

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

---

Title and Copyright Information

Set up RPC Connection between Two Tenants and their Dynamic Routing Gateways

G30553-02

Copyright ©2025, Oracle and/or its affiliates.