Manual Chapter :
Upgrading to BIG-IP Version 14.1.5
Applies To:
Show Versions
BIG-IP AAM
- 14.1.5
BIG-IP APM
- 14.1.5
BIG-IP Analytics
- 14.1.5
BIG-IP Link Controller
- 14.1.5
BIG-IP LTM
- 14.1.5
BIG-IP PEM
- 14.1.5
BIG-IP AFM
- 14.1.5
BIG-IP DNS
- 14.1.5
BIG-IP FPS
- 14.1.5
BIG-IP ASM
- 14.1.5
Upgrading to BIG-IP Version 14.1.5
Upgrading earlier configurations
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 | Description |
|---|---|
660833 | merged repeatedly cores due to unused istats-trigger object The merged process continuously cores. merged restarts. If any of the elements of the istats-trigger configuration are not defined, this issue occurs. For example, all the elements defined in the key of the istats-trigger definition must be defined before the trigger is created. Workaround: None. |
666884 | Message: Not enough free disk space to install! cpcfg cannot copy a configuration on a chassis platform Only on a chassis platform running 12.1.x or 13.0.x. You cannot use cpcfg on a chassis platform. "cpcfg fails with errors similar to the following: info: Getting configuration from HD1.3 info: Copying configuration to HD1.1 info: Applying configuration to HD1.1 error: status 256 returned by command: F5_INSTALL_MODE=install F5_INSTALL_SESSION_TYPE=hotfix chroot /mnt/tm_install/23102.e3MAZU /usr/local/bin/im -force /var/local/ucs/config.ucs info: >++++ result: info: Extracting manifest: /var/local/ucs/config.ucs info: /shared: Not enough free space info: 6144 bytes required info: 0 bytes available info: /var/local/ucs/config.ucs: Not enough free disk space to install! info: Operation aborted. Workaround: Save a UCS from the source volume, reboot to the destination volume, then load that UCS file. Fix: cpcfg could incorrectly calculate the amount of free space available, refusing to do the copy unless the /shared filesystem had sufficient space to do the copy. This has been resolved and this free space calculation is done correctly. |
667148 | Config load or upgrade can fail when loading GTM objects from a non-/Common partition GTM config referencing non-/Common partition objects from /Common. GTM configuration fails to load, which may keep a system from becoming active GTM configuration fails to load. Workaround: No workaround. Fix: Fixed issue preventing GTM configurations from loading when non-Common partitioned items present. |
673664 | TMM crashes when sys db Crypto.HwAcceleration is disabled. This occurs when sys db Crypto.HwAcceleration is disabled. TMM crash. Traffic disrupted while tmm restarts. TMM crashes when sys db Crypto.HwAcceleration is disabled. Workaround: "Enable crypto hardware acceleration using the following command: tmsh modify sys db crypto.hwacceleration value enable" |
673832 | Performance impact for certain platforms after upgrading to 13.1.0. "The following platforms, with Fast HTTP/OneConnect/Full Proxy configured. -- i2800 -- i4800 -- i5800 -- i7800 -- i10800 -- i11800 -- B2250 -- B4450 The performance impacts occur on the following platforms under the associated conditions: Performance impact for certain platforms after upgrading to 13.1.0. Workaround: None. Fix: Performance impact for certain platforms has been eliminated. |
681377 | The BIG-IP system sends out SYN/ACK with MSS 0 in VLAN syncookie protection mode on some platforms Hardware syncookie is enabled on a VLAN that is under SYN flood attack and the syncookie protection is triggered. This occurs on the following platforms: BIG-IP series 5000, 7000, and 10000 platforms, and VIPRION B2100, B2150, B2250, and B43x0 blades. Most TCP clients can handle these SYN/ACK packets gracefully, but some clients (such as Ixia traffic-test appliances) may not be able to handle them properly, thus impacting traffic. A firmware issue exists on certain platforms that will result in SYN/ACK packets with an MSS filed with a value of 0, even though TMOS sets it to a different value. Workaround: Turn off hardware VLAN syncookie protection if regular TCP traffic is impacted. Fix: In 13.1.0, the per-VLAN-based syncookie protection will be disabled in the data plane BIG-IP series 5000, 7000, and 10000 platforms, and VIPRION B2100, B2150, B2250, and B43x0 blades. |
684068 | FIX with PVA offload and late binding without flow release may not execute iRules on subsequent messages. -- Configure a virtual server with a FastL4 profile and a FIX profile. -- Configure the FastL4 profile to have late binding and explicit flow migration. -- Place iRules on the virtual server that trigger on FIX_MESSAGE or FIX_HEADER. -- Restart the BIG-IP, connect to the virtual server and begin sending FIX messages." The iRules may not trigger on the second and further messages sent to the FIX virtual server on the first connection after the restart. With a virtual server configured with a FastL4 profile and a FIX profile where the FastL4 profile is configured with late binding and explicit flow migration, the first connection after a setup or restart may not correctly execute FIX iRules if the flow is not handed off to ePVA after the first FIX message. Workaround: None. |
686190 | LRO performance impact with BWC and FastL4 virtual server -- BWC is configured. -- Virtual server has a FastL4 profile assigned. -- LRO is enabled (enabled by default in 13.1.0). Very large performance impact to the BWC policy (up to 75%). For example, if the BWC policy rate limit is set to 100Mb, the actual rate limit could be 25Mb. Using Bandwidth controller (BWC) might result in a very large drop in performance of up to 75%. In this release, Large receive offload (LRO) is enabled by default. Workaround: "Disabling LRO recaptures most of the performance degradation related to using FastL4. To disable LRO (this is a system-wide setting), run the following command: tmsh modify sys db tm.largereceiveoffload value disable Important note: Although you can disable LRO to recapture much of the 13.0.0-level performance, you will likely still experience some impact: 2-5% for small files, 17-22% degradation for the '10 requests per connection' benchmark. The only guaranteed way to avoid performance degradation is to remain on version 13.0.0." |
686307 | Monitor Escaping is not changed when upgrading from 11.6.x to 12.x and later -- Upgrading and rolling forward monitor configuration data. -- LTM policy data present. Monitors may not work after upgrade. "When upgrading, monitor attributes such as receive string and send string might contain escape sequences that must be processed after the upgrade. However, due to a problem introduced by the LTM policy upgrade script, this processing is not performed, resulting in monitors not functioning correctly after the upgrade. Note: Without LTM policies in the configuration, monitors upgrade without problem." Workaround: No workaround at this time. Fix: This release addresses the underlying problem so the issue no longer occurs. |
696525 | B2250 blades experience degraded performance. This occurs when the FastL4 profile is configured to offload to hardware and the service provider DAG is configured and in use on B2250 blades. Performance will be degraded due to more connections being handled in software. B2250 blades have degraded performance by up to 17%. This is caused by connections not being offloaded to hardware as often as expected. Workaround: None. Fix: The performance issue for the B2250 blades has been fixed. |
698182 | Upgrading from 13.1.1 to newer release might cause config to not be copied over Upgrade or loading a UCS from 13.1.1 to newer release. Config cannot be loaded or fails. Upgrading from 13.1.1 to newer release might cause config to not be copied over. This is due to the UUID being available on the older release but not on the newer one. Workaround: Copy config and remove UUID-specific schema before loading the config. Fix: When upgrading to a version in which UUID is not supported, the system now automatically copies the config and removes UUID-specific schema before loading it. |
699249 | The config may not load after upgrade if syslog-ng syntax is not valid "In v13.0.0, the syslog-ng version changed from 2.1.4 to 3.8.1. Syslog-ng include options may contain syntax which is correct in 2.1.4 syslog but is not correct in 3.8.1. TMOS does not parse the 'include' option, or translate it from older versions to newer, or any other modification. It blindly copies it into the configuration file." The config will not load after upgrade if the syntax is not valid in a new syslog-ng version. The config is not loaded after upgrade Workaround: "Manually modify the 'include' option in BIG-IP_base.conf file after upgrade. The config cannot be loaded so tmsh will not work." |
699624 | Config with custom 'SIP' or 'Firepass' monitor fails to load after upgrade Custom 'SIP' or 'FirePass' monitor is configured, and the config is upgraded from a version earlier than v13.1.0 to version v13.1.0. "After upgrade, the configuration fails to load with an error such as: 01070726:3: monitor /Common/sip-monitor in partition /Common cannot reference SSL profile monitor parameter /Common/sip-monitor 1 SSL_PROFILE_NAME= in partition name-of-other-partition. Alternatively, the configuration loads after upgrade, but the config file is corrupted, and will fail to load (such as after a system restart, or upon explicit 'tmsh load sys config'), with an error such as: Syntax Error:(/config/bigip.conf at line: 63) ""user-defined"" unknown property" "A configuration that contains custom 'SIP' or 'FirePass' monitors that is upgraded from a version earlier than v13.1.0 may either fail to load, or may result in a configuration that loads the first time after the upgrade, but cannot be re-loaded from the text config files. If the BIG-IP system has partitions other than 'Common', the initial configuration load may fail with an error such as: 01070726:3: monitor /Common/sip-monitor in partition Common cannot reference SSL profile monitor parameter /Common/sip-monitor 1 SSL_PROFILE_NAME= in partition name-of-other-partition If the BIG-IP system only has a 'Common' partition, the initial configuration load will succeed, but subsequent attempts to load the configuration (e.g., 'tmsh load sys config') may fail with this error: Syntax Error:(/config/bigip.conf at line: 63) ""user-defined"" unknown property Which corresponds to a SIP or FirePass monitor in the configuration such as: ltm monitor sip /Common/test_sip_monitor { cipherlist DEFAULT:+SHA:+3DES:+kEDH compatibility enabled debug no defaults-from /Common/sip destination *:* filter 488 interval 5 mode tcp time-until-up 0 timeout 16 user-defined SSL_PROFILE_NAME /Common/test_sip_monitor_ssl_profile }" Workaround: Remove custom 'SIP' and 'FirePass' monitors from the configuration, and re-create them manually after upgrade is complete. Fix: In this release, a configuration that contains a custom 'SIP' or 'FirePass ' monitor from a version earlier than v13.1.0 now loads correctly and continues to load as expected. |
701898 | Certain virtual address route-advertisement settings break upgrades from 13.0.0 hotfix rollups - Upgrading from a version of 13.0.0 other than the base (i.e. HF1 or later). - Upgrading to 13.1.0 or later. - At least one virtual address with its route-advertisement value set to 'selective', 'any', or 'all'. Configuration will not load. If the unit being upgraded is a stand-alone unit, this will result in a traffic outage. "Upgrading from a version of 13.0.0 other than the base build may result in failure depending on the values of the virtual address route-advertisement setting. If set to 'selective', 'any', or 'all', the configuration will fail to load after the upgrade with an error similar to the following example in the /var/log/ltm file: If you become aware of this issue prior to upgrading:
Note that if your chosen destination (i.e. HD1.3) already exists and contains the very software you want to install (e.g., 13.1.1.2), then you must first delete the destination before you can re-use it. This is because, by design, the BIG-IP system will not perform an installation if the desired software is already present in the destination boot location. Attempting such an installation would just result in the BIG-IP system immediately rebooting to activate that boot location, without performing any installation and thus defeating the point of this workaround. If you become aware of this issue after the upgrade has already failed:
Fix: Upgrades from 13.0.0 hotfix rollups involving certain virtual address route-advertisement settings no longer fail. |
702792 | Upgrade creates Server SSL profiles with invalid cipher strings "Custom HTTPS monitors configured prior to an upgrade result in these profiles being created during the upgrade. The default HTTPS cipherlist is 'DEFAULT:+SHA:+3DES:+kEDH', which is a valid OpenSSL cipher list, but is not a valid Client SSL / Server SSL cipher list." Upgrade creates configurations that are challenging to manage as a result of MCPD validation. "Upgrade of BIG-IP creates Server SSL profiles for custom HTTPS monitors that may have an invalid Ciphers attribute. This does not prevent the configuration from loading, but attempting to modify the existing SSL profile or create a new one with matching configuration fails with the following message For instance, use ""DEFAULT:+SHA:+3DES:+EDH"" instead of ""DEFAULT:+SHA:+3DES:+kEDH""." Fix: Upgrade no longer creates Server SSL profiles with invalid cipher strings. |
703045 | If using TMSH commands with deprecated attributes in iApp, the upgrade will fail. TMSH commands with deprecated attributes will fail if used in iApp. This is so whether the iApp is activated during the upgrade process or simply run under iApp service at the user display. TMSH commands will not execute like create command will result in no objects (e.g., monitor, virtual server, etc.) being created. TMSH commands with deprecated attributes will fail if used in iApp. Workaround: Try to avoid deprecated attributes of the object in the iApp. Fix: "All TMSH commands should handle deprecated attributes of objects consistently across TMSH command line, CLI Script and iApp and like so:
|
704540 | Monitor configuration with invalid 'key' and 'cert' not detected upon upgrade post v13.1.x "-- A pre-v13.1.0 configuration containing monitors with invalid 'key' or 'cert' attributes (i.e., 'https', 'SIP', 'Firepass' monitors). -- In some cases the 'key' and 'cert' may be valid and match, with the 'key' in the encrypted form. -- Upgrading that configuration to v13.1.0 or later." After upgrade, the configuration does not load. "A monitor configuration with invalid SSL-attributes for 'key' or 'cert' is not detected as invalid, and upon upgrade to on-or-after v13.1.0 may result in an invalid configuration; or may result in a config that loads with the pool 'up', but the monitor 'key' and 'cert' attributes must be added manually. The invalid configuration includes: 'key' and 'cert' attributes do not match, or are not supported. This affects the following monitors, which contain SSL attributes: 'https', 'SIP', 'Firepass'. In some cases this issue may present with valid and matching 'key' and 'cert', with the 'key' in the encrypted form." Workaround: "You can use the following workarounds:
|
705730 | Config fails to load due to invalid SSL cipher after upgrade from v13.1.0 "-- Config uses 'https' monitors. -- Upgrade occurs from v13.1.0 to a later version." The configuration fails to load, an error message is issued, and the device remains offline until a manual config load is performed. "Config with apparently invalid SSL cipher entry fails to load after upgrade from v13.1.0, and requires a manual config load after upgrade: 'tmsh load sys config' This occurs because starting in v13.1.0, 'https' monitors rely upon SSL-attributes configured through a 'serverssl' profile, which does not support the 'kEDH' cipher; but the 'kEDH' cipher was a default cipher for previous releases (where 'https' relied upon 'OpenSSL')." Workaround: "You can use either of the following workarounds: (This works because upon a manual config load command ('tmsh load sys config'), the system replaces the existing 'https' ciphers with defaults appropriate for a 'serverssl' profile in the new version of the software. Even though the system posts an error referencing the invalid 'kEDH' cipher, the device will become 'Active' seconds later, and new default ciphers will be established for 'https' monitors.) |
721261 | v12.x Policy rule names containing slashes are not migrated properly
|
721571 | State Mirroring between BIG-IP 12.1.3.* and 13.* or 14.* systems may cause TMM core on standby system during upgrade
1. You can disable mirroring using either the GUI or the command line. Important: This action results in connection state loss on failover. 2. Once all devices are running the same software version, re-enable state mirroring by re-adding the device mirror IP addresses removed previously. |
743970 | Ensure 8 GB RAM vCMP guests have no more than three modules provisioned before upgrading
|
Upgrading from earlier versions
Upgrading from version 12.x or later
When you upgrade from version 12.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.Upgrading from versions earlier than 12.x
You cannot roll forward a configuration directly to this version from BIG-IP version
11.x or earlier. You must be running version 12.x
(or later) software. For details about upgrading from earlier versions, see the release
notes for the associated release.
Automatic firmware upgrades
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.
Issues when upgrading from earlier Advanced WAF versions
If you upgrade from an earlier version of Advanced WAF, note the following issues.
Exporting Logs
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.
Advanced WAF cookie security
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 nameTS*.
- 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
Cookie signature validation
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
Running Advanced WAF on a vCMP system
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.About changing the resource provisioning level of the Advanced WAF
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.
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
.Prevent traffic from bypassing the Advanced WAF
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.
About working with device groups
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 thedatasync-global-dgdevice-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 thedatasync-global-dgdevice-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.
- Thedatasync-global-dgdevice 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.
