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
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.
Select the offline mode and click Next.
Click on the browse file option to upload the F5 BIG-IP.conf file. If your virtual services use SSL certificates, you can upload the folder where you have stored the SSL certificates and the key.
Note: if your SSL certificates are passphrase protected, upload the passphrase file (in YAML format) where the key is the SSL certificate name and the value is the actual passphrase.
Enter the Avi controller details and generate and accept the Avi SSL thumbprint.
Note: If you don’t have a staging controller in your environment, select the checkbox “Use the same controller as staging.”
Select the tenant/cloud/SEG for the VS placement and click Next.
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.
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.
Click the Needs Review for the VS that was not auto-converted by the tool.
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 the VS has SNAT configured. Avi skipped this setting because, by default, Avi doesn’t do SNAT for the VS. To use SNAT in Avi, you must have service engines deployed in Active-Standby mode. In this case, check with your app team if they really require SNAT for the VS. If not, you can just skip this setting.
Note: If the application requires SNAT, you must select the SEG that has HA mode set to Active-Standby during the import phase. Also, you must manually enable SNAT on the VS after it is created in Avi by the conversion tool.
Review the Avi LB config for the VS and click Ready to submit the configuration changes.
Repeat the steps for the other VSes that require manual review.
Click on the “Continue to Deploy” button to generate the Ansible playbook for the migration.
Select the virtual services and click “Generate Playbook” to generate the migration playbooks.
Use the patch option to apply customization (any) to the playbook.
Specify the playbook name and click Generate.
The tool generates the config create and config delete playbooks.
Select the generated playbook and download the files to your local machine for record-keeping.
You can also push the playbook to Avi by selecting the playbook and clicking on the 3 dots and selecting the “Push to Controller” option.
And that’s it for this post. In the next post of this series, I will demonstrate using the conversion tool CLI to perform the migration. Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it’s worth sharing.