In a previous blog, I explained how to get started with Oracle Cloud Infrastructure Networking primitives to allow Internet traffic into your Virtual Cloud Network. In this blog, I will show you how to peer 2 different Virtual Cloud Networks (VCNs), using VMs across different Availability Domains (AD) in the same region. For this, we are going to use a new type of OCI Networking Gateway, called Local Peering Gateway (LPG).
In Oracle Cloud Infrastructure, VCN are regional and subnets can be configured as regional resources too. This means that they can span across multiple Availability Domains within the same region (normally 3 ADs per region). For this demo, we are going to provision a private VM in a different Availability Domain (AD), each in a different VCN, so that we can make sure that we can establish connectivity across 2 VMs located in different VCNS and Ads, via the Local Peering
For the purpose of this demonstration, I am going to show how to:
- Attach LPG to each of your VCNs in the same region and establish the local peering.
- Configure 2 private VMs, each in a different VCNs (different AD)
- Use public bastion host to connect to 1 of the private VMs and then confirm connectivity into the other private VM.
This is a high-level visual representation:
Ok, let’s have fun!!!
Before we start
In this blog I assume the following:
- You have an Oracle Cloud account, if not request a free trial. Here: https://cloud.oracle.com/tryit
In this blog, I assume that you are familiar with basic OCI primitives, such as Networking VCNs, subnets, Internet Gateways and compute resources. If you are not, refer to my previous blog.
Create 2 VCNs in your region of choice:
- VCN1: 10.105.0.0/24
- VCN2: 10.105.1.0/24
Create 2 private subnets. One in each VCN:
- VCN1 private subnet: 10.105.0.0/30 (a bit small, as we just need to deploy 1 VM in it)
- VCN2 private subnet: 10.105.1.0/30 (a bit small, as we just need to deploy 1 VM in it)
Provision 1 Ubuntu VM on each of the private subnets. Make sure to choose a different Availability Domain for each VM.
- Region 1 > VCN1 > AD1 > Private subnet: vm1
- Region 1 > VCN2 > AD2 > Private subnet: vm2
For testing purposes, create a public subnet and bastion host in one of the existing VCNs:
- VNC2 > public subnet: 10.105.1.4/30 (If you choose another subnet range, just make sure you don’t overlap with the existing private subnet)
- Provision a bastion host Linux VM, so that we can jump into one of the 2 private VMs.
- Configure an Internet Gateway as a default destination of Internet traffic into the public subnet route table.
Let’s create the Local Peering Gateway
Now that you have already created 2 VCNs and 2 private subnets as indicated earlier, now we are going to create 1 Local Peering Gateway within each if the 2 VCNs.
- Go to your VCN1 and under Resources click on Local Peering Gateway
- Click on Create Local Peering Gateway blue button.
- Call it lpg1 and associated within your compartment of choice. Then click on create.
- The new LPG will be shown.
- Repeat the same steps for another LPG (lpg2) under VCN2.
Now let’s update each of the Route tables associated with each private subnet to route traffic via the corresponding LPG.
- Go to VCN1 > Subnets > Private subnet 1
- Click on its associated Route Table
Create Add Route Rules button
- Target Type: Local Peering Gateway
- Destination CIDR Block: 10.105.1.0/30
- Target Local Peering Gateway: lpg1
- Now repeat the previous steps to add a Route Rule from Private Subnet 2 (VCN2) to route all 10.105.0.0/30 traffic over lpg2.
Activate the Local Peering Gateway Communication
As you probably observed from the last previous steps, the LPGs are created, but their status is still “Not connected”. Let’s connect them now.
- Go to VCN1 > Local Peering Gateways
- Locate lpg1 and hove over the right most contextual menu
- Select Establish Peering Connectivity.
- Since we are in VCN1 (lpg1), let’s connect into VCN2 – lpg2. Then click on Establish Peering Connectivity.
- The status should change from Pending/Connecting into a solid green Available (Peered Connected to a Peer).
That’s it, now we can test our communication between VMs.
- SSH into the bastion host in your public subnet
Confirm connectivity into VM2 located in the same VCN (VCN2) using its assigned Private IP Address (i.e. 10.105.1.2 in this case). This is easy, as both subnets live in the same VCN, so no routing rules are required.
You need to create a new file with the private key associated with VM2 (there are better ways to do it using dynamic groups, but that would be another blog).
Now, from VM2, confirm connectivity into VM1, using its assigned Private IP Address (10.105.0.2 in this case)> This is more interesting, as VM1 resides in a different VCN and AD (VCN1 > AD1).
For this, you might have to create a new file with the private key associated with VM1
Great, our Local VCN Peering works. Now let’s finish testing the full circuit, coming back from VM1 into VM2.
Once again, you might have to create a new file with the private key associated with VM2
Amazing! Our Local Peering works bi-directionally, congratulations!!!
I hope you found this blog useful. If you have any question or comment, feel free to contact me directly at https://www.linkedin.com/in/citurria/
Thanks for your time.