VRF Multi-Tenancy

VRF is an Aviatrix segmentation construct that gives each tenant, business unit, or customer its own routing context, including support for identical or overlapping IP address ranges between segments. It extends the first-hop VRF capability introduced in Controller 9.0 end-to-end across transit peerings, so a segment retains its identity from an Edge or Spoke attachment, across one or more Transit Gateways, to its destination. Network Domains and Multicloud Transit Segmentation already isolate traffic using cloud-native VPC/VNet route tables, but both assume that a prefix advertised into the transit fabric is unique. VRF removes that assumption: use it when segments must be isolated and one or more of them use IP address ranges that overlap with another segment.

​

Design

​

Core Design

VRF removes the implicit constraint of Network Domains and Transit Segmentation. It gives each segment its own routing context: a separate forwarding table on the gateway itself, in addition to the cloud-native VPC/VNet route table. As a result, the same prefix can exist in two segments at once, and each instance resolves independently in its own table. This is the same technical problem that first-hop VRF solves in traditional on-premises networking, now applied to Aviatrix Gateways.

​

How It Works

VRF is delivered in two stages that build on each other:

• First-hop VRF (Controller 9.0) scoped this per-segment forwarding table to a single gateway hop, for Site2Cloud connections terminating on a Transit Gateway. Each domain got its own routing context at that one gateway, which was enough to resolve overlapping CIDRs arriving from different Site2Cloud connections, but the isolation did not extend past that gateway.
• End-to-end segment identity propagation across transit peerings (Controller 10.1) extends that same per-segment forwarding table across a transit-to-transit or Edge/Spoke-to-transit peering. When traffic for a segment crosses a peering, the receiving Transit Gateway has to know which segment the packet belongs to, so it can select the matching per-segment table on its own side. The segment identity has to survive the trip across the peering, not only the first hop. Segments with the same name on both sides of a peering are treated as the same segment (name-based mapping); the peering itself is what has to be explicitly VRF-aware for this propagation to take effect.

​

Operation Model

1. A packet enters a VRF-enabled gateway and is marked with its segment identity based on the connection or attachment it arrived on (for example, a specific Site2Cloud connection, BGP peer, or spoke attachment).
2. The gateway looks up the packet’s destination in the forwarding table that belongs to that segment, not the gateway’s shared/main table.
3. If the destination is reachable through a VRF-aware transit peering, the segment identity travels with the packet across that peering.
4. The receiving Transit Gateway reads the segment identity, matches it by name to its own local segment, and continues forwarding using that segment’s own table, including out to a third-hop Spoke or Edge attachment.
5. Routes learned dynamically (for example, over BGP) are installed into, and withdrawn from, the matching per-segment table rather than the shared table, so route churn in one segment does not affect another.

Cross-segment connectivity does not happen unless you explicitly allow it. A connection policy between two segments (the same policy construct used by Network Domains) permits bidirectional traffic between them; removing the policy restores isolation.

​

Key Features

​

Per-Segment Route Isolation

Each segment gets its own forwarding table, independent of any other segment’s table on the same gateway.

• Identical or overlapping CIDRs in different segments do not collide, because each segment resolves destinations in its own table.
• A segment’s cloud-native VPC/VNet route table only ever contains that segment’s own routes. It never carries another segment’s overlapping CIDRs.
• Dynamic routes (BGP-learned) install into and withdraw from the correct per-segment table automatically.

​

Segment Identity Propagation Across Transit Peerings

This release adds a new capability: a segment’s isolation extends beyond the gateway it entered on.

• A VRF-aware transit-to-transit or Edge/Spoke-to-transit peering preserves segment identity across the peering.
• Segments are mapped between peered gateways by name: a segment named the same way on both sides of the peering is treated as one continuous segment.
• Isolation holds even when the two sides of the peering are in different clouds or regions.

​

Controlled Cross-Segment Connectivity

Segments are isolated by default; you decide when two segments should talk to each other.

• A connection policy between two segments allows bidirectional traffic between them, using the same policy model as Network Domains.
• Removing a connection policy restores isolation without requiring any other configuration change.

​

Compatibility with Encryption and Path Features

Segment isolation is validated to keep working alongside Aviatrix’s performance and resiliency features on the same peering, not only on a plain tunnel.

• Segment identity propagation is validated against High Performance Encryption, which spreads a single peering’s traffic across multiple encrypted subtunnels.
• Segment identity propagation is validated against ActiveMesh multi-path tunnels.
• IPv6 traffic is supported within a VRF-enabled segment.

​

When to Use

​

Consolidating Multiple Tenants Onto Shared Transit Infrastructure

You operate a shared transit backbone, as a service provider or as an internal platform team serving multiple internal customers. Your tenants’ networks were never coordinated with each other, so some of them use identical or overlapping private address ranges. Use VRF to isolate each tenant’s routing without renumbering any of them, while still using one shared set of Transit Gateways rather than a separate Controller or Transit deployment per tenant.

​

Segmenting Business Units After a Merger or Acquisition

Two business units, divisions, or recently acquired subsidiaries need to be kept isolated from each other on the network, but at least one of their address ranges overlaps with the other’s. Network Domains alone cannot represent that overlap in a shared transit route table; VRF can, because each business unit resolves its own destinations in its own table.

​

Extending an Existing On-Premises VRF-Lite Design Into the Cloud

Your on-premises network already segments traffic per business unit or customer using VRF-lite or a similar per-VRF WAN design. You want the cloud side of your Aviatrix deployment to preserve that same per-segment boundary once it reaches the cloud, rather than collapsing everything into one flat routing domain. First-hop VRF already lets a Transit Gateway preserve segment boundaries for Site2Cloud connections; this feature extends that boundary further, across transit peerings, toward the rest of your Aviatrix fabric.

​

Best Practices

• Name segments consistently across every transit you peer. Segment mapping across a VRF-aware peering is name-based. A typo or inconsistent naming convention between two transits results in two segments that fail to map to each other rather than a visible error.
• Reserve non-overlapping CIDRs for anything shared across every segment. Shared services that every segment needs to reach are simplest to design with a non-overlapping address range, since a shared destination that itself overlaps with a segment’s own range is harder to route unambiguously.
• Treat connection policies between segments as a deliberate exception, not a default. Segments are isolated by default specifically so that overlapping or sensitive address space in one segment is never reachable from another segment without an explicit decision.
• Plan for a bounded number of segments, and confirm the actual limit for your target release before committing to a design. Design for no more than 10 to 20 segments per Controller. This range reflects current design guidance, not a load-tested maximum for this release; confirm the published limit for your target release before finalizing a design.
• VRF is supported on AWS, Azure, and GCP. Confirm your target segments run in one of these clouds before you design around VRF.
• Adopt first-hop VRF before relying on cross-peering propagation. Since end-to-end propagation extends the same per-segment table that first-hop VRF establishes at the gateway, confirm your Site2Cloud or BGP-facing gateways are already using first-hop VRF correctly before layering transit peering propagation on top of it.

​

Comparison with Network Domains and Transit Segmentation

VRF does not replace Network Domains or Transit Segmentation. It addresses the one case they cannot: segments whose address space overlaps. If none of your segments need overlapping address space, Network Domains and Transit Segmentation alone are sufficient and simpler to reason about. Reach for VRF specifically when overlapping IP addresses across segments are a requirement, not a preference.