How to Deploy Avi 30.x/31.x in VCF 9.x

By default, VCF 9 deploys the v22.x of Avi, which is too old. To use newer versions of Avi in the VCF 9.x setup, Broadcom provides a shell script. This script uploads the newer Avi OVA and updates the SDDC Manager manifest file so that the new Avi can be selected in the SDDC Manager UI.

The shell script and helper files can be downloaded from the Avi GitHub repo

This shell script performs the following tasks:

  • Uploading the Avi bundle to the SDDC manager.
  • Uploading the SDDC manager root certificate to the NSX manager as a trusted CA.
  • Registering the Avi enforcement point in NSX Manager.

Analyze the Shell Script

The shell script (vcf_tools.sh) contains 2 helper files:

1: pvc.json: This file contains the information of the Avi install bundle name and the build number. If the build number of the Avi installer bundle that you downloaded from Broadcom’s portal is not in the JSON file, update it.… Read the rest

F5 to Avi Load Balancer Migration – Part 7: Migrate Complex L7 VS with Policies

Welcome to part 7 of the F5 to Avi migration series. The previous post in this series discussed the migration method of complex L4 virtual services. In this post, I will demonstrate the migration of L7 virtual services that have policies configured.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: Migration Strategy Framework

3: Avi Assessment Framework

4: F5 to Avi – Online Mode Migration

5: F5 to Avi – Offline Mode Migration

6: Migrate Complex L4 VS with Policies

The Avi Conversion Tool currently has a limitation when migrating virtual services (L4/L7) with policies (complex iRules)configured.  When you migrate such a VS; the ACT UI skips the policy part.

In the converter.log, you will see an error similar to that shown below.

Read the rest

F5 to Avi Load Balancer Migration – Part 6: Migrate Complex L4 VS with Policies

Welcome to part 6 of the F5 to Avi migration series. The previous post in this series discussed the migration method for offline mode. In this post, I will demonstrate migrating complex L4 virtual services.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: F5 to Avi – Migration Strategy Framework

3: Avi Assessment Framework

4: F5 to Avi – Online Mode Migration

5: F5 to Avi – Offline Mode Migration

Not all F5 virtual services can be migrated to Avi using the Avi Conversion Tool. The tool currently has a limitation of migrating L4 virtual services configured for SNI-based routing policy. When you attempt to convert such a VS to AVI format using the conversion tool UI, the tool skips the policies.

Migration of such virtual services is not possible through ACT UI, and you have to do this manually using the converter Python script.… Read the rest

F5 to Avi Load Balancer Migration – Part 5: Offline Mode Migration

Welcome to part 5 of the F5 to Avi migration series. The previous posts in this series discussed the online mode migration of the load balancer from F5 to Avi. In this post, I will demonstrate the offline mode migration.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: F5 to Avi – Migration Strategy Framework

3: Avi Assessment Framework

4: F5 to Avi Online Mode Migration

Offline migration is typically needed when you want to migrate F5 BIG-IP configurations to AVI without direct connectivity between systems or in air-gapped environments. To convert the F5 objects, you manually upload the F5 configuration file (bigip.conf), certificates, and keys to the conversion tool.

To perform offline migration, login to the conversion tool and navigate to the Migrate tab, and click Start. Read the rest

F5 to Avi Load Balancer Migration – Part 4: Online Mode Migration

Welcome to part 4 of the F5 to Avi migration series. The previous posts in this series aimed to provide a comprehensive framework for the F5 to Avi migration strategy and planning migration waves. In this post, I will demonstrate how to migrate load balancer objects between the 2 platforms.

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: F5 to Avi – Migration Strategy Framework

3: Avi Assessment Framework

Avi Load Balancer Conversion Tool

To migrate load balancer objects from F5 to Avi, VMware provides a migration tool called “Avi Load Balancer Conversion Tool (ALBCT),” a UI-based conversion tool that automates and simplifies migration of existing F5 load balancer configurations to the Avi Load Balancer platform. The conversion tool helps you:

  1. Import configuration files from existing load balancers (F5).
Read the rest

F5 to Avi Load Balancer Migration – Part 3: Identifying Migration Candidates

Welcome to part 3 of the F5 to Avi migration series. Part 1 of this series discussed use cases of Avi migration, and part 2 dived into the migration framework that you should follow for a successful error-free migration. 

If you are not following along, I encourage you to read the earlier parts of this series from the links below:

1: Introduction to F5 to Avi Load Balancer Migration

2: F5 to Avi – Migration Strategy Framework

Overview

Not all F5 virtual services and configurations are equally suited for immediate migration to Avi. A strategic assessment helps prioritize migrations, manage risks, and allocate resources effectively. In this post I will try to provide a comprehensive framework for evaluating F5 objects and determining migration candidacy.

Step 1: Understand the Goal of Migration

Before identifying good candidates, clarify the purpose:

  • Are you moving to reduce licensing costs (F5 → NSX ALB built into NSX or vSphere+ licensing)?
Read the rest

F5 to Avi Load Balancer Migration – Part 2: Migration Strategy Framework

In the first post of this series, I discussed the top reasons why an organization wants to move from F5 to Avi load balancer. In this post, I will discuss the migration strategy for a successful migration.

To migrate from F5 to Avi Load Balancer, VMware provides a free Avi Load Balancer Conversion Tool (ALBCT) that automates the translation of F5 BIG-IP configurations. The migration process involves using this tool to convert the F5 load balancer configuration and then cutting over traffic to the Avi-based environment.

Migration Strategy: An Eight-Stage Approach

The key to successful migration is meticulous planning, comprehensive testing, and leveraging Avi’s conversion tool to automate complex configuration transformations. With proper execution, organizations emerge with a modern, scalable, and easier-to-manage load balancing platform that supports their digital transformation initiatives.

The image below lists the various stages involved in the strategic planning for a successful migration.

Stage 1: Planning and Assessment

Before any technical work begins, thorough planning is essential.Read the rest

F5 to Avi Load Balancer Migration – Part 1: Introduction

Introduction

In today’s digital-first world, enterprises are under constant pressure to modernize infrastructure, adopt hybrid and multi-cloud architectures, and deliver applications faster.  As enterprises accelerate their digital transformation journey, legacy load-balancing infrastructure is becoming a bottleneck. The rise of cloud-native applications, containerization, and the need for operational simplicity have prompted many organizations to evaluate modern alternatives.

F5 BIG-IP, while robust, lacks the agility, automation capabilities, and cloud-native architecture that modern applications demand. On the other hand, Avi Load Balancer, a software-defined, cloud-native alternative, offers organizations the flexibility to evolve their infrastructure with minimal disruption.

In this blog, I will cover the key use cases driving migration from F5 to Avi Load Balancer.

Use Cases for F5 to Avi Migration

Migrating from F5 to Avi helps organizations modernize their application delivery infrastructure, reduce operational complexity, and achieve cloud agility. Below are some common use cases for F5 to Avi migration.

1. Cloud and Multi-Cloud Strategy Enablement

Organizations are adopting multi-cloud architectures to avoid vendor lock-in and leverage best-of-breed services across providers.Read the rest

How to Upgrade NSX ALB in a GSLB Setup

The Global Server Load Balancing (GSLB) function of NSX ALB (Avi) enables load balancing for globally distributed applications/workloads (usually, different data centers and public clouds). GSLB offers efficient traffic distribution across widely scattered application servers. This enables an organization to run several sites in either Active-Active (load balancing and disaster recovery) or Active-Standby (DR) mode.

In a GSLB setup, the corporate DNS server delegates one or more subdomains to Avi GSLB, which then owns these domains and provides responses to DNS queries from clients. DNS based load balancing is implemented by creating a DNS Virtual Service in Avi. In a GSLB setup, one site is designated as the GSLB leader, and the rest of the sites are GSLB followers. 

If you are new to GSLB, I encourage you to read about the same from the links below:

1: Avi GSLB in VMware Cloud on AWS

2: Avi GSLB for Containerized Workloads

Upgrading Avi controllers is pretty straightforward and is well documented in the product documentation.Read the rest

Force Delete a Stale Virtual Service in NSX ALB

Recently, I ran into an interesting problem in my lab where I couldn’t get rid of an unused Virtual Service in NSX ALB. The attempt to delete was failing with an error: “VS cannot be deleted! ‘It is being referred to by SystemConfiguration object”

I tried deleting the VS via API and it returned the same error

To figure out where this VS is being referenced, I looked through the pool members and other settings in NSX ALB, but I couldn’t discover anything particular. Internet searches were also not very helpful.

I then checked this issue in internal tools and got a hint that I needed to remove the VS reference from the system configuration through API first. Read the rest