Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone:

Use Rapid Clone to create template files for cloning on the Source System. After copying the Source System to the Target System, Rapid Clone updates these templates to include the new Target System configuration settings. Rapid Clone never changes the Source System configuration.

What is cloning:

Cloning is the process of creating a copy of an existing Oracle E-Business Suite system.
Cloning process consists of the following three phases, each of which is made up of several logical sections and their steps.

• Prepare the Source System for database tier and application tier. 
• Copy both database tier and application tier nodes from the Source System to Target System. 
• Configure the Target System for both database tier and application tier.

For Oracle E-Business Suite Release 12.2 system that is on the AD-TXK Delta 6 or lower codelevel.

Prepare the Source System for database tier and application tier:

Prepare the Source System database tier for cloning :

Execute the following commands:

$ cd <RDBMS ORACLE_HOME>/appsutil/scripts/<CONTEXT_NAME> 

$ perl adpreclone.pl dbTier

• It’s create the clone directory >$ORACLE_HOME/appsutil/clone/directory
• Obtains Database Information and Creates adcrdbclone.sql

Prepare the Source System application tier for cloning:

Source the environment file of the Run Edition File system.

To Verify:

$ echo $FILE_EDITION

should return the value:

run

Execute the following commands:

$ cd <INST_TOP>/admin/scripts

$ perl adpreclone.pl appsTie

It will collect all the information about the source system, creates a cloning stage area, and generates templates and drivers. All of these are to reconfigure the instance on a Target machine.

Adpreclone.pl process on the application tier creates a complete compressed archive of the Oracle Fusion Middleware and its components as follows:

A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home: 

<COMMON_TOP>/clone/FMW/FMW_Home.jar

A compressed archive of the Oracle E-Business Suite WebLogic domain:

<COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar

The Oracle E-Business Suite WebLogic domain's configuration template:

<COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml

A compressed archive of the Oracle Web Tier/Oracle HTTP Server configuration instance:

<COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

The Oracle HTTP Server configuration instance's configuration template:

<COMMON_TOP>/clone/FMW/OHS/moveplan.xml

These jar files created in clone directory are sufficent to clone the FMW home,So we dont need to copy FMW home in the clone process from source to target

>>>It’s create the Clone directory in application side >cd $COMMON_TOP/clone

Log Location:

adpreclone log files are created in the <INST_TOP>/admin/log/clone directory.

Copy both database tier and application tier nodes from the Source System to the Target System:

Database:

Copy the Source System database ORACLE_HOME to the Target System.

Use , Tar or cp

Copy the application tier file system from the Source "Run Edition File System" to the Target "Run Edition File System":

Copy the following application tier directories from the Source Node to the Target Run Edition File System application tier node:

<APPL_TOP> 

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

Configure the Target System:

Configure the Target System database:

$ cd <RDBMS ORACLE_HOME>/appsutil/clone/bin
$ perl adcfgclone.pl dbTechstack
$perl adcfgclone.pl dbTier <Database Target context file>  (when using previous context file).


log file is created in <RDBMS_ORACLE_HOME>/appsutil/log/<CONTEXT_NAME> directory.

Options:

Database Node: dbTier   | database | dbconfig | dbTechStack 

dbTier :
configure the ORACLE_HOME on the target database tier node and  recreate the controlfiles.

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• Configure the ORACLE_HOME
• Recreate the control files
• Start SQL*Net Listener

dbTechStack :
configure the ORACLE_HOME on the target database tier node only.

• Create the context file
• Register ORACLE_HOME
• Configure the ORACLE_HOME
• Start SQL*Net Listener

dbconfig :
configure the database with  context file.Database should be in open mode.

• This scripts configure the database

database:

• Configure the ORACLE_HOME
• Recreate the control files
• Start SQL*Net Listener

Configure the Target System application tier :

$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

At the prompt “Target System Base Directory”, enter the location of the base directory. For example: /<SID>/applmgr.

When asked the question:
Do you want to startup the Application Services for mult35? (y/n)” you should answer ‘n’.

log files are created in the <INST_TOP>/admin/log/clone directory in the Run Edition File System.

Option:

Application Node: appsTier | appltop  | atTechStack

 atTechStack:

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• Configure the ORACLE_HOME
• Create INST_TOP
• Start SQL*Net Listener

appltop:

• Configure the apple top
• Create INST_TOP
• Start SQL*Net Listener

appsTier

• It’s Create the context file
• Register the ORACLE_HOME
• Relink the ORACLE_HOME
• It’s create the INST_TOP
• Configure APPL_TOP
• Start APPS Process

Copy the following Oracle E-Business Suite application directories from the Run Edition File System to the Patch Edition File System.

<APPL_TOP>
<COMMON_TOP>
<OracleAS Tools 10.1.2 ORACLE_HOME>

Log on to the Patch Edition File System in the Target System as the applmgr user and enter the following commands:
$ cd <COMMON_TOP>/clone/bin
$ perl adcfgclone.pl appsTier

The Patch Edition File System must be aware of the location of the Run Edition File System that will be configured in the next step. At the prompt “Location of Run System Context File”, enter the absolute path to the context file for the Run Edition File System that was created in the previous step.

For exmp:/<SID>/applmgr/fs1/inst/apps/TEST_<servername>/appl/admin/TEST_<servername>.xml.

log files are created in the <INST_TOP>/admin/log/clone directory in the Patch Edition File System.

start the services from run file system

=========================================================================

High level Steps:-

PART 1 : PREREQUISITE TASKS

—————————-

– check for in-progress online patching cycle

PART 2 : PREPARE SOURCE SYSTEM

——————————

perl adpreclone.pl dbTier

perl adpreclone.pl appsTier

**require Apps User password and Weblogic AdminServer password

In 12.2, the adpreclone.pl process on the application tier creates a complete compressed archive of the Oracle Fusion Middleware and its components

PART 3 : COPY APPLICATION TIER NODE

———————————–

Copy Application Tier node from the Source “Run Edition File System” to the Target “Run Edition File System”.

so if source run edition is fs2, then target run edition will also be fs2

Only copy “EBSapps” directory from under $RUN_BASE. DO NOT COPY “inst” or “FMW_Home”

PART 4 : COPY DATABASE TIER NODE

——————————–

do normal RMAN cloning

PART 5 : CONFIGURE TARGET DATABASE SYSTEM

—————————————–

SQL> exec fnd_conc_clone.setup_clean;

$ perl adconfig.pl dbTier

PART 6 : CONFIGURE TARGET APPLICATION SYSTEM

——————————————–

$ perl adcfgclone.pl appsTier

RUN ADPRECLONE ON RUN EDITION <<< NEW STEP IN R12.2

COPY TARGET RUN EDITION OVER TARGET PATCH EDITION <<< NEW STEP IN R12.2

RUN ADCFGCLONE ON TARGET APPLICATION NODE PATCH EDITION <<< NEW STEP IN R12.2

PART 7 : FINISHING TASKS

————————-

Update profiles, workflow settings, SESSION_COOKIE_DOMAIN, SSL and SSO configuration as required

Changing SYS/SYSTEM/APPS/SYSADMIN/OTHER ORACLE passwords as per business requirements

• Run adpreclone on the source database and application nodes.

• Back up the full Container Database (CDB) database with archives by using RMAN Hot backup and copy it to the target node.

• Clean up the target database and application node.

• Copy the source application binaries and database binaries to the target node.

• Configure $Oracle_Home on the target database node.

• Restore and recover the databases.

• Perform post-restore steps on the Target database node.

• Configure the application on the target application node.

• Perform post-clone steps on the application node.

• Start the target application services.

Oracle EBS Cloning steps are as follows.

1. Running Pre-Clone on the Source Apps Tier and DB Tier
2. Backup Full database and Archivelogs via RMAN
3. Copy Some Application Tier directories from Source to Target
4. Copy Oracle database Home and backups from Source to Target
5. Configure and start Oracle Instance on Target
6. Duplicate & Restore and Recover database and open clone database on Target
7. Run Post Clone Steps on Target Database Server ( DB Tier )
8. Run Post Clone Steps on Target Application Server ( Apps Tier )
9. Run Pre-Clone on the Target Apps Tier for Creating Patch edition
10. Copy EBSpps directory from Run edition to patch edition on Target Application server
11. Run Post Clone on Patch Edition of Target Application server
12. Start EBS Clone Environment

https://ittutorial.org/ebs-cloning-ebs-clone-oracle-r12-2-e-business-suite-step-by-step-cloning-ebs-clone/

=========================================================================

Adpreclone.pl on the Application Tier 

The adpreclone.pl process on the Application Tier creates a complete compressed archive of the Oracle Fusion Middleware and its components as follows:  A compressed archive of the Oracle WebLogic Server home, Oracle Web Tier Utilities home, Oracle Common Utilities home and the Oracle E-Business Suite home:

<COMMON_TOP>/clone/FMW/FMW_Home.jar

A compressed archive of the Oracle E-Business Suite Weblogic domain:

 <COMMON_TOP>/clone/FMW/WLS/EBSdomain.jar

 The Oracle E-Business Suite Weblogic domain’s configuration template:

 <COMMON_TOP>/clone/FMW/WLS/plan/moveplan.xml

A compressed archive of the Oracle Web Tier/Oracle HTTP Server Cloning Oracle E-Business Suite with Rapid Clone 17-9 configuration instance:

 <COMMON_TOP>/clone/FMW/OHS/ohsarchive.jar

The Oracle HTTP Server configuration instance’s configuration template:

<COMMON_TOP>/clone/FMW/OHS/moveplan.xml

****The 'dualfs' option will clone the Run and Patch file systems in a single operation.

$ perl adcfgclone.pl appsTier dualfs

Adding a New Application Tier Node to an Existing System:

• add it to the existing Applications system, a process also known as scale up or scale out.
• Before adding a new node, you should update the tcp.invited_nodes parameter of sqlnet.ora on the database tier to include the host.domain of the new node being added.
• The addition of nodes should not be done during an active adop cycle.

Steps for adding a node on a non-shared file system:

1.Run adpreclone.pl on both the Run and Patch Edition File Systems in the primary application tier node of the E-Business Suite instance

Note: Before executing this step, ensure the AdminServer on both the Run Edition File System and the Patch Edition File System is running. The AdminServer on the Patch Edition File System can be shut down after completion of adpreclone.pl.

2.Copy the Run Edition File System to the Target secondary node.

Only the following directories should be copied:

<APPL_TOP>

<COMMON_TOP>

<OracleAS Tools 10.1.2 ORACLE_HOME>

The secondary node must be on a different host.

3.Configure both Run and Patch Edition File Systems in the Target secondary node.

Note: Before executing these steps, ensure the AdminServer on both the Run Edition File System and the Patch Edition File System is running. This is required for adcfgclone.pl to properly register the new node on the Oracle E-Business Suite instance.

The adcfgclone.pl script can be executed in either the interactive mode or in the non-interactive mode for adding the node. You can choose one of the two options.

Running adcfgclone.pl in the interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl appsTier dualfs

When asked the questions:

"Do you want to add a node (yes/no)" you should answer 'yes'

"Do you want to startup the Application Services for <TWO_TASK>? (y/n)" you should answer 'y' if the Application services are to be started up. Otherwise, you should answer 'n'.

Note: Ensure that the port pool provided for the Run Edition File System is different from the port pool of the Patch Edition File System of the primary node. Otherwise, it will result in errors during execution of fs_clone.

As mentioned earlier, the function (run or patch) of the two file systems is not static, and their values switch every time when a cutover phase is complete. Hence, refer to the environment variables $RUN_BASE and $PATCH_BASE to determine the Run Edition File System and Patch Edition File System respectively. 

Running adcfgclone.pl in the non-interactive mode

Execute the following command:

$ cd <COMMON_TOP>/clone/bin

$ perl adcfgclone.pl component=appsTier pairsfile=<PAIRSFILE> addnode=yes dualfs=yes

The sample pairsfile for application tier is delivered under INST_TOP of each file system in the location <INST_TOP>/appl/admin/<CONTEXT_NAME>.txt. It should be updated to have values corresponding to the node being added.

Note:

Ensure the following while setting values in the pairs file:

The value of 's_shared_file_system' should be set to 'false' and the value of 's_atName' should be set to the hostname of the node being added.

The port pool provided for the Run Edition File System is different from the port pool of the Patch Edition File System of the primary node. Otherwise, it will result in errors during execution of fs_clone. As mentioned earlier, the function (run or patch) of the two file systems is not static, and their values switch every time when a cutover phase is complete. Hence, refer to the environment variables $RUN_BASE and $PATCH_BASE to determine the Run Edition File System and Patch Edition File System respectively.

The value of 'patch_s_port_pool' for the port pool of the Patch Edition File System is provided correctly.

5.Register the new topology from the newly added application tier node.

If OHS is enabled on the newly added node, perform the following steps on that node:

Source the Run Edition File System.

The OHS configuration files mod_wl_ohs.conf and apps.conf will contain entries of managed servers from all application tier nodes. If any of these managed servers are not desired to be part of the cluster configuration on the current node, execute the following command to delete details of these managed servers from the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \

  -contextfile=<CONTEXT_FILE> \

  -configoption=removeMS \

  -oacore=<host>.<domain>:<port>  \  

  -oafm=<host>.<domain>:<port> \

  -forms=<host>.<domain>:<port> \ 

  -formsc4ws=<host>.<domain>:<port> \

  -ekanban=<host>.<domain>:<port> \

  -accessgate=<host>.<domain>:<port> \

  -yms=<host>.<domain>:<port>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:

<host>.<domain>:<port>

host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

For example, to delete references of managed servers oacore_server1 on 'testserver1' and forms_server2 on host 'testserver2' on the domain 'example.com' with ports 7201 and 7601 respectively, the following command should be executed:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \

  -configoption=removeMS -oacore=testserver1.example.com:7201 -forms=testserver2.example.com:7601

  

  

Perform the following steps on the other application tier nodes participating in the same cluster where this node is added:

Source the Run Edition File System.

If any of the managed servers from the newly added node are desired to be part of the cluster configuration on the current node, execute the following command to add details of these managed servers into the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \

  -contextfile=<CONTEXT_FILE> \

  -configoption=addMS \

  -oacore=<host>.<domain>:<port> \

  -oafm=<host>.<domain>:<port> \

  -forms=<host>.<domain>:<port> \

  -formsc4ws=<host>.<domain>:<port>

where

The argument contextfile accepts the complete path to the context file.

The arguments oacore, oafm, forms, formsc4ws accept a comma-separated list of managed server details in the following format:

<host>.<domain>:<port>

host and domain are the hostname and domain name of the newly added node

port is the port of the new managed server whose reference is to be added

For example, if the newly added node on host 'testserver1' and domain 'example.com' contains managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the following command should be executed:

$ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE> \

-configoption=addMS -oacore=testserver1.example.com:7205 -oafm=testserver1.example.com:7605

6.On all application tier nodes, perform the following steps to register the newly added application tier node with the application tier TNS Listener (FNDFS listener) on each node:

Source the Run Edition file system.

Run AutoConfig.

On UNIX:

$ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh

Reload the application tier TNS Listener (FNDFS listener) as follows:

$ lsnrctl reload APPS_<TWO_TASK>

Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1)

Cloning Oracle E-Business Suite Release 12.2 with Multitenant Database using Rapid Clone (Doc ID 2552208.1)

https://www.funoracleapps.com/2022/04/ebs-step-by-step-oracle-apps-cloning.html

How to clear lock on web logic

Clear lock:

cd $DOMAIN_HOME/servers/AdminServer
mv tmp tmp_bkp
mv cache cache_bkp

cd data/ldap/ldapfiles
mv EmbeddedLDAP.lok EmbeddedLDAP.lok_bkp2

cd ../../store/default
 mv _WLS_ADMINSERVER000000.DAT _WLS_ADMINSERVER000000.DAT_bkp2

cd ../diagnostics
mv WLS_DIAGNOSTICS000000.DAT WLS_DIAGNOSTICS000000.DAT_bkp2

VCN:Virtual Cloud Network:

Basic terminology of VCN:

When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources.

VCN:Virtual Cloud Network:

A virtual, private network that you set up in Oracle data centers.

A Virtual Cloud Network (VCN) is a virtual version of a traditional network including subnets, route tables, and gateways on which your compute instances run.

A VCN is a customizable private network in Oracle Cloud Infrastructure.

A VCN resides within a single region but can cross multiple Availability Domains.VCN is specific to a region.

When you create your VCN, you assign a contiguous IPv4 CIDR block of your choice. VCN sizes ranging from /16 (65,533 IP addresses) to /30 (1 IP address) are allowed. Example: 10.0.0.0/16, 192.168.0.0/24.


Default Components that Come With Your VCN .Your VCN automatically comes with these default components:

Default route table, with no rules
Default security list, with default rules
Default set of DHCP options, with default values.

***Virtual Cloud Network (VCN) is a virtual network in which you can create subnets, route tables and gateways for your compute instances.

There are two options for creating VCN in OCI:
Create Virtual Cloud Network only: Creates a Virtual Cloud Network only. You’ll still need to set up at least one subnet, gateway and route rule to have a working Virtual Cloud Network.
Create Virtual Cloud Network plus related resources: Automatically sets up a Virtual Cloud Network with access to the internet. You can set up firewall rules and Security Lists to control ingress and egress traffic to your Instances. All related resources will be created in the same Compartment as the VCN.

SUBNET:
Each VCN network is subdivided into subnets.

Subnets can be either AD-specific or regional.Oracle recommends using regional subnets because they're more flexible.They make it easier to efficiently divide your VCN into subnets while also designing for availability domain failure.

Subnets contain virtual network interface cards (VNICs), which attach to instances. Instances are placed in subnets and can live across.

All VNICs in a given subnet use the same route table, security lists, and DHCP options

Instances draw their internal IP address and network configuration from their subnet.

Each subnet has a contiguous range of IPs, described in CIDR notation. Subnet IP ranges cannot overlap.

Subnets can be designated as either
• Private (instances contain private IP addresses assigned to vNICs)
• Public (contain both private and public IP addresses assigned to vNICs)
 > Public has access to internet but private don't have and both types of subnets can co-exist in the same VCN.

Can have multiple subnet in an AD.

***Subnets: They are a logical subdivisions of the VCN and they contain virtual network interface cards (VNICs), which attach to instances.

VNIC:
A virtual network interface card (VNIC), which attaches to an instance and resides in a subnet to enable a connection to the subnet's VCN.The VNIC determines how the instance connects with endpoints inside and outside the VCN. Each instance has a primary VNIC that's created during instance launch and cannot be removed. You can add secondary VNICs to an existing instance (in the same availability domain as the primary VNIC), and remove them as you like. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in the same availability domain as the instance.

SECURITY LISTS:

Virtual firewall rules for your VCN.

Security Lists provides two types of traffic:

• ingress: Incoming traffic
• Egress:Outgoing traffic.

You can choose whether a given rule is stateful or stateless.

For example, you can allow incoming SSH traffic from anywhere to a subnet's instances by setting up a stateful ingress rule with source CIDR 0.0.0.0/0, and destination TCP port 22.

***Security Lists: They have ingress and egress rules that specify the types of traffic (protocol and port) allowed in and out of the instances.

ROUTE TABLES:

Route Table is used to send traffic out of the VCN.

VCN comes with an empty default route table, and you can add custom route tables of your own.

Consists of a set of route rules; each rule specifies
• Destination CIDR block
• Route Target (the next hop) for the traffic that matches that CIDR.

Each subnet uses a single route table specified at time of subnet creation, but can be edited later.

Route table is used only if the destination IP address is not within the VCN's CIDR block

No route rules are required in order to enable traffic within the VCN itself

When you add an internet gateway, NAT gateway, service gateway, dynamic routing gateway or a peering connection, you must update the route table for any subnet that uses these gateways or connection.

***Route Tables: They have rules to route traffic from subnets to destinations outside the VCN by way of gateways or specially configured instances.

DHCP OPTIONS:

Configuration information that is automatically provided to the instances when they boot up.

***DHCP Options: Configuration information that is automatically provided to the instances when they boot up.

PRIVATE IP:
A private IP address and related information for addressing an instance (for example, a hostname for DNS).

Each VNIC has a primary private IP, and you can add and remove secondary private IPs.

The primary private IP address on an instance doesn't change during the instance's lifetime and cannot be removed from the instance.


PUBLIC IP:

A public IP address and related information. You can optionally assign a public IP to your instances or other resources that have a private IP. Public IPs can be either ephemeral or reserved.

DYNAMIC ROUTING GATEWAY (DRG):

It provides a path for private network traffic between your VCN and on-premises network. You can use it with other Networking components and a router in your on-premises network to establish a connection by way of IPSec VPN or Oracle Cloud Infrastructure FastConnect. It can also provide a path for private network traffic between your VCN and another VCN in a different region.

***You can think of a DRG as a virtual router that provides a path for private traffic (that is, traffic that uses private IPv4 addresses) between your VCN and networks outside the VCN's region.

You use a DRG when connecting your existing on-premises network to your virtual cloud network (VCN) with one (or both) of these:
IPSec VPN
Oracle Cloud Infrastructure FastConnect

You also use a DRG when peering a VCN with a VCN in a different region:
Remote VCN Peering (Across Regions)

A DRG is a standalone object. To use it, you must attach it to a VCN. A VCN can be attached to only one DRG at a time, and a DRG can be attached to only one VCN at a time.You can detach a DRG and reattach it at any time.

After attaching a DRG, you must add a route for the DRG in the VCN's route table to enable traffic flow

The VCN has three gateways:

INTERNET GATEWAY:

Internet gateway provides a path for network traffic between your VCN and the interne.
You can have only one internet gateway for a VCN.
After creating an internet gateway, you must add a route for the gateway in the VCN's Route Table to enable traffic flow.

NETWORK ADDRESS TRANSLATION (NAT) GATEWAY:

NAT gateway gives an entire private network access to the internet without assigning each host a public IP address.

Hosts can initiate outbound connections to the internet and receive responses, but not receive inbound connections initiated from the internet. Use case: updates, patches)(Connections can be initiated only from the subnet. )

You can have more than one NAT gateway on a VCN, though a given subnet can route traffic to only a single NAT gateway

It gives cloud resources without public IP addresses access to the internet without exposing those resources to incoming internet connections.


SERVICE GATEWAY:

It provides a path for private network traffic between your VCN and supported services in the Oracle Services Network (examples: Oracle Cloud Infrastructure Object Storage and Autonomous Database). For example, DB Systems in a private subnet in your VCN can back up data to Object Storage without needing public IP addresses or access to the internet.

Use case: back up DB Systems in VCN to Object Storage)

LOCAL PEERING GATEWAY (LPG):

It lets you peer one VCN with another VCN in the same region. Peering means the VCNs communicate using private IP addresses, without the traffic traversing the internet or routing through your on-premises network.

A given VCN must have a separate LPG for each peering it establishes.

REMOTE PEERING CONNECTION (RPC):

A component that you can add to a DRG. It lets you peer one VCN with another VCN in a different region.