Skip to main content
Virtual Routing and Forwarding (VRF) lets you run multiple isolated routing tables on the same Aviatrix fabric, so that tenants or business units with overlapping IP address ranges can share the same Transit and Spoke Gateways without their routes or traffic mixing.

​
When to Use This

Use these patterns when you must onboard multiple tenants, business units, or customers with overlapping IP address space onto a shared Aviatrix fabric, and deploying a dedicated fabric per tenant is not practical at your scale.

​
Architecture Diagram

Every pattern in this document is fundamentally a topology decision, and each is best understood as a diagram of Transit Gateways, Spoke Gateways, VRF segments, and (where applicable) Network Domains.
  • Single-Transit Multi-VRF: a single Transit Gateway serving multiple VRF segments
    Single-Transit Multi-VRF
  • Multi-Transit VRF Stitching: VRF segments stitched across multiple Transit Gateways
    Multi-Transit VRF Stitching

​
Design Principles

Isolation at the routing layer. VRF enforces tenant isolation in the routing table itself, rather than through IP address planning or NAT. This is what allows tenants with overlapping CIDRs to coexist on the same fabric without one tenant’s routes leaking into another’s routing table. Overlap-tolerant by design. These patterns assume tenants, business units, or acquired companies frequently have colliding IP address ranges that cannot be renumbered. The design goal is to accommodate that reality directly instead of requiring NAT remediation before onboarding a tenant. Built on the existing Network Domain construct, not a second layer beside it. VRF does not introduce a separate segmentation model that you combine with Network Domains. In CoPilot, VRF is enabled with the Support for VRF toggle under Networking > Network Segmentation > Settings, and turning it on automatically assigns each existing Network Domain its own VRF segment. Environments that already segment Spokes with Network Domains keep that design unchanged. See the Network Domain entry under Components. Minimize fabric sprawl. A primary motivation for these patterns is avoiding the operational cost of deploying a dedicated Transit and Spoke fabric per tenant. A single fabric serving many isolated VRF segments reduces the number of gateways, peering relationships, and control-plane objects you must manage. Deliberate scope boundaries for GA. Several adjacent capabilities (FireNet inter-VRF inspection and route leaking between VRFs) are explicitly deferred past 10.1. These patterns are scoped to what is supported at GA rather than describing a larger, not-yet-delivered capability set. Terraform support for VRF is available at GA; see the sibling VRF Configuration guide for Terraform usage. Disabled by default. VRF end-to-end propagation does not activate merely by upgrading to Controller 10.1. It ships off by default and must be explicitly enabled (see the sibling VRF Configuration guide for the enablement procedure).

​
Components

  • VRF (Virtual Routing and Forwarding) segment: The isolated routing table that keeps a tenant’s or business unit’s routes and traffic separate from other segments on the same fabric. In CoPilot, VRF is enabled with the Support for VRF toggle under Networking > Network Segmentation > Settings. For a conceptual introduction to VRF and the multi-tenancy problem it solves, see VRF Multi-Tenancy Overview .
  • Transit Gateway: Hosts one or more VRF-scoped routing instances and is the point where VRF segments from different Spokes (and, in the multi-transit pattern, from peer Transit Gateways) converge on the shared fabric.
  • Spoke Gateway: Attaches a tenant’s VPC/VNet to a specific VRF segment on its Transit Gateway, keeping the tenant’s workload traffic scoped to that segment.
  • Network Domain: The existing Aviatrix segmentation construct that groups Spoke VPC/VNets so members can communicate with each other but not with VPC/VNets outside the domain. VRF assignment to a Network Domain is automatic: the Create Network Domain dialog exposes only Name, Associations, and Connect to Network Domain, with no manual VRF ID field, and each domain receives its own VRF automatically. A Network Domain and a VRF segment are the same boundary at GA, not two independently combinable layers of segmentation. See Transit Network Segmentation .
  • Site2Cloud (S2C): The overlapping-CIDR use case that motivated first-hop VRF support: multiple S2C connections in different segments can present overlapping remote CIDRs at the Transit Gateway. See Site2Cloud Overview .

​
Traffic Flows

These patterns handle three distinct east-west traffic patterns:
  • Intra-tenant, spoke-to-spoke. Traffic between two Spokes that belong to the same tenant stays within that tenant’s VRF segment as it crosses the Transit Gateway. This is the baseline flow for all three patterns.
  • Tenant-to-shared-services. Traffic from a tenant VRF to a shared services VPC/VNet (for example, DNS, logging, or a shared security appliance) crosses from the tenant’s VRF into a shared VRF segment or Network Domain that is explicitly permitted to reach it.
  • Cross-fabric, stitched. In the Multi-Transit VRF Stitching pattern, traffic for a given tenant must cross from that tenant’s VRF segment on one Transit Gateway to the matching VRF segment on a peer Transit Gateway, preserving tenant isolation across the stitched hop.
The following steps illustrate the cross-fabric flow:
1

Spoke originates traffic in its tenant VRF

A Spoke Gateway in Tenant A’s VRF segment on Transit Gateway 1 sends traffic destined for a resource reachable only through Transit Gateway 2 (for example, a different region or cloud).
2

Traffic crosses the stitched VRF segment

Transit Gateway 1 forwards the traffic to Transit Gateway 2 over the VRF segment stitched between the two gateways for Tenant A, keeping the traffic scoped to Tenant A’s routing table on both sides of the hop.
3

Traffic reaches the destination Spoke

Transit Gateway 2 delivers the traffic to the destination Spoke in Tenant A’s VRF segment, without exposing Tenant A’s routes to any other tenant’s VRF segment on either Transit Gateway.

​
Variants and Trade-offs

The pattern categories below are described at a conceptual level only. The definitive list of which specific pattern combinations are supported at 10.1 GA has not been finalized. Confirm current support status with your Aviatrix account team or the release notes for your Controller version before committing to a design.
Every pattern in this document shares the same underlying trade-off between VRF and Network Domain alone: enabling VRF adds datapath and Controller performance overhead, because the Controller must compute and maintain a separate routing table per VRF segment, in exchange for letting tenants with overlapping IP address ranges share the same fabric. If you leave VRF disabled and rely on Network Domains alone for segmentation, you avoid that overhead, but no two tenants anywhere in the topology can use overlapping CIDRs. The trade-offs below are specific to each pattern, on top of that baseline choice.

​
Sizing and Scale Considerations

As the number of tenants grows, the primary scaling questions are how many VRF segments a single Transit Gateway can host, how many routes each VRF segment can carry, and at what point a Single-Transit Multi-VRF design should move to Multi-Transit VRF Stitching to spread tenants across more than one Transit Gateway. Treat designs in the range of roughly 10 to 20 VRF segments per Transit Gateway as representative of what this feature is being scoped and validated against.

​
Security Considerations

VRF provides isolation at the routing layer: it prevents one tenant’s routes and traffic from being visible to or reachable by another tenant’s VRF segment on the same fabric. VRF-based isolation is not equivalent to firewall inspection between tenants. It controls reachability, not payload inspection.