Understanding Transit Gateway Peering over the Internet with Insane Mode on GCP

Aviatrix Insane Mode over the internet builds high-performance encryption (HPE) tunnels over public IP addresses between two inter-cloud transit peering gateways (cloud network layer).

Aviatrix Insane Mode HPE over the internet throughput performance is dependent on the number of HPE tunnels that are configured.

Insane Mode over the internet for GCP transit gateway peering configuration differs from other CSPs because GCP Ethernet interface supports only one public IP address per VPC.

In this document I’ll explore how multi cloud transit network with insane mode over Internet with GCP works. The topology I’m going to use is shown in the diagram below:

Aviatrix version 6.7 or later is required for Transit Gateway Peering over the Internet with Insane Mode on GCP

FireNet Deployment

FireNet deployment is covered on the following blogs:

http://rtrentinsworld.com/2022/05/28/deploying-an-aviatrix-firenet-on-gcp-with-checkpoint/

http://rtrentinsworld.com/2022/05/28/deploying-an-aviatrix-firenet-on-gcp-with-fortinet-fortigate/

http://rtrentinsworld.com/2022/05/28/terraforming-an-aviatrix-firenet-on-gcp-with-pans/

Transit Gateway Peering Configuration

Create the Transit GW Peering by navigating to Transit Network > Transit Peering > Add New. I’m peering an azure transit (az-eastus-transit) to a gcp transit (avx-us-central1-transit):

Because both Transit GWs were built with Insane the advanced options is displayed, allowing us to choose between private or internet with insane mode:

Peering over Private Network: This option only appears and applies to when the two Multi-Cloud Transit Gateways is each launched in Insane Mode and each is in a different cloud type.
Insane mode Encryption over Internet: This option only appears and applies to when the two Multi-Cloud Transit Gateways is each launched in Insane Mode. It peers transit gateways across the internet by using Aviatrix Insane Mode encryption tunneling.

By default, the gateways create 4 x tunnels. The supported range is 2 to 20 HPE tunnels for each transit gateway but depends on the instance size. Odd tunnel numbers are supported without penalty.

If number of tunnels need to be changed later, the peering would have to be detached first and then re-attached

Instance Size x Tunnels

The maximum number of tunnels supported between a GCP transit gw and another CSP is the number of tunnels supported by the other CSP transit gateway instance but caped to the maximum of 20 tunnels at this time.

Azure

8 tunnels: Standard_D3_v2, Standard_DS3_v2
32 tunnels: Standard_D4_v2: 32, Standard_D5_v2,Standard_DS4_v2, Standard_DS5_v2, Standard_D4_v3, Standard_D8_v3, Standard_D16_v3, Standard_D32_v3, Standard_D8s_v3, Standard_D16s_v3, Standard_D32s_v3, Standard_D8_v4, Standard_D16_v4, Standard_D32_v4, Standard_D8s_v4, Standard_D16s_v4, Standard_D32s_v4, Standard_F8, Standard_F8s_v2, Standard_F16s_v2, Standard_F16, Standard_F32s_v2
48 tunnels: Standard_D48_v3,Standard_D64_v3, Standard_D48s_v3, Standard_D64s_v3, Standard_D48_v4, Standard_D64_v4, Standard_D48s_v4, Standard_D64s_v4, Standard_F48s_v2, Standard_F64s_v2, Standard_F72s_v2

GCP

15 tunnels: n1-highcpu-4, n2-highcpu-4, c2-standard-4
30 tunnels: n1-highcpu-8, n1-highcpu-16, n2-highcpu-8, highcpu-16,
50 tunnels: n1-highcpu-32, n2-highcpu-32, c2-standard-30, c2-standard-60

Checking

Once the transit peering configuration finishes, we can check the status of the connection:

Azure gateway is a D64s v3 machine that supports up to 48 tunnels:

We can see the number of tunnels checking the GW routing table:

there are 20 tunnels between av-gw-az-eastus-transit and avx-us-central1-transit
Tunnels point to the same public ip (34.121.111.49) that is associated to the NIC0 and private ip 172.23.16.4: