Enabling VPC Network peering in Google Cloud Platform

VPC network peering comes to help when we need to make hosts on two different VPCs needs to be able to communicate without the need to route the traffic through public internet. It allows RFC 1918 connectivity across two Virtual Private Cloud (VPC) networks regardless of whether the two networks are in same GCP project or not. The traffic stays completely within google’s network. VPC peering can be enabled with VPCs in same projects as well as VPCs in two different projects.

Sample VPC peered networks

The advantages of VPC network peering includes

• Lower latency since communications happens through Google’s internal network rather than routing through public internet
• Reduced bandwith costs. Whenever data transfer takes place via public internet Google cloud charges for the bandwidth consumed
• Improved network security since the network admins do not have to worry about the risks involved in exposing to public internet

VPC peering cannot be enabled with overlapping subnets. While setting up VPC peering with VPCs of different projects, it is worth to be noted that we cannot peer the default VPCs of the two projects since both the VPCs with be having overlapping subnets.

We will demonstrate how to peer two VPCs on two different projects in GCP.
In order to peer VPC networks we need to create two projects in GCP. Let them be gcp-project-1 and gcp-project-2
We will be peering default VPC of gcp-project-1 with a custom VPC named vpc-custom in gcp-project-2
We will be using bgp peering for network peering here, bgp peering is used to exchange routing informations between two systems(peers). You can read more about bgp peering here
https://docs.opendaylight.org/projects/bgpcep/en/latest/bgp/bgp-user-guide-bgp-peering.html

Let’s create a VPC network vpc-custom in gcp-project-2 with regional bgp peering mode.

gcloud compute networks create vpc-custom --subnet-mode=custom \
--bgp-routing-mode=regional

Create a subnet in that VPC with a non overlapping ip range in a region. You can use any region with your requirement, here we’re choosing us-central1 for demo purposes

gcloud compute networks subnets create custom-central1 \
--network=cpc-custom \
--range=10.59.0.0/20 \
--region=us-central1 \
--project=gcp-project-2

icmp firewall rule must be enabled for discovery of instances over the peered networks. Also add firewall rules for ssh to test connectivity with two VMs in the separate networks

gcloud compute firewall-rules create vpc-custom-default \
--network vpc-custom --allow tcp:22,icmp

Let’s create peering connection

gcloud beta compute networks peerings create custom-default \
--network=custom-vpc \
--peer-network=default \
--peer-project=gcp-project-2 \
--project=gcp-project-1
gcloud beta compute networks peerings create default-custom \
--network=default \
--peer-network=custom-vpc \
--peer-project=gcp-project \
--project=gcp-project-1

Viola VPC peering has been enabled between two projects.

Let’s test the connection by creating two compute engine instances in each VPC network, and try to ping from each other from those machines

gcloud compute instances create ping-test-1 \
--network default \
--subnet default \
--machine-type f1-micro \
--project=gcp-project-1
gcloud compute instances create ping-test-2
--network vpc-custom
--subnet custom-central1
--machine-type f1-micro
--project=gcp-project-2

Now list down vm instances in gcp-project-1 and gcp-project-2 with

gcloud compute instances list --project={project-id}

ssh into ping-test-1 and ping the internal ip of ping-test-2

Ping will be successful, do the same vice-versa and confirm the discoverability of machines across VPCs