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
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 with policies configured. This is true for both L4 & L7 types vs. 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.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
[2025-10-27 23:18:58,207] ERROR - f5_config_converter.py [convert:295] Conversion error Traceback (most recent call last): File "/env/lib/python3.12/site-packages/avi/migrationtools/f5_converter/f5_config_converter.py", line 291, in convert test_clone_obj.find_clone_all() File "/env/lib/python3.12/site-packages/avi/migrationtools/f5_converter/clone_cross_tenant_obj.py", line 224, in find_clone_all self.find_refs_and_clone(obj) File "/env/lib/python3.12/site-packages/avi/migrationtools/f5_converter/clone_cross_tenant_obj.py", line 196, in find_refs_and_clone c_obj, c_ref = self.get_clone_ref_obj(parent_tenant, v) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/env/lib/python3.12/site-packages/avi/migrationtools/f5_converter/clone_cross_tenant_obj.py", line 140, in get_clone_ref_obj for child_obj in self.old_avi_config[path_key_map[objtype]]: ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^ |
For the Layer-4 VS, you can use the Avi L4 datascript and leverage the tool’s command line option to generate the migration playbooks manually. See the previous post in this series for the steps.
The same steps don’t work for the Layer-7 type VS, as the datascript used in the procedure is meant only for L4 VS.
After discussing the issue with Broadcom ACT engineering, we were advised to migrate the VS manually by creating the VS and associated objects in Avi. The support for L7 VS will be added to the tool very soon.
Let’s have a quick look at the current configuration of VS running in F5.
The VS is a standard VS configured to listen on port 443.
The virtual service is configured for two-way SSL for end-to-end security.
The VS doesn’t have a default pool configured. It is routing traffic to backend pool members via policy.
The policy is configured to forward traffic to a specific pool based on the SNI in the incoming request.
VS Configuration in Avi
Since the virtual service in F5 is configured to route traffic to pools based on SNI, it will be created in a parent/child fashion in Avi. The parent-child virtual service (VS) configuration is used for efficient virtual hosting, primarily via Server Name Indication (SNI).
What is SNI?
Server Name Indication (SNI) is a method of virtual hosting multiple domain names for an SSL-enabled virtual IP. This allows you to host multiple HTTPS applications on a single VIP address, with Avi intelligently routing connections based on the hostname requested by the client during the TLS handshake. In an SNI configuration, you have a parent VS and one or more child VS.
Parent Virtual Service
The parent virtual service holds the virtual IP, service port, and the network profile. The parent VS can be configured with a wildcard certificate as a catch-all VS for any traffic not matched by the child virtual services, or the parent SSL certificate can be different from the child VS, where each child can have a certificate of its own.
The parent VS services all connection requests from the clients and handles the initial SSL/TLS negotiation until the phase reaches SNI matching, where the child VS will be selected, and the request will be forwarded.
Child Virtual Service
The Child virtual service doesn’t have a VIP or a service port field; instead, it only has an application domain name, which points to the Parent virtual service. Each child represents a specific application/domain (like app1.company.com or app2.company.com). No networking properties are configured on the child virtual services.
A child VS contains application-specific configurations like SSL certificates, pools, policies, DataScripts, etc. It handles all traffic after SNI matching occurs.
SNI Virtual Service Architecture
The diagram below illustrates the concept in a visual form.
Create the Parent VS
It is assumed that you have already created VS objects (pools/monitors/SSL profiles/network profiles, etc.) beforehand.
Select the Parent Virtual Hosting VS option and set the type to SNI.
Configure the VIP for the VS and select the appropriate network profile (created earlier).
Specify the server port and the SSL profile. The TLS certificate needs to be either a wildcard certificate or a certificate that has SAN entries for each URL that will be served by the child VS.
Note: Since no default pool is configured for the VS in F5, it means that the VS is not configured for the catch-all condition, and that’s why the pool is left empty here.
Select the appropriate Service Engine Group for the VS placement.
Create Child VS
Set the VS hosting to Child and select the virtual hosting parent. In the domain name, enter the hostname/FQDN that the VS will serve.
Select the pool that will be servicing the configured domain name and the corresponding SSL certificate. You can use the same SSL profile as the parents.
Select the Service Engine Group for the VS and save the configuration.
And that’s it for this post. In the next post of this series, I will share common issues encountered during the migration and the remediation steps. Stay tuned!!!
I hope you enjoyed reading this post. Feel free to share this on social media if it’s worth sharing.