X

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

Vijay Kannan
Principal Product Manager

In my last post, we covered an overview of Oracle Cloud Infrastructure's Local VCN Peering Solution.

In this 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. Two Spoke VCNs are in the same tenancy and compartment of the Hub VCN. One Spoke VCN is in a different tenancy.

Local VCN Peering Scenario

Let us discuss the following example of a “hub-and-spoke” model in detail:

  1. Create four VCNs, their corresponding subnets, and the associated default route tables, security lists, and DHCP options based on the steps 1-3 described here.
  • Create the Hub VCN and two Spoke VCNs in the first tenancy as shown in the following figure.

  • Create the Spoke3 VCN on a different tenancy as shown in the following figure.

  • Create the subnet in the Hub VCN based on the appropriate CIDR details 

  • Spoke1 subnet details:

  • Spoke2 subnet details:

  • Spoke3 subnet details:

  1. The following steps illustrate how to create peering gateways on Hub VCN and Spoke1 VCN and then establish a peering connection between Hub VCN and Spoke1 VCN.
  • Create a Local Peering Gateway(LPG) in Hub VCN

  • Create a Local Peering Gateway(LPG) in Spoke1 VCN.

  • Establish a peering connection between the two VCNs using the two peering gateways created in previous two steps. In this case, Local Peering Gateway(LPG) in Hub VCN is accepting the connection. The Local Peering Gateway (LPG) in Spoke1 VCN is used to initiate the connection.

  • The established connection enables advertisement of the CIDRs to the peering gateway.

  1. Similarly, another pair of peering gateways is enabled to realize communication between Spoke2 VCN and Hub VCN.
  • Create another Local Peering Gateway(LPG) in Hub VCN

  • Create a Local Peering Gateway(LPG) in Spoke2 VCN.

  • Establish a peering connection between the two VCNs using the two peering gateways created in previous two steps. In this case, the Local Peering Gateway (LPG) in the Hub VCN is accepting the connection and the Local Peering Gateway (LPG) in Spoke2 VCN is used to initiate the connection

  • The established connection enables the advertisement of CIDR to the peering gateways.

  1. Another pair of peering gateways and IAM policies are enabled to realize cross-tenancy peering between Spoke3 VCN and Hub VCN.
  • Create another Local Peering Gateway (LPG) in Hub VCN.

  • Create a Local Peering Gateway (LPG) in Spoke3 VCN.

  • Establish a peering connection between the two VCNs across two tenancies using the two peering gateways created in previous two steps. In this case, Local Peering Gateway(LPG) in Hub VCN is accepting the connection and the Local Peering Gateway(LPG) in Spoke3 VCN is used to initiate the connection.

 

  • Administrator of the Spoke VCN shares the OCID of tenancy and user group. Administrator of the Hub VCN uses this information to set up IAM policies for facilitating the peering connection.

  • Administrator of the Hub VCN shares the OCID of its tenancy and LPG to the administrator of the Spoke3 VCN. Administrator of the Spoke3 VCN uses this tenancy OCID information to set up IAM policies for facilitating the peering connection.

  • The Local Peering Gateway (LPG) in Spoke3 VCN is used to initiate the connection

  • The corresponding LPGs in Spoke VCN and Hub VCN move to a peered state by establishing a cross-tenancy peering connection.

  1. Listed are the peering gateway details after establishing the hub-and-spoke communication model as required by the preceding figure.
  • Peering Gateways details in Hub VCN:

  • Peering Gateway details in Spoke1 VCN:

  • Peering Gateway details in Spoke2 VCN:

  • Peering Gateway details in Spoke3 VCN

  1. Local VCN peering will be presented to the customers as a direct route target in their VCN. VCN subnet level route rules will send the traffic directly to VCN Peering.
  • Route Table entries in Hub VCN

  • Route Table entries in Spoke1 VCN

  • Route Table entries in Spoke2 VCN

  • Route Table entries in Spoke3 VCN

  1. As a final step, evaluate the security rules associated with the subnets and update them accordingly to ensure that all inbound or outbound traffic that you permit is well defined as intended. In the simplest case, add a security rule in Hub VCN subnets to accept ICMP traffic from Spoke VCNs

With these steps, you now have three Spoke VCNs peered with the Hub VCN from the networking stand-point. Customers can deploy shared services in the instances attached to Hub VCN. Peered Spoke VCNs can now access shared services deployed in Hub VCN using private IP addresses.

I hope you enjoyed using Local VCN Peering feature in Oracle Cloud Infrastructure. We'd love to hear any feedback you have. 

Vijay Arumugam Kannan

Principal Product Manager
Oracle Cloud Infrastructure

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