Avi Load Balancer 32.1.1: VCF 9.1, MCP Traffic, and the Licensing Shift

Avi 32.1.1 lands native VCF 9.1 integration, MCP load balancing for AI agent workloads, and the same licensing model change shipping in SSP 5.1.2. Here’s what it means in practice.

Avi Load Balancer 32.1.1 went GA on May 12, 2026 — the same day as SSP 5.1.2. The headline additions are deep VCF 9.1 integration, MCP load balancing support, and a licensing model change that mirrors what SSP 5.1.2 introduces for vDefend. There are also 65 resolved issues, which on its own would make this worth prioritizing.

VCF 9.1 integration

The most operationally significant change in 32.1.1 is how Avi sits inside a VCF 9.1 environment. In previous releases, Avi was a capable but somewhat separately-managed layer. In 32.1.1, it becomes a first-class component of the VCF stack.

Deployment and lifecycle management move through VCF Operations. Discovery and integration with vCenter and NSX Manager are automatic. Load balancing services become self-service through VCF Automation, with organization-based resource governance — quotas and tenant isolation — built in. On Kubernetes, AKO deploys automatically onto VKS clusters rather than requiring a separate installation step.

The practical effect is that Avi stops requiring its own administrative orbit in VCF environments. Teams provisioning workloads through VCF Automation can get load balancing alongside compute and networking without a separate Avi workflow. For multi-tenant VCF deployments, the quota and isolation model means you can delegate load balancing capacity to individual organizations without giving them access to the broader Avi controller.

MCP load balancing

The addition of MCP load balancing is worth paying attention to even if you don’t have MCP deployments today. MCP is the protocol that AI agents use to call tools — the traffic that flows between an agent and the functions it can invoke. As internal AI agent deployments scale, MCP traffic starts looking like any other application traffic that needs load balancing: multiple backend instances, session affinity requirements, and authentication at the edge.

32.1.1 handles MCP with session persistence and OAuth 2.0 authorization. The session persistence piece matters because MCP is stateful — an agent session that crosses to a different backend mid-conversation loses context. The OAuth 2.0 support means Avi can enforce authorization at the load balancer before traffic reaches the MCP server, which is where you want that check to happen.

If you’re running internal AI tooling and haven’t thought about what load balancing looks like for those workloads yet, this release is a reasonable prompt to do so.

The licensing change

32.1.1 deprecates the legacy 25-character license key format in favor of digitally signed subscription files, aligned with the change shipping in SSP 5.1.2. YAML license files are also deprecated. Going forward, Avi licensing runs through either Cloud Licensing (connected mode via VMware Avi Cloud Console) or License Hub (the on-premises option introduced in SSP 5.1.2).

If you’re running both Avi and vDefend, the licensing infrastructure now converges: a single License Hub instance manages both. That’s a consolidation worth planning around — getting License Hub in place before your next Avi or VCF upgrade is cleaner than retrofitting it under pressure.

Bug fixes worth knowing about

65 resolved issues is a large number. A few stand out:

VIP sharing across Virtual Services no longer causes failover failures — a class of issue that tends to surface at the worst possible time.
Memory exhaustion from extended rolling window durations is corrected, along with a SE partition state issue that could manifest after 30 or more days of uptime.
WAF policy cloning now preserves Positive Security Groups, which previously required manual reconstruction after a clone.
GSLB geo-location algorithm failures on site location updates are fixed.
Configuration import with private key certificates is now supported.

The WAF CRS default version also updates to 2025-2 in this release — worth confirming your custom rules and per-URI overrides are compatible before upgrading.

What to do before you upgrade

Check your license format. If you’re on 25-character keys, get them migrated through the Broadcom Support Portal before the upgrade window. The migration process is straightforward but has no shortcut under time pressure.

If you have rolling window durations configured beyond 60 minutes in your event rules, 32.1.1 will cap them automatically at upgrade — verify that the automatic reduction doesn’t break any alerting thresholds you’re relying on.

For HTTPS health monitors: 32.1.1 requires an associated SSL profile within the pool configuration. If you have bare HTTPS health monitors without an SSL profile, add one before upgrading.

Known issue AV-267509 affects hybrid Linux Service Cloud deployments — SE upgrades to 32.1.1 will fail without a manual workaround. If that describes your environment, read the release notes before scheduling the upgrade window.