How to Upgrade Image in F5 BIG-IP?

1. Upgrade vs. Update: Terminology & Overview

F5 distinguishes between an update (minor, patch-level change) and an upgrade (major release, potentially new features or platform requirements). Regardless of which you’re performing, the core steps are the same:

1. Backup your current configuration (UCS, SCF).
2. Download the target image (ISO) from F5’s downloads site.
3. Upload the image to /shared/images.
4. Install the image to a new boot volume.
5. Reboot into the new volume (or fail over in HA).
6. Validate system health and application connectivity.
7. Rollback if necessary, by rebooting back to the previous volume.

This general flow comes directly from F5’s Upgrade Planning guide.

2. Pre-Upgrade Planning & Prerequisites

Before touching the TMOS shell or GUI, do the following:

2.1. Health Checks & Backups

• Check system health:

bash
tmsh show sys health tmsh show sys software # verify current versions tmsh show sys health
tmsh show sys software   # verify current versions and volumes
df -h                     # ensure you have free space on `/shared` and `/var`  

• Backup your config:
  • UCS archive (includes licenses, user accounts, certs):

bash
tmsh save sys ucs /var/local/ucs/pre-upgrade.ucs

• SCF + filestore (human-readable diffing):

bash
tmsh save sys config file /var/local/scf/fullconfig no-passphrase

2.2. License Verification

F5 images often include a license check date, which your license file must meet or exceed. If your license is out of date, the upgraded volume won’t load your config . To verify:

bash
tmsh show sys license

If the Service Check Date in your license is older than the License Check Date baked into the new TMOS image, reactivate your license before upgrading.

2.3. Maintenance Window & Stakeholders

• Notify application owners and network operations of the expected impact.
• Schedule a maintenance window long enough for two reboots (standalone) or two failover cycles (HA).
• Ensure console (serial, iLO, DRAC) access is ready—SSH alone may not be sufficient if network settings change.

These steps are part of the “Plan of Action” originally laid out in community best practices.

3. Downloading & Uploading the TMOS Image

1. Download the ISO from F5’s support portal.
2. Verify the MD5 or SHA256 checksum matches the F5-published value.
3. Upload to your BIG-IP: On Windows, you can use WinSCP to transfer the ISO to /shared/images/.

bash
scp BIGIP-16.X.X-0.0.X.iso root@<BIG-IP-management-scp BIGIP-16.X.X-0.0.X.iso root@<BIG-IP-management-IP>:/shared/images/

4. Installing the Image to a New Volume

You can use tmsh on both standalone and HA systems:

bash
tmsh
sys software image install BIGIP-16.X.X-0.0.X.iso volume HD1.X

• volume HD1.X specifies the target boot volume; if omitted, tmsh chooses the next available volume.
• The system imports your running config into the new volume automatically.
• Do not reboot yet if you intend to perform the install on a standby device in an HA pair.

This CLI-based approach ensures you get exactly the same process every time.

5. HA Upgrades: Standby First, Then Active

To minimize downtime in a High Availability (Active/Standby) pair:

• Identify the standby unit:

bash
tmsh show cm failover-status

• Install the new image on standby (see Section 4).
• Reboot standby into the new volume:

bash
tmsh reboot volume HD1.X

• Validate that the standby comes up cleanly, syncs config, and passes smoke tests (virtual servers, pools).
• Force failover—make the upgraded node Active:

bash
tmsh run cm failover standby

• Install and reboot the former active (now standby) unit.
• Fail back if desired, or leave the new node active once both sides are on the same version.

This zero-or-minimal-downtime workflow is the heart of the community Plan of Action, and matches F5’s official HA upgrade guide.

6. Post-Upgrade Validation

After both nodes are on the new TMOS image:

• Verify version:

bash
tmsh show sys version

• Check config sync:

bash
tmsh show cm sync-status

• Test traffic flows against key Virtual Servers (LTM) or DNS zones (GTM).
• Monitor logs (/var/log/ltm, /var/log/audit) for errors or unexpected errors.
• Confirm custom iRules, SSL profiles, and certificates are intact.

Only once you’ve signed off on these checks should you consider the upgrade complete.

7. Rollback Plan

If you detect failures or incompatibilities:

• Reboot the affected unit back to the previous volume:

bash
tmsh reboot volume HD1.Y

• Re-sync configuration from the working peer (HA), or restore your UCS (standalone).
• Investigate upgrade logs under /var/log/upgrade/ for root-cause analysis.

Because you never deleted the old boot volume, rollback is trivial and fast.

8. Automating with BIG-IQ or REST API

• BIG-IQ orchestration can push images, schedule upgrades, and monitor progress across fleets.
• iControl REST scripts can perform:
  • Image upload (/mgmt/shared/file-transfer/uploads)
  • Software install (POST /mgmt/tm/sys/software/image)
  • Volume reboot (POST /mgmt/tm/sys/software/volume)

Embedding these steps into CI/CD pipelines ensures consistency, audit trails, and self-service upgrades for large teams.

Please follow and like us: