Seamless Upgrade of F5 BIG-IP SSL Orchestrator (SSLO) L3 HA Cluster Without Downtime
Introduction
Upgrading the SSL Orchestrator (SSLO) in a high availability (HA) deployment can be a daunting task. especially in the BFSI sector, where even minimal downtime can impact mission-critical services such as net banking and mobile banking.
While F5’s official knowledge article K64003555 provides detailed steps for SSLO upgrades, it typically involves a 30–45 minute service outage. This may not be acceptable in many production environments.
This article provides a practical, tested method to upgrade SSLO (version 15.x.x and above) in an HA cluster without any service disruption.
Step-by-Step: Zero-Downtime Upgrade Procedure
1. Convert Full SSLO Topologies to LTM VIPs
SSLO topologies consist of tightly coupled components: virtual servers, access profiles, per-request policies, service chains, inspection services, and iRules. These objects are auto-generated and logically bound. Manual changes or upgrades can cause them to break or behave unpredictably.
To avoid this, the first step is to recreate your SSLO traffic flow using native LTM virtual servers.
Use duplicate IPs (or source IP-based routing) to create new LTM VIPs. Attach the corresponding SSLO access policies, profiles, and iRules to the LTM VIPs manually.
Test traffic flow through these LTM VIPs to ensure they replicate the behavior of your existing SSLO topologies.
Note: In my setup, I used existing VIP IPs by limiting the source address to my own public IP. I then changed source matching rules for controlled traffic diversion during testing.
2. Detach SSLO Profiles/Policies from VIPs on the Standby Device
Once the LTM VIPs are functional and validated, detach SSLO-related profiles from them on the standby device before starting the upgrade.
Use the following example command:
modify ltm virtual myapp.example.com \
per-flow-request-access-policy none \
profiles delete { sslo_myapp_topology.app/sslo_myapp_topology_accessProfile } \
rules none
Once detached, the device will act as a standard LTM unit—safe for upgrades without SSLO-related interruptions.
3. Upgrade Standby Device to New TMOS Version
Continue to upgrade the standby SSLO device to your desired TMOS version (e.g., from 16.x to 17.x). Follow the standard BIG-IP upgrade process:
⚠️ Important: Do not access SSLO → Configuration in the GUI before both devices are upgraded. This may trigger an SSLO RPM package upgrade prematurely.
4. Validate Post-Upgrade Configuration
After the upgrade:
- Confirm all access policies and profiles are present via Access → Profiles / Policies
- Verify that the LTM VIPs created earlier are intact and function as expected.
5. Re-Attach SSLO Policies and Profiles
Once validation is complete, re-attach the access profiles, policies, and rules to the respective LTM VIPs. You can automate this using TMSH commands, like the example below:
modify ltm virtual myapp.example.com \
per-flow-request-access-policy ssloP_IDS_IPS_WAF.app/ssloP_IDS_IPS_WAF_per_req_policy \
profiles add { sslo_appname.app/sslo_appname_accessProfile { } } \
rules { sslo_appname.app/sslo_appname-min_in_t ssloS_WAF.app/ssloS_WAF-port_remap }
6. Failover to the Upgraded Device
Perform a manual failover to the upgraded standby device. Monitor application behavior and test traffic flow thoroughly.
7. Repeat for the Second Device
Now, repeat Steps 2–6 for the second (now standby) SSLO device. This will complete the upgrade process for the full HA pair.
8. Trigger SSLO GUI Upgrade
Once both devices are upgraded and traffic is tested from both nodes, access SSLO → Configuration via GUI. This will initiate the SSLO RPM package upgrade safely.
9. Monitor Upgrade Status
Use the following REST API calls for monitoring upgrade progress and sync status:
restcurl -u admin: shared/gossip | grep status
restcurl -u admin: tm/cm/device
restcurl -u admin: tm/cm/device | jq '.items[] | {devicename: .name, ConfigSyncIP: .configsyncIp, UnicastAddress: .unicastAddress}'
References
Conclusion
Upgrading a F5 SSLO HA cluster without downtime is possible with proper planning and by converting topologies into LTM-native VIPs. This approach ensures continuous traffic flow and minimizes the risk associated with auto-generated SSLO objects during upgrades.
Employee