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).
2. Analyze and convert them into Avi-compatible objects (virtual services, pools, profiles, etc.).
3. Generate reports that highlight what was successfully converted and what requires manual attention.
4. (Optional) Push the converted configuration directly into an Avi Controller.

Discover F5 Configuration

The Avi Load Balancer Conversion Tool discovers and converts existing F5 configurations in 2 modes:

• Online Mode: Provide F5 credentials to the ALBCT, allowing it to connect to the F5 BIG-IP and automatically fetch configuration files, certificates, and keys.
• Offline Mode: Manually upload F5 configuration files, certificates, and keys to the conversion tool.

In this post, I will cover the online mode conversion.

The Avi Conversion Tool is shipped in the OVA form factor, and deployment is straightforward. You deploy the appliance and configure the IP address, credentials, etc.

Login to the tool using the credentials that you set during the deployment.

As of v2.7, the ALBCT supports migrating load balancers from F5 and NSX-T.

Click on the start button to navigate to the next screen.

To discover the F5 objects, go to the discovery tab and click Start.

Enter the F5 device IP and credentials to connect. Click Finish to start the discovery process.

The tool takes a couple of minutes to analyze the F5 objects.

The discovery reports show the Active/disabled VS, the VS type, the iRules count, etc. You can download the report for offline analysis.

Pull Configuration from F5 Load Balancer

To migrate the load balancers, navigate to the Migrate tab and click the Start button.

Select the Online Mode and click Next.

Enter the F5 IP address and credentials and click Generate Thumbprint.

Click on the Accept button to accept the generated thumbprint.

Click Next to continue.

Enter the Avi controller details on the staging controller page and click and accept Avi’s SSL thumbprint.

Note: If you don’t have a staging controller in your environment, your staging and destination controller (prod one) will be the same. In that case, select the checkbox “Use the same controller as staging.”

Click Next to proceed.

Select the target placeholders for the VS that you want to migrate.

If your environment is multi-tenant, you would place the migrated VSes in the appropriate tenant, where each tenant has its own SEG, VRF context, etc.

Select the virtual services that you want to migrate and click Migrate selected only.

The import can take a while, depending on the number of virtual services selected for migration.

Analyze F5 Configuration

The conversion tool generates a report displaying the list of iRules, virtual services that were successfully translated to Avi, and those that were not.

Click the “Continue to Configuration” button to see the list of virtual services that require manual intervention.

The conversion tool categorized all the reviewed virtual services as follows:

• Needs Review: These virtual services require manual intervention to proceed further with the migration workflow.
• Auto-Converted: These virtual services do not need any manual intervention.
• Skipped: These virtual services are skipped by the conversion tool script or are not supported by the conversion tool.

In the screenshot below, you can see that the tool has auto-converted 3 virtual services, and the remaining three VS need administrator review.

Clicking on the “Need Review” button opens an editor, providing F5 configuration and the corresponding translated Avi configuration for the particular virtual service for easier comparison.

In the example below, the tool detects that an HTTPS health monitor has a string configured for the receive operation, which was not auto-populated in the Avi config.

This can be fixed by entering an HTTP response code in the generated configuration on the right-hand side, or if it’s non-fatal, you can skip it by clicking Next.

Review the VS config and click Next to continue.

The Review step allows you to check the previous changes performed on the Avi LB configuration objects.

To submit the configuration changes, click the Ready button.

Generate Avi Config

Click on the “Continue to Deploy” button to generate the Ansible playbook for the migration.

Select the virtual services and click “Generate Playbook.”

Starting with v2.7.1, the conversion tool provides a patch option in the UI that can be used to modify the output file before the playbook generation step.

You can use the patch option to customize the playbook. For example, for the validation phase, you can select to only enable VS, keeping the traffic disabled. Similarly, you can pass a parameter to remove the listening port when the VS is down.

Specify the playbook name and click Generate.

Note: I had to change the playbook name to “30-Oct-VL224-Wave1” after taking the screenshot. You will see this name in subsequent screenshots.

The conversion tool generates the following three files on successful playbook generation:

1. A CSV file: This has the list of the virtual services that you are migrating.
2. A YAML file: This has three actions available for the playbook:

• Push to Controller: Use this option to push the Ansible playbook to the destination Avi Load Balancer Controller.
• Download: Select the download option to download the configuration files to your local machine. These configuration (.yml) files can be uploaded to the Avi Load Balancer Controller using Ansible.
• Edit Playbook: Perform further edits to the Ansible playbook as required.

Note: The tool creates 2 YAML files, one for pushing the config to the Avi and the other one (delete.yml) to clean up the config from Avi.

Select the generated playbook and download the files to your local machine for record-keeping.

Push configuration to Avi Load Balancer

To push the converted configuration to Avi, click on the 3 dots and select the “Push to Controller” option.

The config push takes a couple of minutes.

Login to the Avi controller and verify you see the virtual services, VIP, pools, etc, created.

Note: If you haven’t used the patch script to customize the playbook, you will find that the VS and the traffic are disabled on the virtual service.

In the ALBCT UI, the playbook status changes to Completed. Click on the View Transcript option to see the details.

The transcript shows the details of the object created (vs/vip/pool/health monitor, etc.) by the conversion tool in Avi and the total duration of the playbook execution.

Cleanup Avi Config

To delete the pushed objects from Avi, run the delete playbook by clicking on “Push to Controller.”

Wait for a couple of minutes for objects to be deleted from Avi. The playbook status changes to Completed when all pushed objects are deleted.

You can again click on View Transcript to see what objects are deleted by the playbook.

Login to the Avi controller and validate that the objects have been deleted.

And that’s it for this post. In the next post of this series, I will demonstrate using offline mode migration. Stay tuned!!!

I hope you enjoyed reading this post. Feel free to share this on social media if it’s worth sharing.