Manual Chapter : Upgrading to BIG-IP Version 16.1.5

Applies To:

  • BIG-IP APM

    16.1.5

  • BIG-IP Link Controller

    16.1.5

  • BIG-IP Analytics

    16.1.5

  • BIG-IP LTM

    16.1.5

  • BIG-IP PEM

    16.1.5

  • BIG-IP AFM

    16.1.5

  • BIG-IP DNS

    16.1.5

  • BIG-IP FPS

    16.1.5

  • BIG-IP ASM

    16.1.5

Updated Date: 07/07/2026

Upgrading to BIG-IP Version 16.1.5

When you upgrade from an earlier versions of the software, you might need to know about or take care of these configuration-specific issues.

ID Number

Title

Description

Workaround

Fix Text

762097

No swap memory available after upgrading to v14.1.0 and above

After an upgrade to v14.1.0 or higher, swap memory may not be mounted. TMM or other host processes may restart due to lack of memory.

– System is upgraded to v14.1.0 or above.

– System has RAID storage.

May lead to low or out-of-memory condition. The Linux oom killer may terminate processes, possibly affecting service. Typically management activities may be impacted, for example, a sluggish GUI (config utility) or tmsh sessions.

Mount the swap volume with correct ID representing the swap device.

Perform the following steps on the system after booting into the affected software version:

  1. Get the correct ID (RAID device number (/dev/md<number>)):

blkid | grep swap

Note: If there is no RAID device number, perform the procedure detailed in the following section.

  1. Check the device or UUID representing swap in /etc/fstab.

  2. If swap is not represented with the correct ID, modify the /etc/fstab swap entry to point to the correct device.

  3. Enable the swap:

swapon -a

  1. Check swap volume size:

swapon -s

If the blkid command shows there is no UUID associated with the swap RAID device, use the following procedure:

  1. Generate a random UUID:

uuidgen

  1. Make sure swap is turned off:

swapoff -a

  1. Recreate the swap partition with UUID generated in step 1:

mkswap -U <uuid_from_step_1> <raid_device_from_step_1>

  1. Run blkid again to make sure that you now have a UUID associated with the raid device:

blkid | grep swap

  1. edit fstab and find the line

<old_value> swap swap defaults 0 0

  1. Replace the old value, whether it was an incorrect UUID or a device name, with the UUID generated in step 1, for example:

UUID=8b35b30b-1076-42bb-8d3f-02acd494f2c8 swap swap defaults 0 0

None specified

1019793

Image2disk does not work on F5OS BIG-IP tenant.

Image2disk fails to recognize the correct disk to install and installation fails. This occurs with BIG-IP tenants that are running in F5OS partitions. Installation fails.

None

None specified

1014285

Set auto-failback-enabled moved to false after upgrade

In a traffic group, auto-failback-enabled is changed from true to false after config save and upgrade. During the upgrade, the following log can be observed:

info: Warning: Invalid configuration - Traffic Group has high availability (HA) Group “test_HA_Group” assigned and auto-failback-enabled set to true. Resetting auto-failback-enabled to false.

– auto-failback-enabled is set to true and high availability (HA) groups are configured and assigned to traffic-group

– The device is upgraded. Auto-failback-enabled is set from true to false and auto failback is disabled.

After upgrade, set the auto-failback-enabled to true.

None specified

When you upgrade from version 14.x or later, you use the Software Management screens in the Configuration utility to complete these steps. To open the Software Management screens, in the navigation pane of the Configuration utility, expand System, and click Software Management. For information about using the Software Management screens, see the online help.

You cannot roll forward a configuration directly to this version from BIG-IP version 13.x or earlier. You must be running version 14.x (or later) software. For details about upgrading from earlier versions, see the release notes for the associated release.

If this version includes new firmware for your specific hardware platform, after you install and activate this version, the system might reboot additional times to perform all necessary firmware upgrades.

If you upgrade from an earlier version of Advanced WAF, note the following issues.

In version 13.0.0 the ability to export request logs in binary (.csv) and PDF file formats was removed. Log files are exported in HTML format only. The resultant HTML log file can be converted to a PDF by:

  • Printing the HTML page to PDF from the browser window.
  • Scripting the HTML to PDF conversion using CLI can be found in wkHTMLtopdf.

As a result of changes made to the signing of Advanced WAF cookies, performing a clean upgrade may result in cookie violations and blocked traffic. To prevent these, F5 recommends that you perform the following actions before upgrading:

  • Disable the modified domain cookie violation, and re-enable it only after at least 24 hours have passed.
  • If you do not have a wildcard cookie, before the upgrade add an Advanced WAF allowed cookie to the security policy, with the name TS*.
  • Have all clients restart their browsers.

After upgrading, users must synchronize their Cookie Protection settings in the following cases:

  • Systems that share traffic but are NOT in the same device group
  • Systems from different versions that share traffic, even if they are in the same device group

After upgrading, the system performs the following:

  • Turns on staging for all Allowed cookies
  • Applies signature checks on existing Allowed cookies
  • Adds a * wildcard Allowed cookie even if the user did not have on previously Upgrading to version 11.3.0 or later

If you are running Advanced WAF on a vCMP system: For best performance, F5 recommends configuring remote logging to store Advanced WAF logs remotely on syslog servers rather than locally.

After upgrading or installing a new version, before you can use the Advanced WAF, you must set the Advanced WAF resource provisioning level to Nominal. You can do this from the command line, or using the Configuration utility.

Important: Wait 5 minutes after you set the resource provisioning level before making any configuration changes to the Advanced WAF. The system overrides all configuration changes that were made before this process is completed. When the process is not complete, the system informs you by displaying, in the Configuration utility, the following message: ASM is not ready. The system informs you when the process is completed by indicating in the log (/var/log/asm) the following message: ASM started successfully.

For important information needed to prevent traffic from bypassing the Advanced WAF, please see the AskF5 Knowledge Center articles K8018: Overview of the BIG-IP HTTP class traffic flow and K12268: Successive HTTP requests that do not match HTTP class may bypass the BIG-IP ASM.

Note: This section is relevant only if you are working with device groups.

When Advanced WAF is provisioned, the datasync-global-dg device-group is automatically created (even if there are no device-groups on the unit) in any of the following scenarios:

  • First provisioning of Advanced WAF installed.
  • Adding a device to a trust-domain that has another device which already has the datasync-global-dg device-group.
  • Upgrading to when Advanced WAF is already provisioned.
  • Upgrading when the device is joined in a trust-domain that has another device which already has the datasync-global-dg device-group.

This device group is used to synchronize client-side scripts and cryptographic keys across all of the devices in the trust-domain.

Note the following:

  • The synchronization is performed across the entire trust-domain, regardless of the configured device groups.
  • The datasync-global-dg device group must not be removed; it is essential for consistency of client-side scripts and keys across the devices.
  • This device group is created upon provisioning, even if the BIG-IP system is working as a standalone.
  • All of the devices in the trust-domain are automatically added to this device group.
  • This device group is manually synchronized. Therefore, when working with device groups (multiple devices in a trust-domain), customers must choose which device will hold the master scripts and keys. The rest of the devices receive these scripts and keys from the chosen device.
  • This device group is also created on units that do not have Advanced WAF provisioned, but are in a trust-domain with other units which do have Advanced WAF provisioned.