About Transit Gateway Settings

This document describes the settings that you can configure for an Aviatrix Transit Gateway.

About Transit Gateway Settings

This section describes the settings that you configure to create a Transit Gateway. For instructions on how to create a Transit Gateway, see Creating a Transit Gateway.

Account

Your cloud provider account. The Aviatrix Controller uses your cloud provider’s account credentials to launch Aviatrix gateways via API calls.

To learn more about access accounts, see Accounts and Users.

Instance Size

Instance Size is the gateway instance size.

When selecting the gateway instance size, use the following guidelines of IPsec performance based on IPERF tests conducted between two gateways of the same size:

AWS Performance Numbers

AWS Instance Size Expected Throughput

T2 series

Not guaranteed; it can burst up to 130Mbps

c5.2xlarge, c5.4xlarge

2Gbps - 2.5Gbps

c5n.4xlarge

25Gbps (with High Performance Encryption (HPE) Mode)

c5n.9xlarge

70Gbps (with HPE Mode)

c5n.18xlarge

70Gbps (with HPE Mode)

Azure Performance Numbers (without High Performance Encryption Mode)

Azure Instance Size Expected Throughput

B series

Not guaranteed; it can burst up to 260Mbps

D/Ds series

480Mbps - 1.2Gbps

F Series

approximately 450Mbps - 1.2Gbps

GCP Performance Numbers (without High Performance Encryption Mode)

GCP Instance Size Expected Throughput

n1-standard-1, n1-standard-2, n1-highcpu-2

1.0 - 1.2 Gbps

n1-standard-4, n1-highcpu-2

2.3 - 2.5 Gbps

OCI Expected Throughput Numbers

OCI Instance Shape Throughput with Active Mesh Throughput without Active Mesh

VM.Standard2.2 or larger

1.8G

900 Mbps

With OCI you can choose a flexible shape to modify the Oracle CPU (OCPU) and memory configurations of your shape after it is deployed.

OCI Flex Shape OCPU and RAM

FLEX4.16

E3 4 OCPU 8G RAM

FLEX8.32

E3 8 OCPU 32G RAM

FLEX16.32

E3 16 OCPU 32G RAM

If you need IPsec performance beyond 2Gbps, refer to ActiveMesh HPE Performance Benchmark.

Gateway Resize

You can change gateway instance size, if needed, to change gateway throughput. The gateway instance will restart with a different instance size.

High Performance Encryption

High Performance Encryption (HPE) is an Aviatrix technology that enables 10Gbps and higher IPsec performance between two single Aviatrix Gateway instances or between a single Aviatrix Gateway instance and on-prem Aviatrix appliance.

When a gateway instance is launched with High Performance Encryption enabled, the Aviatrix Controller will look for a spare /26 subnet segment to create a new public subnet "-insane" and launch the gateway on this subnet.

The instance sizes that support High Performance Encryption are:

Cloud Provider Instance Sizes that Support HPE

AWS

t3, t3a, c5, c5n, c6in

Azure

Standard (except for B1ms, B2s, B4ms, B8ms, D1_v2, D2_v2, DS1_v2, DS2_v2, D2s_v3, D4s_v3, F2s_v2, F4s_v2)

GCP

n1-standard (except for standard-1 and standard-2), n1-highcpu (except for highcpu-2)

OCI

All instance sizes

HPE is only supported on OCI Spoke/Transit gateways.

For an overview of Aviatrix High Performance Encryption, see About High-Performance Encryption.

Peer to Transit Gateways

Transit Gateway peering connects two or more Aviatrix Transit Gateways that enables communication between Spoke VPCs/VNets via the Transit Gateways.

Transit Egress Capability

Enabling Transit Egress Capability ensures that this Transit Gateway is available to use in a Transit FireNet workflow or a Transit Egress workflow.

If you select AWS you can also enable the Gateway Load Balancer option (see definition below).

If you select GCP you must enter the subnet of a LAN VPC that will exchange traffic between the gateway and a firewall.

Gateway Load Balancer

If you enable Transit Egress Capability on an AWS Transit Gateway you can also enable the Gateway Load Balancer. This is beneficial if the Transit Gateway is going to be used as a Transit FireNet with attached firewalls.

BGP over LAN

In AWS and GCP, BGP over LAN feature allows Aviatrix Transit Gateways to establish a connection with a pair of third-party instances, that are in the same VPC as the Transit Gateway, without using the IPsec or GRE tunneling protocol.

In Azure, BGP over LAN allows Aviatrix Transit Gateways to establish a connection with a pair of third-party instances, that are in the same VNet but different from the Transit Gateway VNet, without using the IPsec or GRE tunneling protocol.

Multiple BGP over LAN connections are supported, however, each connection can be connected to one or at most two third-party instances. For Azure, the two third-party instances must be in the same VNet.

BGP over LAN feature is not supported for OCI and Alibaba Cloud.

When configuring BGP over LAN:

  • For Azure, you must indicate the number of LAN interfaces you need (maximum is eight).

    When you add new or additional LAN interfaces to an Azure Transit Gateway, the gateway is rebooted and traffic disruption may occur.
    You cannot delete an interface after the Transit Gateway is created.
  • For GCP, you must indicate the subnet on which to apply the BGP over LAN connection. You cannot enable BGP over LAN after the Transit Gateway is created.

To learn more about BGP over LAN connections, refer to:

Instances

The Aviatrix Gateway High Availability feature enables you to create High Availability (HA) gateways for Spoke and Transit Gateways to minimize and reduce network downtime and improve network stability and performance.

  • Transit Gateways can have only two gateway instances.

  • Spoke Gateways can have up to 15 gateway instances.

  • Spoke Gateways can have only one gateway instance if the gateway has:

    • BGP connection(s).

    • Site2Cloud or customized SNAT and DNAT enabled.

When HA Spoke and Transit gateways are deployed, the Aviatrix Controller monitors your cloud network deployment, detects if a gateway is down and handles failover resolution automatically.

For an overview of the Aviatrix Gateway High Availability feature, see About Gateway High Availability.

Attach to Subnet

Aviatrix Gateways are launched in a public subnet in AWS, GCP, and OCI. A public subnet in AWS VPC is defined as a subnet whose associated route table has a default route entry that points to the Internet gateway (IGW). To learn more about VPC and subnets, refer to this link.

If you do not have a VPC/VCN with public subnet in AWS, GCP, or OCI, you can use our Creating a VPC/VNet using CoPilot tool to create a VPC with fully populated public and private subnets in each AZ.

About Transit Gateway General Settings

This section describes the settings that you can configure for a Transit Gateway after the gateway is created. For instructions on how to configure the settings, see Enabling Transit Gateway General Settings.

Use VPC/VNet DNS Server

The Use VPC/VNet DNS Server feature enables you to set the default DNS server for the Aviatrix gateway.

When this feature is On, it removes the default DNS server for the Aviatrix Gateway and instructs the gateway to use the VPC or VNet DNS server configured in VPC or VNet DHCP option.

When this feature is Off, the Aviatrix Gateway will revert to use its built-in (default) DNS server.

When enabling this feature, the Controller checks to make sure the gateway can indeed reach the VPC/VNet DNS server; if not, an error is returned.

For more information, see Using VPC/VNet DNS Server.

Connected Transit

By default, Aviatrix Spoke VPCs and VNets do not have routing established to communicate with each other via the Transit Gateway. They are completely segmented.

The Connected Transit feature enables you to build a full mesh network where Spoke VPCs and VNets communicate with each other via the Transit Gateway. All connections are encrypted in Connected Transit mode.

  • All Spoke Gateways must be either in high-availability (HA) mode or non-HA mode. A mixed deployment (where some Spoke gateways have HA enabled and some Spoke Gateways have non-HA mode) does not work when a failover happens on a HA-enabled Spoke Gateway.

  • For a Spoke VPC or VNet in a Multicloud Transit to communicate with a Spoke VPC in TGW Orchestrator, Connected Transit must be enabled on the Aviatrix Transit Gateway that connects both sides.

Advertise Transit VPC/VNet CIDR

By default, Aviatrix Transit Gateway does not advertise Transit VPC/VNet CIDR.

When this setting is enabled, Aviatrix Transit Gateway advertises the Transit VPC/VNet CIDR to VGW. The Controller programs the 3 RFC1918 routes in the AWS route table to point to the Transit Gateway. It also programs the learned routes from VGW into the AWS route table.

If you deploy instances in the Transit VPC/VNet, enabling Advertise Transit VPC CIDR mode allows the instance to communicate both to Spoke VPCs and the on-prem network, assuming the Spoke VPCs are in the RFC1918 range.

Multi-Tier Transit

Use the Multi-Tier Transit setting to implement a hierarchical Transit Gateway architecture that permits packets to traverse more than two Aviatrix Transit Gateways. Previously, full-mesh transit peering was required. You can now connect two cloud service providers or regions through one peered connection. You must use ActiveMesh 2.0 to use multi-tier transit gateways, but full-mesh transit peering is not required.

  • You can use Multi-Tier Transit option with or without HPE.

  • Inter and intra-region peering are both supported.

  • Inter-CSP HPE over Internet is supported between AWS and Azure.

  • AWS TGW peering is not supported.

Jumbo Frame

Jumbo Frame improves Aviatrix Gateway throughput performance.

  • Jumbo Frame is enabled by default for AWS and OCI. It is not supported for Azure or GCP.

  • If the gateway is used in a Transit FireNet configuration, ensure that the associated firewall also has Jumbo Frame enabled.

GRO/GSO

The GRO/GSO feature enables you to configure the gateway interface and enable or disable Generic Receive Offload (GRO) and Generic Segmentation Offload (GSO).

GRO/GSO is On by default to improve performance. You can set this feature to Off to minimize out of order packets for sensitive applications (like FTP), but there will be a performance throughput penalty.

Active-Standby

This feature enables you to deploy a Transit Gateway connection to an external device where the external device, such as an on-premises firewall, does not support asymmetric routing on two tunnels.

Active-Standby mode applies to both BGP and Static Remote Route Based external connections.

When Active-Standby mode is enabled, the Transit Gateway connects to the external device with only one active peering connection forwarding network traffic and the other as standby.

If you enable Active-Standby mode, you can select the Failover Mode to determine the network’s behavior when the active peering connection goes down.

  • When Preemptive is enabled, the network automatically switches back to using that active peering connection when the connection is back up.

  • When Non-Preemptive is enabled, the network continues to use the standby peering connection even after the active peering connection is back up, until you initiate a manual switch to the active peering connection.

Gateway Single AZ HA

The Gateway Single AZ HA feature enables the Aviatrix Controller to monitor the health of the gateway instance and restart the gateway instance if it becomes unreachable. Gateway Single AZ HA is enabled by default.

Using Gateway Single AZ HA, you can select the gateway instance to restart.

When Gateway Single AZ HA status is On, the Aviatrix Controller attempts to restart the gateway instance. When status is Off, Controller does not attempt to restart the gateway instance.

If you’re using Terraform to create Aviatrix gateways, you must enable the single_az_ha flag in the aviatrix_gateway resource. See Aviatrix Provider.

Change Interface(s) RX Queue Size

Using the Change Interface(s) RX Queue Size, you can select a gateway and set the gateway’s interface(s) RX Queue Size.

  • A larger RX queue size introduces high latency in forwarding packets.

  • A smaller RX queue size has low latency but will drop packets early when forwarding packets.

About Transit Gateway CSP Related Settings

This section describes the cloud service provider related settings for a Transit Gateway.

Summarize CIDR(s) to AWS TGW

Enable this setting to limit routes propagated to TGW to only three RFC 1918 CIDRs and specific non-RFC 1918 CIDRs. Limiting routes saves route propagation time.

Leave this setting disabled (the default setting) to maintain better segmentation behavior without improving performance.

AWS TGW Edge Segmentation

AWS TGW Edge Segmentation allows you to further specify on each AWS TGW Aviatrix _Edge_Domain connection which domain the Transit Gateway can communicate with.

This feature is not available for Transit Gateways that have FireNet added, or have Network Segmentation enabled.

After you turn On this option you can build domain connection policies to specify which Network Domain this AWS TGW Aviatrix_Edge_Domain connection can communicate with.

For more information, see Configuring AWS TGW Edge Segmentation.

Configuring CSP Settings

  1. In Aviatrix CoPilot, go to Cloud Fabric > Gateways > Transit Gateways tab.

  2. In the table, locate and select the Transit Gateway you want to edit.

  3. Go to the Transit Gateway’s Settings tab.

  4. Expand the CSP Settings section.

  5. (optional) Toggle Summarize CIDR(s) to AWS TGW to On.

  6. Follow the instructions to set up AWS TGW Edge Segmentation.