OCI – Remote Peering 2 Virtual Cloud Networks across different Regions

In a previous blog, I explained how to local peer two Virtual Cloud Networks (VCNs) located in the same Region. In this blog, I am going to show you how you can remote peer two VCNs located in different Regions. You might want to use this approach for High Availability or Disaster Recovery scenarios or simply to interconnect private workloads across multiple regions. In order to remote peering 2 VCNs, we are going to use a new type of Networking Gateway in Oracle Cloud Infrastructure, called Dynamic Routing Gateway (DRG). It is important to mention that the communication between the 2 regions does not route over the Internet, but via a dedicated network pre-established private fast connection/backbone, so the communication is secured and low latency. Just for the record, DRGs are the same type of gateways that you would use to establish connectivity between any other Data centres (e.g. on-premise DC or other Cloud providers, e.g. AWS, MS Azure, GCP), as well as to establish IPsec VPN connections or during a dedicated Fast Connect Private Peering communication, but that would be another blog.

For this demo, we are going to connect workloads between Phoenix and Ashburn. Each region will have its own VCN and within each VCN we are going to deploy a private subnet with 1 Linux VM, used to test the inter-communication across the regions.

For the purpose of this demonstration, I am going to show how to:

1. Attach and configure DRG to each of your VCNs, located in different regions and establish the remote peering.
2. Configure 2 private VMs, each in a different VCNs (different AD)
3. Use public bastion host to connect to 1 of the private VMs and then confirm connectivity into the other private VM (cross-region connectivity).

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, one in Phoenix and the other in Ashburn:
    • Phoenix VCN-1: 10.105.0.0/24
    • Ashburn VCN-2: 10.105.1.0/24
  • Create 2 subnets in VCN-1:
    • Phoenix VCN-1 private subnet-1: 10.105.0.0/30 (a bit small, as we just need to deploy 1 VM in it)
    • Phoenix VCN-1 public subnet-2: 10.105.0.4/30 (If you choose another subnet range, just make sure you don’t overlap with the existing private subnet)
  • Create 1 private subnet in VCN-2:
    • Ashburn VCN-2 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 2 private subnets:
    • Phoenix > VCN1 > AD1 > Private subnet-1: vm1
      
    • Ashburn > VCN2 > AD2 > Private subnet-3: vm3
      

• For testing purposes, create another VM used as a bastion host in VCN-1 within the public subnet, that way we can jump into one of the 2 private VMs:
  • Phoenix > VCN1 > AD1 > Public subnet-2: vm2 (bastion host)
    
  • Provision 1 Ubuntu VM on each of the 2 private subnets and 1 Ubuntu VM in the public subnet as the bastion host.
    
  • Configure an Internet Gateway as a default destination of Internet traffic into the public subnet route table.

Let’s create the Remote Peering Gateway

Let’s firs create DRG-1 in Phoenix.

• Use the top left burger menu in OCI to go Networking > Dynamic Routing Gateways.
• Click on Create Dynamic Routing Gateway button.

• Call it DRG-1. Click on the create button when ready.

• After a few seconds your DRG will be ready.

• Repeat the same steps to create DRG-2 in Ashburn.

• Now, we have to attach the 2 DRGs into each of their corresponding VCNs. Since we are already in Ashburn, go to VCN-2 and click on Dynamic Routing Gateways on the left menu.

• Click on Attach Dynamic Routing Gateway blue button.
• Search for DRG-2 and click Attach.

• Repeat the same steps to attach DRG-1 into VCN-1 in Phoenix.

• We have to a create routes rule in each of the Private Subnets Route Tables to route the corresponding private traffic via the DRG. That is:
  • Private Subnet 1 > Route Table: Destination block: 10.105.1.0/30 > DRG-1
    
  • Private Subnet 3 > Route Table: Destination block: 10.105.0.0/30 > DRG-2
    

• Lastly, we have to associate a Remote Peering Connection (RPC) on each of the DRGs. These will act as a connection point for a remotely peered VCN.
• First let’s go inside DRG-1 (Phoenix)

• On the left menu, click on Remote Peering Connection.

• Click on Create Remote Peering Connection.
• Call it RPC-1 and click the create button.

• Within a second, RPC-1 should be displayed.

• Repeat the same steps to create another Remote Peering Connection in DRG-2 in Ashburn. Call it RPC-2.

• Great, now on any of the RPCs, hove over the 3 vertical dots icon at the far end and click on Establish Connection.

• Select the region that you want to remote peer into and then enter the OCID of the matching RPC. For example, in the example above since I am establishing the remote peering from RPC-1 in Phoenix, I am going to paste the OCID of RPC-2 in Ashburn.

• After a few seconds, the remote peering will be established. You can tell because the RPC will show Peer region information, for example, from RPC-1 in Phoenix I can see Ashburn:

• And, vice-versa, from Ashburn I can see Phoenix:

• We can now test our Remote peering now. First, SSH into the Bastion Host

  Note: For the following tests, use the private key associated with the public key that you assigned when creating the VMs. There are better ways to do it using dynamic groups, but that’ll be another blog.

• Now, from the bastion host, SSH into VM1 (VCN-1 in Phoenix). For this, use the private IP Address of VM1.

• Ok this was easy, as both VMs are in the same VCN (i.e. VCN-1), so no routing rules are required. Now let’s try something a bit more interesting, from VM1, SSH into VM3 located in VCN-2 in Ashburn (i.e. different region).

• Finally, let’s test the full circuit and from VM3 (Ashburn), SSH into VM1 (Phoenix).

Amazing! Our Remote 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.

Author: Carlos Rodriguez Iturria

I am extremely passionate about people, technology and the most effective ways to connect the two by sharing my knowledge and experience. Working collaboratively with customers and partners inspires and excites me, especially when the outcome is noticeable valuable to a business and results in true innovation. I enjoy learning and teaching, as I recognise that this is a critical aspect of remaining at the forefront of technology in the modern era. Over the past 10+ years, I have developed and defined solutions that are reliable, secure and scalable, working closely with a diverse range of stakeholders. I enjoy leading engagements and am very active in the technical communities – both internal and external. I have stood out as a noticeable mentor running technology events across major cities in Australia and New Zealand, including various technology areas such as, Enterprise Integrations, API Management, Cloud Integration, IaaS and PaaS adoption, DevOps, Continuous Integration, Continuous Automation among others. In recent years, I have shaped my role and directed my capabilities towards educating and architecting benefits for customers using Oracle and AWS Cloud technologies. I get especially excited when I am able to position both as a way to exceed my customers’ expectations. I hold a bachelor degree in Computer Science and certifications in Oracle and AWS Solutions Architecture. View all posts by Carlos Rodriguez Iturria