990849

Loading UCS with platform-migrate option hangs and requires exiting from the command

The UCS loading process with platform-migrate stops responding and hangs after printing:

Platform migrate loaded successfully. Saving configuration. Load UCS with platform-migrate option: tmsh load sys ucs <ucs_name> platform-migrate

Note: If you are loading a UCS archive created on a system running a different software version that also has an ASM configuration, there are other other aspects to consider. See: https://cdn.f5.com/product/bugtracker/ID995629.html The UCS loading process stops responding, causing the device to be in an INOPERATIVE state.

None.

Loading UCS with the platform-migrate option executes smoothly without getting stuck.

985537

Upgrade Microsoft Hyper-V driver

BIG-IP Virtual Edition (VE) on Azure has an issue where the BIG-IP system raises a kernel panic soon after a Network Management Agent update occurs on the host. When performance tests are run on VE in Microsoft Azure, the BIG-IP system loses all connectivity to the pools and becomes unresponsive.

-- Azure Host performs a Network Management Agent (NMAgent) update while TMM is running.

-- Running performance tests of VE in Azure.

The BIG-IP system might restart and the GUI becomes unresponsive during performance testing.

None.

The Microsoft Hyper-V driver has been updated to v4.3.5.

958085

IM installation fails with error: Spec file not found

IM installation fails with an error message: ERROR Error during switching: Spec file not found This can occur when deleting an IM file that is actively installing on one volume, and the BIG-IP system is booted from another volume. Upgrading/Downgrading to another IM does not work until you install a new BIG-IP image on the same disk.

None

During the init process, the system now installs FactoryDefaults if the active IM file is not found on disk.

874677

Traffic Classification auto signature update fails from GUI

Beginning in BIG-IP software v14.1.0, Traffic Classification auto signature update fails when performed using the GUI. The system reports an error: Error: Exception caught in the script. Check logs (/var/log/hitless_upgrade.log) for details. Performing Traffic Classification auto signature update using the GUI. Fails to update the classification signature automatically.

You can use either of the following:

-- Perform Traffic Classification auto signature update operations from the CLI.

-- Use the GUI to manually update Traffic Classification signatures.

Fixed the hitless upgrade script to download the IM packages from the EDSM server for point releases.

862937

Running cpcfg after first boot can result in daemons stuck in restart loop

After running cpcfg and booting into the volume, daemons such as named and gtmd are stuck restarting. Additionally the SELinux audit log contains denial messages about gtmd and named being unable to read unlabeled_t files. Running cpcfg on a volume that has already been booted into. Services do not come up.

None specified

848445

Global/URL/Flow Parameters with flag is_sensitive true are not masked in Referer

Global/URL/Flow Parameters with flag is_sensitive true are not masked in referrer and their value may be exposed in logs. Global/URL/Flow Parameters with flag is_sensitive true are defined in the policy. In logs, the value of such parameter will be masked in QS, but will be exposed in the referrer. The parameter will not be masked in 'Referer' value header in logs, although it is masked in 'QS' string.

839121

A modified default profile that contains SSLv2, COMPAT, or RC2 cipher will cause the configuration to fail to load on upgrade

After upgrading, the configuration fails to load and throws an error about a profile that is located in profile_base.conf using SSLv2. However, upon inspection you will notice that there is no SSLv2 cipher in use.

The upgrade failure is seen when all the following conditions are met:

-- BIG-IP system with SSLv2 as the ciphers option in an SSL profile running software v12.x/v13.x.

-- Upgrading to a version that reports an error when using SSLv2, such as v14.x/v15.x.

(1) Modified root SSL profile (such as /Common/clientssl or /Common/serverssl) is present in bigip.conf.

(2) The modified root SSL profile contains an invalid keyword 'COMPAT', 'SSLv2', or 'RC2' in its ciphers

(3) The default profiles whose ciphers inherited from the root profile are not present in bigip.conf. The error for invalid ciphers is reported against these profiles.

Beginning in version 14.x, SSLv2 has been changed from being a warning condition, and now prevents the configuration from loading. In most cases the upgrade script properly removes this, so there is no issue. However, if this issue is encountered, the configuration fails to load after upgrading.

There are two possible workarounds:

-- The easiest way to work around this is to comment out the modified base profile from bigip.conf and then run the command: tmsh load sys config.

-- If you are post upgrade, you can use sed to remove the !SSLv2 entries. To do so, perform these steps on the standby device:

1. cp /config/bigip.conf /config/backup_bigip.conf

2. Run: sed -i "s/\(\!SSLv2:\|:\!SSLv2\)//g" /config/bigip.conf 3. tmsh load /sys config

None specified

837637

Orphaned bigip_gtm.conf can cause config load failure after upgrading

Configuration fails to load after upgrade with a message:

01420006:3: Can't find specified cli schema data for x.x.x.x Where x.x.x.x indicates an older version of BIG-IP software than is currently running.

-- Orphaned bigip_gtm.conf from an older-version. This can occur if GTM/DNS is provisioned, then deprovisioned before upgrade, leaving behind a bigip_gtm.conf with the old schema.

-- Upgrading to a new version that does not contain the schema for the old version that the bigip_gtm.conf uses.

Configuration fails to load after upgrade.

Before upgrading: If the configuration in bigip_gtm.conf is not needed, then it can be renamed (or deleted) before upgrading:

mv /config/bigip_gtm.conf /config/bigip_gtm.conf.id837637

tmsh load sys config gtm-only

After upgrading (i.e., with the system in the Offline state) services must be restarted to pick up the change:

mv /config/bigip_gtm.conf /config/bigip_gtm.conf.id837637

tmsh restart sys service all

None specified

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.

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

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

4. Enable the swap:

swapon -a

5. 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

2. Make sure swap is turned off:

swapoff -a

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

mkswap -U <uuid_from_step_1> <raid_device_from_step_1>

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

blkid | grep swap

5. edit fstab and find the line

<old_value> swap swap defaults 0 0

6. 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

739505

Automatic ISO digital signature checking not required when FIPS license active

Automatic ISO digital signature checking occurs but is not required when FIPS license active. The system logs an error message upon an attempt to install or update the BIG-IP system: failed (Signature file not found - /shared/images/BIGIP-13.1.0.0.0.1868.iso.sig) When the FIPS license is active, digital signature checking of the ISO is automatically performed. This requires that both the ISO and the digital signature (.sig) file are uploaded to the system. Installation does not complete if the .sig file is not present or not valid. Installation failure.

To validate the ISO on the BIG-IP system, follow the procedure described in K24341140: Verifying BIG-IP software images using .sig and .pem files :: https://support.f5.com/csp/article/K24341140.

The restriction of requiring automatic signature checking of the ISO is removed. The procedure described in K24341140: Verifying BIG-IP software images using .sig and .pem files :: https://support.f5.com/csp/article/K24341140 to perform the checks on or off the BIG-IP system is still valid, but that checking is optional.

718796

iControl REST token issue after upgrade

When upgrading to version 13.1.0.x or later, users who previously had permissions to make calls to iControl REST lose the ability to make those calls.

You will notice this issue when you use iControl REST and are upgrading to version 13.1.0.x or later.

You can also detect if the user is impacted by this issue with the following steps

1. Run below API to for impacted user account XYZ.

# curl -ik -u username:XYZ -XPOST https://localhost/mgmt/shared/authn/login --data-binary '{"username":"XYZ", "password":"XYZpass", "loginProviderName":"tmos"}' -H "Content-Type: application/json"

2. Find user XYZ's 'link' path under 'token' in previous output

There are two formats possible for 'link'

a. Path will have a UUID

For example "token"->"link"->"https://localhost/mgmt/cm/system/authn/providers/tmos/1f44a60e-11a7-3c51-a49f-82983026b41b/users/<UUID>"

b. Path will have a username (not UUID)

For example "token"->"link"->"https://localhost/mgmt/shared/authz/users/<username>"

3. Run below API to get list of user roles.

# restcurl -u "admin:<admin-user-pass>" /shared/authz/roles | tee /var/tmp/rest_shared_authz_roles.json

4. Check user XYZ's link path from step 2 in above output.

Check under the "userReferences" section for group "iControl_REST_API_User" . You will see the link path in one of the two formats listed in 2a/2b. If you do not see the user link path then you are impacted by this bug.

A previously privileged user can no longer query iControl REST. In addition, some remotely authenticated users may lose access to the Network Map and Analytics view after the upgrade.

You can repair the current users permissions with the following process:

1) Delete the state maintained by IControlRoleMigrationWorker and let it rerun by restarting restjavad process:

# restcurl -X DELETE "shared/storage?key=shared/authz/icontrol-role-migrator"

2) Restart services

# bigstart restart restjavad *or* tmsh restart /sys service restjavad

3) Now, when you create a new user, the permissions should start in a healthy state

4) If this still does not resolve the issue you could update shared/authz/roles/iControl_REST_API_User userReference list to add all affected users' accounts using PUT. Here you may need to use the UUID path as described under 'Conditions'

# restcurl shared/authz/roles/iControl_REST_API_User > role.json

# vim role.json

a. add { "link": "https://localhost/mgmt/shared/authz/users/[your-user-name]" } object to userReferences list

OR

b. add { "link": "https://localhost/mgmt/cm/system/authn/providers/tmos/1f44a60e-11a7-3c51-a49f-82983026b41b/users/<UUID>" } object to userReferences list

# curl -u admin:admin -X PUT -d@role.json http://localhost/mgmt/shared/authz/roles/iControl_REST_API_User

When upgrading to version 13.1.0.x or later, users who previously had permissions to make calls to iControl REST retain the ability to make those calls.

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

1019085

Network virtual-addresses fail to retain the "icmp-echo enabled" property following an upgrade or reload of the configuration from file.

Network virtual-addresses default to "arp disabled" and "icmp-echo disabled". However, a BIG-IP Administrator can change these settings to "enabled", if required. Either following a software upgrade or a reload of the configuration from file, network virtual-addresses that had previously been set to "icmp-echo enabled" revert to the default of "icmp-echo disabled".

- One or more network virtual-addresses configured with "icmp-echo enabled".

- A software upgrade or reload of the configuration from file occurs (for example, taking and restoring a UCS archive, removing the mcpd binary database and reloading the config, etc.).

Traffic failures can occur as a result of the affected network virtual-addresses not being presented to the surrounding network as originally intended by the BIG-IP Administrator.

Manually configure the affected virtual-addresses to "icmp-echo enabled" again. This workaround is not permanent, and the issue will occur again in the future given the right conditions.

Network virtual-addresses no longer lose the "icmp-echo enabled" property.

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