Welcome to part 8 of the VCF-9.1 home lab series. The previous post in this series discussed setting up network connectivity in the management domain. In this post, I will demonstrate deploying the Avi load balancer in the workload domain.
If you are not following along, I encourage you to read the earlier parts of this series from the links below:
3: VCF 9.1 Pre-Deployment Planning
4: Setting up VCF 9.1 Offline Depot
5: VCF 9.1 Deploy Management Domain
6: Configure Management Domain Network Connectivity
Avi and VCF Integration
VCF 5.2.X was the first version that enabled deploying the Avi load balancer using SDDC Manager. Although the deployment of the controller nodes was automated and some aspects of the Avi life-cycle management (password, certificates, and upgrade) were tied to the SDDC Manager, the configuration was largely manual and error-prone. This behavior continued in VCF 9.0.
Avi integration with VCF has matured dramatically with the 9.1 release. One of the biggest shifts in VCF 9.1 is that VCF Operations now owns the full lifecycle of Avi Load Balancer. This covers initial deployment, upgrades, certificate and password rotation, and configuration drift detection. What was once a largely manual, error-prone configuration exercise has been transformed into a streamlined, lifecycle-managed, multi-tenant platform that aligns closely with the cloud operating model enterprises are trying to achieve.
In this blog, I will cover architecture, prerequisites, step-by-step deployment, NSX VPC integration, multi-tenancy, and avoid common pitfalls for a successful Avi deployment in a VCF 9.1 environment.
Why is Avi in VCF 9.1 a game changer?
VCF 9.1 added new capabilities for Avi and the components that consume Avi. These include:
- Distributed Transit Gateway (DTGW) Support: VCF 9.1 adds support for Distributed Transit Gateway alongside the Centralized Transit Gateway introduced in 9.0. This gives architects more flexibility when designing multi-tenant network topologies, particularly in large-scale environments where traffic isolation between organizations is a hard requirement.
- Provider-Managed and Organization-Managed Service Engine Groups: Avi in VCF 9.1 introduces two Service Engine Group deployment models: provider-managed (shared across organizations) and organization-managed (dedicated per organization). These models include quota-based controls, which allow operators to govern resource consumption at the organization level—a critical capability for chargeback and capacity planning in multi-tenant clouds.
- Centralized and Tenant-Based Licensing: Licensing for Avi is now centrally managed and enforced through VCF Operations, with tenant-based granularity. This eliminates the fragmented per-cluster licensing management that plagued earlier deployments.
- Self-Service Analytics in VCF Automation: Avi analytics are now surfaced directly inside the VCF tenant portal and VCF Automation UI. DevOps teams can view health scores, application latency, error rates, and throughput without needing full Avi administrative access, enabling faster troubleshooting through role-based visibility.
Avi Integration with NSX VPCs
VCF 9.0 introduced a VPC-aware deployment model for Avi, and it has been significantly expanded in 9.1; the NSX fabric is now organized around organizations, projects, and VPCs. Avi integrates at this level to provide LBaaS within tenant VPCs.
The Avi network architecture includes:
- Management Network: The Avi Controller cluster and SE management interfaces reside on a dedicated VLAN-backed or overlay segment with connectivity back to the Controller.
- Data Networks: SE data interfaces connect to VPC-backed private network segments. VIP addresses are allocated from the VPC’s IP address pools — no manual IPAM configuration is required.
- VPC External IP Blocks: Routable VIP addresses for external-facing virtual services are allocated from the VPC External IP Blocks defined during VPC connectivity profile setup.
One critical architectural constraint to note is that Avi uses a one-arm load-balancing setup in VPC mode. This means SEs have a single data interface connected to the VPC network, and traffic is routed through the NSX fabric rather than using a separate return path. This simplifies SE network configuration but requires that the NSX DTGW or Centralized Transit Gateway be correctly configured for north-south routing.
Deployment Prerequisites
- A workload domain is deployed and is in a ready state.
- The Avi 32.1.x install binary is downloaded and available in the software depot.
- DNS records for the 3 controller nodes and Avi VIP are created in the DNS. A total of 4 IPs are required for the deployment.
- A local content library is available for storing service engine images.
Deploy Avi Controller Cluster
Login to the VCF Operations and navigate to Build > Lifecycle > VCF Instances and select the workload domain where Avi will be deployed.
Click the Manage Components option to open the Avi deployment tile. Click Install to proceed.
Select the Avi version to deploy. VCF 9.1 supports Avi 32.x versions only.
Selecting the version triggers a compatibility check. The Next button gets enabled only after a successful check.
Click Next to continue.
Select the Avi Controller form factor.
Choose based on your scale requirements. Small handles up to ~50 virtual services; medium supports several hundred; and large is appropriate for large multi-domain deployments. Consult the Avi Controller Sizing documentation for current resource requirements.
Provide Avi Controller node IPs and the cluster VIP. Also, specify the Avi portal login password.
Review the settings and click Finish. If one or more workload domains share the same NSX Manager, Avi will be available across all such workload domains.
The wizard will provision the Controller VMs in the Management Domain cluster, configure the initial cluster, and establish the integration with vCenter and NSX. This typically takes 30-45 minutes depending on storage performance.
Click the tasks tab to see the backend tasks that VCF OPS executes during the Avi cluster deployment.
After successful deployment of the Avi controller cluster, login to the Avi portal and configure the backup passphrase and search domain.
Update Licensing Tier
The default installation of Avi is configured to use the cloud licensing. If you have an Avi license key, change the model to the “On-prem License Hub.”
This requires deploying a license server that I will cover in a later post.
The Avi portal provides instructions for deploying a license hub.
Navigate to the Infrastructure > Clouds tab, and you will notice that the cloud health reports down. The reason is that the NSX cloud doesn’t know which transport zone to use and what is the management network for Avi SE.
The deployment wizard never asks for this information. As per my conversation with the Broadcom Avi PM, this will be fixed in the upcoming version of VCF. Edit the NSX cloud to specify the overlay transport zone and SE management network.
Note: Before modifying the NSX Cloud, ensure that you have created a dedicated tier-1 gateway and a segment for SE management. This segment must be able to route to the infrastructure management network where Avi controllers are deployed.
Under the management network settings, select the overlay transport zone in which you deployed the tier-1 gateway and Avi SE management network.
Repeat the same for specifying the Avi VIP network.
Note: For a VCFA environment, the data networks are auto-plumbed when Avi is enabled on an organization. So, if you are planning to integrate Avi with VCFA, either provide a dummy network for the data network or use the Avi SE management network. There is no hard configuration check for this.
Next is to edit the vCenter configuration and add the local content library and save the cloud settings.
The cloud configuration takes 2-3 minutes to complete, and if the provided values are correct, the NSX cloud connector status reports UP. During the configuration, the Avi controller validates SE management network reachability and pushes the SE image into the content library.
In the NSX cloud connector configuration, you will notice that there are 2 configurations that are enabled by default:
- Onboard Avi in NSX.
- Enable VPC mode.
In the VPC mode, Avi will dynamically discover NSX VPCs, projects, and IP address pools. You do not need to manually define IP address ranges for VIPs—Avi reads these directly from the NSX fabric.
The next step in the configuration is to configure the Service Engine Groups. I will cover this later when demonstrating Avi usage with VCFA.
Conclusion
Deploying Avi Load Balancer in VCF 9.1 is a better experience compared to earlier VCF releases. The combination of centralized lifecycle management in VCF Operations, native VPC-aware LBaaS, and automated multi-tenancy controls delivers a coherent platform that spans infrastructure operators, platform engineers, and application developers.
And that’s it for this post. In the next post of this series, I will discuss supervisor deployment. Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing.