In this lab, we will build the hub and spoke network in GCP. All the GCP VPCs and their respective subnets are already created for you to save time.

GCP Spoke-2 GW VPC Network/Subnet Creation

This step is already done for you so please do not attempt.

Controller can create those subnets using API/Terraform as well. It makes it easy to make it part of your CI/CD pipleline.

Controller –> Useful Tools –> Create A VPC –> Add New
Controller –> Useful Tools –> Create A VPC –> Add New Row

You should view the VPCs created for you already.

Controller –> Useful Tools –> VPC Tracker

Now click “VIEW GCLOUD SUBNET” to see further details

Deploy GCP Spoke-2 Gateway

Since we have all the subnets created properly, it is time to deploy the GCP Spoke-2 GW using the Controller.

Controller –> Multi-Cloud Transit –> Setup

Connect GCP Spokes to GCP Transit

At this stage we have 4 spokes in GCP

• gcp-spoke1 –> connected to gcp transit gw
• gpc-spoke2 –> not connected to gcp transit gw
• gcp-spoke3 –> connected to gpc transit gw (this will be use for user-vpn later in the lab)
• gcp-spoke4 –> not connected to gcp transit gw

Login to CoPilot (user: Copilot / pass: Copilot123!) now to see the connectivity in real-time

In this part of the lab, we will connect the remaining spoke gateway to aviatrix transit-gw

Controller –> Multi-Cloud Transit –> Setup –> Attach Spoke Gateway to Transit Network

Spoke#2

Spoke#3

Now notice the topology changed and all GCP spokes are connected now

Veryify GCP Spoke Connectivity

Now Ping from vm_gcp_private_ip_spoke1 (user: ubuntu / pass: Password123!) to other test machines (as listed below) and check the connectivity

• vm_gcp_private_ip_spoke2 (10.20.12.130) – should work
  • using Aviatrix hub/spoke
• vm_gcp_private_ip_spoke3 (10.42.0.130) – should work
  • using Aviatrix hub/spoke

Connect AWS Spoke to AWS-Transit

If we look at the AWS side, we have aws-spoke1 connected to aws-transit but the spoke2 is not yet connected as shown in the topology below

Now we will use Aviatrix Controller to establishe this connection. The aws-spoke2 gateway is already deployed for you

Controller –> Multi-Cloud Transit –> Setup –> Attach Spoke Gateway to Transit Network

After this setup, following is the topology

Veryify AWS Spoke Connectivity

Now Ping from vm_gcp_private_ip_spoke1 (user: ubuntu / pass: Password123!) to AWS test EC2s (as listed below) and check the connectivity

• vm_aws_private_ip_spoke1 (10.101.0.84) – should work
  • This works because the traffic is routed via the dc-router-1. There is a private link between dc-router-1 and dc-router-2 connecting GCP and AWS using services like Equinix/Megaport/Pureport/Epsilon/etc.
  • Use tracepath or traceroute ($sudo apt install traceroute) to confirm
• vm_aws_private_ip_spoke2 (10.42.0.84) – should not work
  • Because this subnet overlaps with the gcp spoke-vpc3 subnet
  • We will fix this issue later in the lab

Following output shows a traffic route from gcp-spoke-1 test VM to AWS test EC2 in aws-spoke1

ubuntu@vm-gcp-spoke-1:~$ tracepath 10.101.0.84
 1?: [LOCALHOST]                                         pmtu 1460
 1:  gcp-spoke-1.c.cne-pod24.internal                      1.563ms 
 1:  gcp-spoke-1.c.cne-pod24.internal                      0.260ms 
 2:  gcp-spoke-1.c.cne-pod24.internal                      0.256ms pmtu 1396
 2:  10.20.3.2                                             1.846ms 
 3:  10.20.3.2                                             0.775ms pmtu 1390
 3:  169.254.100.2                                        51.410ms 
 4:  172.16.0.2                                           55.184ms 
 5:  10.10.0.93                                           75.906ms 
 6:  10.101.0.70                                          77.206ms 

Multi-Cloud Transit Peering (Connection GCP and AWS)

Now we have setup all the gateway and build the hub-spoke (transit) in GCP, it is time to connect GCP with AWS now. This peering is secure and encrypted and takes care of number of configuration options and best practices that are needed for such a complex connectivity. You will appreciate the simplicity of doing that.

Select Multi-Cloud Transit –> Transit Peering –> ADD NEW

Note that the order of cloud selection does not matter here. After few seconds, the status will be green as shown in the screen shot below.

Verify Transit Connectivity

Ping from vm_gcp_private_ip_spoke1 (user: ubuntu / pass: Password123!) to GCP and AWS VMs (as listed below) and make sure connectivity works

• vm_gcp_private_ip_spoke2 (10.20.12.130) – should work
  • using Aviatrix hub/spoke
• vm_gcp_private_ip_spoke3 (10.42.0.130) – should work
  • using Aviatrix hub/spoke
• vm_aws_private_ip_spoke2 (10.42.0.84) – should not work
  • Because this subnet overlaps with the gcp spoke-vpc3 subnet
  • We will fix this issue later in the lab
• vm_aws_private_ip_spoke1 (10.101.0.84) – should work
  • This time the packet will use gcp to aws aviatrix transit gateway route for connectivity
  • Use tracepath or traceroute ($sudo apt install traceroute) to confirm
  • In case this link goes down, the connectivity will be provided using the DC router DCI link as backup. This setup is important for Business Continuity and Disaster Recover

  ubuntu@vm-gcp-spoke-1:~$ traceroute 10.101.0.84 traceroute to 10.101.0.84 (10.101.0.84), 30 hops max, 60 byte packets 1 gcp-spoke-1.c.cne-pod24.internal (10.20.11.2) 1.322 ms 1.354 ms 1.413 ms 2 10.20.3.2 (10.20.3.2) 2.684 ms 2.708 ms 2.710 ms 3 10.10.0.93 (10.10.0.93) 62.072 ms 62.032 ms 62.032 ms 4 10.101.0.70 (10.101.0.70) 61.975 ms 61.981 ms 61.895 ms

Controller –> Multi-Cloud Transit –> List –> Transit Gateway –> gcp-transit –> Show Details

Following screen shows the best path available to reach 10.101.0.84

Controller –> Multi-Cloud Transit –> List –> Transit Gateway –> gcp-transit –> Show Details –> Route Info DB Details

Following screen shows that 10.101.0.0/24 was received from two paths and transit peering was selected as the best path

This completes the transit topology and testing. You can verify it in CoPilot as well.