Transit Network Segmentation FAQ¶
What is Multi-Cloud Transit Segmentation?¶
Aviatrix Multi-Cloud Transit Segmentation provides network isolation through security domains and connection policies to Aviatrix Transit network where both Spoke and Transit networks deploy Aviatrix gateways across multi-region and multi-cloud. The concept can be described in the diagram below,
Where Spokes associated with the blue domain can communicate with each other while Spokes associated with the green domain can communicate with each other. But there is no cross communication between blue domain and green domain unless there is connection policy. The concept is the same as Security Domains and Connection Policies defined in TGW Orchestrator, except this is implemented with Aviatrix Transit where both Spokes and Transit VPC/VNet deploy Aviatrix gateways. (Note the segmentation works with Azure native Spoke VNets.)
What is a Security Domain in Multi-Cloud Transit?¶
A Security Domain is an Aviatrix enforced network of VPC/VNet members, where VPC/VNets in the Security Domain can communicate with each other, and VPC/VNets not in the security domain cannot communicate with VPC/VNets in the Security Domain.
One or more Spoke VPC/VNetss are members in a security domain.
Spokes in a security domain can communicate with each other via an Aviatrix Transit Gateway.
The Aviatrix Controller dynamically programs and updates both VPC/VNet route tables so that instances in different Spoke VPC/VNets in the same domain can communicate with each other.
Two security domains are not connected, i.e., a Spoke in one domain has no connectivity to another Spoke in a different domain. Connection policy must be specified to connect the two domains so that Spokes in each domain can communicate with each other.
The Security Domain also applies to the hybrid connection from Aviatrix Transit Gateway to on-prem or remote sites. Each BGP peer or connection can be associated with one Security Domain.
What is a Connection Policy?¶
A connection policy is a rule enforced by Aviatrix for cross Security Domain connectivity.
What are the benefits of using Security Domains and Connection Policies?¶
The key use case for building Security Domains is to segment traffic for enhanced security posture.
Using Security Domains and Connection Policies allow you to identify groups of Spokes and Edges with the same requirements from a networking point of view and then apply connection policies at the group level. This avoids having to individually specify connections at the Spoke level. The Aviatrix Controller takes care of route programming of all route tables.
Can an Aviatrix Transit Security Domain work with TGW Orchestrator Security Domain?¶
They do not work together at this time, however we have plan to integrate them in the future.
How many Security Domains are supported in Multi-Cloud Transit Segmentation?¶
The maximum number of Security Domains on each Aviatrix Transit Gateway is 250.
What is the difference in implementation of Segmentation between Release 6.1 and Release 6.0?¶
In Release 6.1 and later, each Security Domain is implemented as an individual route table on the Aviatrix Transit Gateway. This allows better handling for the default route (0.0.0.0/0) traffic if different domains require different egress next hop. In addition, duplicate Spoke CIDRs attached to different Aviatrix Transit Gateways can co-exist if they belong to different domains.
What is the limitation of Segmentation?¶
- Segmentation is not supported on Aviatrix Transit Gateway connection to Aviatrix CloudN hardware for Insane Mode connection.
- Segmentation is also not allowed if Aviatrix Transit Gateway instance type is C5n.18xlarge.
- If two Aviatrix Transit Gateways are peered together and one of them has FireNet Egress enabled, through Aviatrix Transit Gateway peering the Spoke VPC/VNets may be connected. The work around is to have FireNet Egress enabled on each Aviatrix Transit FireNet.
- Duplicated CIDRs that cross domains or cross transits may not work all the time. Aviatrix does not support duplicated CIDRs that cross domains or cross transits.