VCF 9.1.1 Is Billed as a Maintenance Release. The Networking Documentation Says Otherwise.

VCF 9.1.1.0 shipped on 3 September 2026. The release notes describe it in one sentence: a maintenance release with an updated Bill of Materials, delivering features mostly focused on improving supportability.

That's accurate as far as it goes, and it's the reason most people will skim it. But if you run the Distributed VXLAN Connectivity Model, or you're planning to, the documentation tells a different story. Six capabilities moved from unsupported to supported in this release. That's not supportability, that's function.

And there's a patch ordering constraint that contradicts the usual assumption about maintenance releases, which is the thing most likely to cost somebody a change window.

Start with the patch ordering, because it will bite

The release notes say what everyone assumes: in general, maintenance and patch releases do not affect component interoperability and do not require a strict patch order.

Then immediately: however, VCF 9.1.1.0 comes with a new BoM and has specific dependencies between VCF components.

Patch the VCF management services fleet lifecycle component to 9.1.1.0 before any other VCF component. Nothing else goes first.

Once fleet lifecycle is at 9.1.1.0, you can patch the rest simultaneously, subject to four dependencies:

Step 1. Patch the VCF management services fleet lifecycle component to 9.1.1.0. This completes before any other component is touched.

Step 2. Patch the remaining components in parallel, subject to four dependencies:

•      Software depot. While the depot is patching, every other component patch is blocked, because the binaries are unavailable until the depot process finishes.

•      Identity broker. Patch the VCF management services runtime that hosts it before patching the broker.

•      Salt RaaS. Same pattern, patch its host VCF management services runtime first.

•      Migration service engine. Patch VCF Automation before this component.

Three of those four are the same pattern: a service that runs on a runtime needs the runtime patched before it. Easy to miss if you're working from a component list rather than a dependency map.

The software depot one is different and worth planning around. While the depot is patching, every other component patch is blocked because the binaries aren't available. So the depot patch isn't just another item in the list, it's a serialising step in the middle of your window. Sequence it deliberately rather than letting it land wherever the tooling puts it.

The part the release notes undersell

The Distributed VXLAN Connectivity Model integrates NSX with a physical EVPN-VXLAN fabric, unifying virtual workloads and physical endpoints into one routing domain. Between 9.1.0 and 9.1.1 it changed substantially.

What changed between the two versions:

•      Stateful network services via Virtual Network Appliance. Not supported in 9.1.0, supported in 9.1.1.

•      Avi Load Balancer. Not supported in 9.1.0, supported in 9.1.1.

•      EVPN Route Controller high availability. Active/Standby only in 9.1.0. In 9.1.1 you also get Active/Active with scale-out to eight nodes.

•      EVPN-VXLAN Direct Prefix Routing. Not supported in 9.1.0, supported in 9.1.1.

•      DHCP relay on VPC public subnets for external DHCP server connectivity. Not supported in 9.1.0, supported in 9.1.1.

•      Host group affinity using the Best Effort Restart compute policy. Not supported for EVPN Route Controller or Virtual Network Appliance nodes in 9.1.0. Supported for both in 9.1.1.

Read that as a design table rather than a feature list. Anyone who evaluated this connectivity model on 9.1.0 and ruled it out did so against four hard blockers: no stateful services, no Avi, no Direct Prefix Routing, no DHCP relay on VPC public subnets. All four are gone.

If you rejected the Distributed VXLAN model earlier this year, the reason you rejected it may no longer exist.

The Active/Active scale-out to eight EVPN Route Controller nodes is the other one worth noting. Active/Standby caps your control plane at one working node and makes the controller a scaling ceiling. Eight-node Active/Active turns it into something you can size.

How the model actually works

Worth understanding properly, because the encapsulation split is the part people get wrong.

The model uses a decoupled MP-BGP EVPN control plane with a VXLAN data plane, connecting VPCs to the physical fabric. Distributed Transit Gateways provide connectivity into tenant VRF instances in the physical network.

Here's the split that matters. NSX continues to use GENEVE for east-west traffic between ESX hosts. VXLAN is used for routing out to the physical EVPN-VXLAN fabric and the physical endpoints attached to it. The ESX VMkernel tunnel endpoint handles both simultaneously, which is why the documentation uses TEP and VTEP interchangeably when talking about hosts.

So this isn't NSX switching from GENEVE to VXLAN. It's NSX speaking VXLAN at the fabric boundary while keeping GENEVE internally. Different question, different answer, and worth being precise about in a design review.

Multi-tenancy works through Layer 3 VNIs. Each VRF or tenant is identified by an L3 VNI configured in the External Connection, mapping one-to-one to a Distributed Transit Gateway.

Two constraints to know before you design around it

First, and this one is easy to miss because it's in a parenthesis in the documentation: Layer 2 MAC advertisement is not supported in the current EVPN-VXLAN integration with NSX. EVPN normally advertises both L2 MAC and L3 IP reachability. Here you get L3 only. If your design assumed L2 extension across the fabric through this model, it doesn't do that.

Second, the EVPN gateway must advertise a default route to the EVPN Route Controller, regardless of whether Direct Prefix Routing is enabled. That's a requirement on the physical fabric side, which means it's a conversation with your network team before the design is fixed, not after.

The thing that makes this genuinely useful

Unlike the Distributed VLAN model, this one does not require an external VLAN spanning across the Distributed Transit Gateways. Connectivity between each ESX host and the physical fabric runs through the host VTEP interface.

The consequence is stated directly in the documentation: it supports the Multi-Rack Layer 3 vSphere Cluster Model for workloads without compromising rack isolation through a Layer 3 boundary.

That's the real prize. Multi-rack Layer 3 designs give you clean failure domains and clean rack isolation, and historically that came at the cost of stretched Layer 2 somewhere to make connectivity work. This removes that trade. For anyone building at rack scale, particularly GPU estates where rack-level power and cooling boundaries are already forcing the physical design, that matters.

It also connects directly to Broadcom's open networking direction with Cisco. EVPN as a standards-based meeting point between NSX and a third-party fabric stops being a strategy statement and starts being a supported model with a capability matrix.

The upgrade paths

Four routes to 9.1.1.0, and one of them is more useful than it looks:

•      New deployment. VCF Installer deploys a new fleet or instance directly at 9.1.1.0.

•      Convergence. Existing virtual infrastructure converges to VCF or vSphere Foundation directly at 9.1.1.0.

•      Upgrade from 5.2.x or 9.0.x. You go directly to 9.1.1.0 without stopping at 9.1.0 first, starting by upgrading VCF Operations to 9.1.1.

•      Patch from 9.1.0.x, subject to the ordering above.

The third one is the one to notice. If you have a 5.2.x estate with an upgrade planned, there's no reason to target 9.1.0 as an intermediate. Go straight to 9.1.1 and land on the newer BoM with the networking capabilities included.

BoM highlights

Core components all move to 9.1.1.0: ESX, vCenter, NSX, VCF Installer, VCF Operations, VCF Automation, Supervisor, fleet lifecycle, SDDC lifecycle, software depot, identity broker, Salt RaaS and Salt master, log management, real-time metrics, VCF services runtime.

Worth noting separately because they version independently:

•      VMware Tools 13.5.0 and Remote Console 13.1.1

•      VKS 3.7.0+v1.36, VKS Add-ons 3.7.0+20260618

•      vSphere Kubernetes releases 1.34.2+vmware.2-vkr.2

•      Supervisor services: Harbor 2.15.2, Contour 1.33.5, ArgoCD 1.2.0, External DNS 0.21.0

If you pin versions in your HLD, those are the lines that need updating, and the Kubernetes release version is the one most likely to matter to application teams.

What to do

•      Read the patch ordering before you plan the window. Fleet lifecycle first, then watch the software depot serialisation and the three runtime dependencies.

•      If you evaluated the Distributed VXLAN Connectivity Model on 9.1.0 and ruled it out, re-read the comparison table. Four of the likely blockers are resolved.

•      If you're on 5.2.x with an upgrade planned, target 9.1.1 directly rather than 9.1.0.

•      Confirm with your network team that the EVPN gateway advertises a default route, and that L3-only reachability is acceptable, before designing around this model.

•      Update pinned versions in your design documents, particularly the Kubernetes release.

The broader lesson is one this series keeps returning to. Release notes are a summary, not the documentation. A release described in one sentence as supportability improvements contained a six-row capability change to a connectivity model and a patch ordering constraint that overrides the normal assumption. Both were in the documentation. Neither was in the summary.

Sources

•      Broadcom TechDocs VMware Cloud Foundation 9.1.1.0 Release Notes (3 September 2026)

•      Broadcom TechDocs Bill of Materials 9.1.1

•      Broadcom TechDocs NSX 9.1.1.0 Release Notes

•      Broadcom TechDocs VCF Operations 9.1.1.0 Release Notes

•      Broadcom TechDocs VCF Automation 9.1.1.0 Release Notes

•      Broadcom TechDocs VCF SDKs, APIs and CLIs 9.1.1

•      Broadcom TechDocs VCF 9.1 documentation (full PDF, Distributed VXLAN model from p.1857)

Related coverage in this series: the Cisco open networking piece on EVPN interoperability, and the design gaps checklist on connectivity model selection.