Three Transit Models, One Moving Part

Tenant isolation is the part of multi-tenant networking that gets the attention, and it is the wrong place to start. Isolation on Nutanix is largely a solved problem: put each tenant in its own Flow VPC and the overlay keeps their packets apart. What is genuinely hard is that tenants want different relationships with the outside world. One wants cheap shared internet egress. Another brings its own address space and a leased line to its data center. A third wants its routing isolated down to the physical underlay, for reasons written into a compliance report. Historically a provider builds three different networks for those three customers, and then operates all of them at once.

This series argues that multitenancy on Nutanix is a control plane problem, and the previous piece showed how SP Central composes tenancy above unchanged clusters. The network tells the same story one layer down. The three transit models Nutanix presented for service providers at .NEXT 2026 look, at first sight, like three architectures. Read them against the Flow Virtual Networking documentation and they collapse into one design with a single moving part: where a tenant’s exit pair lives.

The Invariant

Every construct in the three models ships in Flow Virtual Networking today, under names you can find in the current guide. A tenant is a VPC. Its traffic reaches the world through a pair of overlay external subnets, OEN in the shorthand the GA documentation now makes official: one translates tenant addresses on the way out, the other routes them untouched. The documentation attaches this construct exclusively to the transit VPC, a VPC whose only job is to connect other VPCs to the outside. Inbound exposure is a floating IP from a provider pool, mapped one to one onto a workload NIC. And the fabric learns about all of it through BGP: the externally routable prefixes of tenant VPCs, the ERPs, are added to the transit VPC, and its gateway advertises them to the physical routers. If you read the earlier piece on inserting a firewall on a transit subnet, the shape will feel familiar; the transit VPC is the same separation move, promoted to the provider scale.

The invariant is worth stating as a property. Whatever enters or leaves a tenant VPC, outbound SNAT, an inbound service published on a floating IP, or address blocks the tenant brings along as BYOIP, crosses that same pair of subnets. The GA release codifies the pair as a rule: a VPC accepts at most two external subnets, one NAT and one no-NAT, never two of the same kind. Workloads themselves stay behind the overlay in every model; that is the property that keeps the tenant boundary clean, and it is why the three models compose instead of multiplying. The only decision left is where the pair attaches.

Shared Transit: Density First

The first model serves the long tail: many tenants, small footprints, standard needs. Every tenant’s NAT subnet lives in one shared transit VPC, which holds the single BGP session toward the physical routers and the shared services every tenant must reach. Onboarding a tenant means creating a VPC and its overlay external subnet; the prefix is advertised through the existing session, and nothing changes in the physical network. The operation is identical for the first tenant and the hundredth, which is the entire point of the model.

Public exposure stays selective. A tenant that needs to publish a service claims a floating IP from the provider pool and maps it to a workload NIC, and both directions of that traffic cross the tenant’s own subnet in the transit. What this model deliberately does not offer is routed connectivity into the workloads or physical isolation; a tenant that needs either has outgrown the shared lane, and the design has a place for it rather than an exception.

Partial Transit: The Split

The refinement that makes the model set interesting is that the choice is not per tenant but per path. A premium tenant keeps its internet access exactly where it was, through its NAT subnet in the shared transit, while its no-NAT subnet moves out into a transit VPC dedicated to that tenant, riding its own VLAN in a dedicated VRF, its own routing table in the physical network. The tenant’s leased line to its data center lands there, its prefixes remain its own, and the provider fabric stays out of that routing entirely.

The same tenant now lives in both models at once, and the two planes do not mix, because the dedicated transit advertises nothing into the shared one. That is the practical meaning of tenant-aware routing here: not a bigger shared network with more rules, but a second, smaller network that exists only for one tenant, attached to the same invariant pair.

Fully Isolated: The Pair Moves Out

In the third model the pair leaves the shared transit entirely. The tenant gets a dedicated transit VPC holding both its NAT and no-NAT subnets, a dedicated VLAN and VRF in the underlay, dedicated uplinks where required, and a BGP speaker of its own in that transit. Internet, data center connectivity, everything the tenant does with the world now crosses a plane that belongs to it. Under that transit, the tenant can attach multiple workload VPCs, separating production from staging the way the provider separates tenants.

Notice the recursion: the fully isolated tenant inherits a hub and spoke of its own, the same shape the provider operates in the shared model, one level down. Notice also what scales. The cost of this model grows with the number of premium tenants, not the number of tenants: each dedicated transit adds a VLAN, a VRF and a BGP session to the fabric, so the automation of the physical network, which no overlay product does for you, becomes the real constraint on how many of these you can sell.

Where the Network Control Plane Lives

All three models run on the same three planes. The data plane is on the AHV hosts, forwarding the flows already programmed. The control plane is the network controller, which programs those flows and reacts to dynamic events. The management plane is Prism Central and, above it, SP Central, where intent is defined. The previous piece noted that on Prism Central 7.5 the Flow deployment mode was a one-way choice; starting with pc.7.6 there is a documented migration from Integrated to Standalone, and the choice still matters either way. Integrated mode runs the controller inside the Prism Central VMs. Standalone mode moves the entire Flow Controller, the network controller together with the gateways and next-generation Flow Network Security, onto a small dedicated cluster hosted on one of the AHV clusters that Prism Central manages.

The difference shows in failure terms. In both modes, existing flows keep forwarding if the controller goes down; what suffers are dynamic events, because a VM that live-migrates on an overlay subnet can become unreachable until the controller returns. In Integrated mode that fate is chained to the management domain: lose it, and every migration or HA restart in the tenant estate is at risk until it is recovered. In Standalone mode the network control plane survives the loss of the management domain; onboarding freezes, tenants keep running, which is exactly the degradation a provider wants. The trade-offs deserve equally plain statement: the documented migration runs from Integrated to Standalone only, Prism Central backup and restore does not cover the controller and requires a manual reconnection afterward, and the controller cluster consumes capacity inside an application domain. That last point deliberately nuances the previous piece: in Standalone mode, application domains do host one piece of control plane, and it is there precisely so that tenant networking does not share a failure domain with tenant management.

One construct, three positions, three commercial profiles. None of it waited for SP Central, and SP Central no longer asks you to wait: version 1.0 reached general availability in August on the 7.6 stack, and what it adds is exactly lifecycle, turning the onboarding of these constructs into a tenant operation instead of a runbook. The questions that remain are the measurable ones, gateway scale-out limits, prefix counts per BGP speaker, controller behavior across a long management outage, and they belong to a lab, which is where this series goes next.