X

Easily Connect Isolated Networks using Oracle Cloud Infrastructure's VCN Peering Solution: Part 1

Vijay Kannan
Principal Product Manager

This is part one of a two-part series that will look at Oracle Cloud Infrastructure's Local VCN peering solution. You can find the part two of the series here.

Virtual Cloud Network (VCN) is a customizable private network in Oracle Cloud Infrastructure. Oracle Cloud Infrastructure now enables customers to connect two virtual cloud networks using our VCN peering solution.

The Oracle Cloud Infrastructure VCN peering solution falls into two major categories:

  • Local VCN peering (or Intra-region peering) which refers to connecting two VCNs within the same region and tenancy. Oracle Cloud Infrastructure supports peering between two VCNs that are in the same tenancy (whether they are in the same compartment or not), or in different tenancies.

  • Remote VCN peering (or Inter-region VCN peering) which refers to connecting two VCNs across two different regions.

This blog describes the Local VCN peering solution in detail. 

Oracle Cloud Infrastructure's local VCN peering solution offers customers many benefits:

  • A no cost, reliable alternative to connectivity models such as VPN by eliminating internet gateways, encryption, and performance bottlenecks.

  • Ease of peering enablement between Oracle VCNs with no scheduled downtime.

  • Private connectivity for resources in peered virtual cloud networks using Oracle Cloud Infrastructure fabric’s highly redundant links with predictable bandwidth and latency.

In some cases, VCNs are owned by the same company but in different departments. In other cases, the two VCNs are in different companies (a.k.a a service-provider model). Our local VCN peering solution supports many use cases by allowing customers to deploy multiple VCNs (within their governance boundaries) and providing private connectivity across the VCNs by the appropriate use of policies such as security rules and routing rules.

  • Access to peer resources:  Traditionally, large enterprises have one or more virtual cloud networks with their operational isolation and business goals. Each business unit can deploy and operate resources independently. In this scenario, resources that are required by two business units (such as forecast tracking, budgetary information, and employee data) tend to get duplicated in both the virtual network boundaries. This situation often results in increased compute expenses and triggers additional cost to sync the versions of these applications and data. Local VCN peering provides private access to the resources in the peered VCN, eliminating duplicate resources and reducing OPEX.

  • Access to centralized resources (hub and spoke model): Customers can realize significant TCO benefits from Local VCN peering solution by deploying all shared resources (such as logging server, DNS servers, Active Directory, etc.)  on a single Hub VCN.  Other VCNs (spokes) are then allowed to peer with the shared (Hub) VCN. 

Setting Up VCN Local Peering

In reality, the two VCNs can be in different tenancies/compartments and can have different administrators

  • Administrators create Local Peering Gateways (LPG) on each VCN.

  • Administrators of these VCNs have to provide explicit agreement to enable the peering relationship. They must share information using out-of-band mechanisms and set up Identity and Access Management (IAM) policies for their own VCN’s compartment and tenancy.

    • If the two VCNs are in same tenancy and same compartment, the same network administrator will most likely have access to information from both VCNs and can proceed to create a peering between the VCNs

    • If the two VCNs are in same tenancy, but in different compartments:

      • The administrator of the VCN which is accepting the peering connection shares information such as VCN’s name, compartment name and LPG name.

      • The administrator of the VCN which is initiating the peering connection shares information such as the name of the IAM group.

    • If the two VCNs are in different tenancies:

      • The administrator of the VCN which is accepting the peering connection shares their tenancy OCID (Oracle Cloud Indentifier) and the LPG’s OCID and sets up special policy statements to accept the peering connection.

      • The administrator of the VCN which is initiating the peering connection shares the tenancy and the administrator group’s OCID and sets up policy statements to initiate the peering connection.

  • Administrators establish a peering relationship between the VCNs. This involves creating a peering connection between the two LPGs. The peering connection indicates permission to exchange route advertisements and the willingness of each VCN to accept packets from the other VCN.  

  • Administrators update their VCN's route tables and security rules to enable traffic between the peered VCNs as desired.

I hope you enjoyed learning about the Local VCN Peering feature in Oracle Cloud Infrastructure.

In my next post, I will walk you through a Local VCN peering scenario where three Spoke consumer VCNs are enabled to access the shared resources on the Hub VCN. Stay tuned...

Vijay Arumugam Kannan

Principal Product Manager
Oracle Cloud Infrastructure, Networking

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha
Oracle

Integrated Cloud Applications & Platform Services