Aviatrix Transit Gateway Encrypted Peering

Excluded Network CIDRs is an optional field. When the field is empty, a Transit Gateway propagates all learned routes from both Spoke VPC/VNets and on-prem.

The use case for this field is if there are conflicting or identical CIDRs on both sides of the Transit Gateways, the peering action will be rejected. Using the filter option prevents the overlapped CIDRs from being propagated to the other Transit Gateway.

Input a list of CIDRS separated by comma.

You can edit this field after the Transit Peering took place. Go to Transit Network > Transit Peering, highlight the peering connection. Click the 3 dots skewer and click Edit to modify the Excluded Network CIDR list.

The diagram below illustrates how Excluded Network CIDRs can be used in a two region deployment. In this case, 10.20.0.0/16 appears on both sides as VPC/VNet CIDR. To allow Transit Peering to proceed, configure on both Transit Gateways Excluded Network CIDRs with 10.20.0.0/16.

This feature applies to TGW hybrid connections. This is because TGW does not preserve BGP information in its learned routes.

When you use AWS Transit Gateway (TGW) to connect to on-prem via DXGW or VPN, there are situations where on-prem advertise the same network CIDRs to TGW in two different regions. When you connect the two regions by the Aviatrix Transit Gateway Peering, the network CIDR overlapping problem will occur.

This feature allows you to not to advertise certain TGW hybrid attachment (DXGW and VPN) to the remote Aviatrix Transit Gateway and therefore the remote TGW.

In the dropdown menu, highlight the TGW hybrid connections (The input box is empty if there is no such connection.), multi-select the connections. The selected connections are excluded to advertise to the remote site.

You can edit this field after the Transit Peering took place. Go to Transit Network > Transit Peering, highlight the peering connection. Click the 3 dots skewer and click Edit to modify the Excluded Connection list.

The diagram below illustrate the use case for this feature. In the diagram, both on-prem connects to TGW and advertise 10.0.0.0/8. Transit Gateway Peering will fail because there are conflict routes. You solve the problem by configuring on both Transit Gateways to exclude 10.0.0.0/8. With this configuration, Site-1 still accesses Prod-1/Prod-2 and Dev-1/Dev-2 via the local regional TGW and Site-2 accesses Prod-3/Prod-4 and Dev-3/Dev-4 via its local regional TGW.

This advanced option only appears and applies when the two Multicloud Transit Gateways are each launched in High Performance Encryption Mode and each is in a different cloud type. For example, one Multicloud Transit Gateway in AWS and the other in Azure.

Peering over Private Network function is an optional field. When this checkbox is checked, users are able to build Aviatrix Transit Gateway peering over multicloud where there is private network connectivity.

One of the use cases is two Aviatrix Transit Gateways deployed in two different public clouds where each has its private connectivity such as AWS Direct Connect and Azure ExpressRoute connecting to on-prem or a co-location. By building a Transit Gateway private peering, Aviatrix Transit Gateway forwards traffic over the private links to the other Aviatrix Transit Gateway and beyond.

For example configuration workflow, see Aviatrix Transit Gateway Peering over Private Network Workflow.

Aviatrix Transit Gateway Peering over the public network expands transit gateway peering across Cloud Service Providers over the internet by using Aviatrix High Performance Encryption (HPE) tunneling. Aviatrix HPE enables high throughput performance and high performance encrypted peered connections between the inter-cloud transit gateways.

Aviatrix HPE tunnels are built over public IP addresses between two inter-cloud transit peering gateways. For example, when a transit gateway peering is established between AWS and Azure, the Aviatrix Controller allocates and builds the HPE tunnels over the EIP addresses between the two transit gateways, establishing one-to-one connections.

GCP Ethernet interface supports only one public IP address; therefore HPE tunnels are built to the same public IP address on the GCP transit gateway, establishing one-to-many connections.

For more information about HPE tunneling, see Overview of Aviatrix High-Performance Encryption.

To establish peered transit gateways over the internet, see Multicloud Transit Gateway Peering over Public Network Workflow.

If centralized egress is enabled by local TGW FireNet or Transit FireNet, the default route 0.0.0.0/0 is not propagated to the remote Aviatrix Transit Gateway via Transit Peering.

On the other hand, if on-prem advertises the default route to the Aviatrix Transit Gateway, this default route is propagated to the remote Aviatrix Transit Gateway via Transit Peering.