Applies To:
Show VersionsBIG-IP AAM
- 11.5.8
BIG-IP APM
- 11.5.8
BIG-IP GTM
- 11.5.8
BIG-IP Link Controller
- 11.5.8
BIG-IP Analytics
- 11.5.8
BIG-IP LTM
- 11.5.8
BIG-IP AFM
- 11.5.8
BIG-IP PEM
- 11.5.8
BIG-IP ASM
- 11.5.8
Summary:
These release notes document the BIG-IP version 11.5.8 release. You can apply the software upgrade to systems running software versions 10.1.0 (or later).
BIG-IP Virtual Edition (VE) is a version of the BIG-IP system that runs as a virtual machine. Supported modules include Local Traffic Manager, Global Traffic Manager, Application Security Manager, Access Policy Manager, Application Acceleration Manager, Policy Enforcement Manager, Application Firewall Manager, and Analytics. BIG-IP VE includes all features of device-based BIG-IP modules running on standard BIG-IP TMOS, except as noted in release notes and product documentation.
Contents:
- Platform support
- Module combination and memory considerations
- User documentation for this release
- Configuration utility browser support
- Compatibility of BIG-IQ products with BIG-IP releases
- Fixes, behavior changes, and known issues
- New in 11.5.8
- Installation overview
- Installation checklist
- Installing the software
- Post-installation tasks
- Installation tips
- Upgrading from earlier versions
- Upgrading earlier configurations
- Issues when upgrading from earlier ASM versions
- About changing the resource provisioning level of the Application Security Manager
- To prevent traffic from bypassing the Application Security Manager
- About working with device groups
- Synchronizing the device group
- Supported ICAP servers
- Contacting F5
- Legal notices
Platform support
- K9412: The BIG-IP release matrix: A software-hardware support matrix organized by BIG-IP release version.
- K9476: The F5 hardware/software compatibility matrix: A platform-sorted matrix BIG-IP hardware/software support.
- K4309: F5 platform lifecycle support policy: A definition of platform lifecycle stages from initial release through retirement.
Module combination and memory considerations
BIG-IP platform considerations
These platforms support various licensable combinations of product modules. This section provides general guidelines for module support.
Most of the support guidelines relate to memory. The following list applies for all memory levels:
- vCMP supported platforms
- VIPRION B2100, B2150, B2250
- VIPRION B4300 blade in the C4480(J102) and C4800(S100)
- VIPRION B4450 blade in the C4480(J102) and C4800(S100)
- BIG-IP 5200v, 5250v, 7200v, 7250v, 10200v, 10250v, 10350v, 12250v
- BIG-IP i5800, i7800, i10800, i11800, i15800
- PEM and CGNAT supported platforms
- VIPRION B2100, B2150, B2250, B4300, B4340N, B4450N
- BIG-IP 5x00v(s), 7x00v(s), 10x00v(s)
- PEM for BIG-IP iSeries: i5800, i7800, i10800, i11800, i15800
- CGNAT for BIG-IP iSeries: i2x00, i4x00, i5x00,i7x00,i10x00,i11x00,i15x00
- BIG-IP Virtual Edition (VE) (Not including Amazon Web Service Virtual Edition) (3 GB, 10 GB production and combination lab models)
- PEM may be provisioned on the VIPRION B2100, but it is not recommended for production, only for evaluation. Use the B4300/B4340N or another blade instead.
- PEM is not supported on vCMP guests.
- PEM is not supported on 8 GB platforms.
- BIG-IP 800 and i850 platform support
- The BIG-IP 800 and i850 platforms support Local Traffic Manager (LTM) only, and no other modules.
Memory: 12 GB or more
All licensable module-combinations may be run on platforms with 12 GB or more of memory, and on VE and vCMP guests provisioned with 12 GB or more of memory. Note that this does not mean that all modules may be simultaneously provisioned on all platforms with 12 GB or more of memory. The BIG-IP license for the platform determines which combination of modules are available for provisioning.
Memory: 8 GB
The following guidelines apply to the BIG-IP 2000s, 2200s, 6900 platforms and to VE guests configured with 8 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus does not fit in this category.)
- No more than three modules should be provisioned together.
- On the 2000s and 2200s, Application Acceleration Manager (AAM) can be provisioned with only one other module.
- To use Access Policy Manager (APM) and Secure Web Gateway (SWG) modules together on platforms with exactly 8 GB of memory, Local Traffic Manager (LTM) provisioning must be set to None.
Memory: Less than 8 GB and more than 4 GB
The following guidelines apply to platforms, and to VE and vCMP guests provisioned with less than 8 GB and more than 4 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus fits in this category.)
- No more than three modules (not including AAM) should be provisioned together.
- Application Acceleration Manager (AAM) cannot be provisioned with any other module; AAM can only be provisioned standalone.
- Analytics (AVR) counts towards the two module-combination limit (for platforms with less than 6.25 GB of memory).
Memory: 4 GB or less (VE and vCMP only)
The following guidelines apply to VE and vCMP guests provisioned with 4 GB or less of memory.
- No more than two modules may be configured together.
- AAM should not be provisioned, except as Dedicated.
- ASM should not be provisioned, except as Dedicated
VIPRION and vCMP caching and deduplication requirements
Application Acceleration Manager (AAM) supports the following functionality when configuring vCMP and VIPRION platforms.
- AAM does not support disk-based caching functionality on vCMP platforms. AAM requires memory-based caching when configuring it to run on vCMP platforms.
- AAM supports disk-based caching functionality on VIPRION chassis or blades.
- AAM does not support deduplication functionality on vCMP platforms, or VIPRION chassis or blades.
vCMP memory provisioning calculations
The amount of memory provisioned to a vCMP guest is calculated using the following formula: (platform_memory- 3 GB) x (cpus_assigned_to_guest / total_cpus).
As an example, for the B2100 with two guests, provisioned memory calculates as: (16-3) x (2/4) ~= 6.5 GB.
- BIG-IP LTM standalone only
- BIG-IP GTM standalone only
- BIG-IP LTM and GTM combination only
VE considerations
This version of the software is supported in the following configurations. For a list of VE hypervisor support, see the Virtual Edition and Supported Hypervisors Matrix.
Memory: 12 GB or more
All licensable module-combinations may be run on BIG-IP Virtual Edition (VE) guests provisioned with 12 GB or more of memory.
Memory: 8 GB
The following guidelines apply to VE guests configured with 8 GB of memory.
- No more than three modules should be provisioned together.
Memory: Less than 8 GB and more than 4 GB
The following guidelines apply to VE guests provisioned with less than 8 GB and more than 4 GB of memory.
- No more than three modules (not including AAM) should be provisioned together.
- Application Acceleration Manager (AAM) cannot be provisioned with any other module; AAM can only be provisioned standalone.
Memory: 4 GB or less
The following guidelines apply to VE guests provisioned with 4 GB or less of memory.
- No more than two modules may be configured together.
- AAM should not be provisioned, except as Dedicated.
- ASM should not be provisioned, except as Dedicated
User documentation for this release
For a list of Virtual Edition (VE) hypervisor support, see the Virtual Edition and Supported Hypervisors Matrix.
Configuration utility browser support
The BIG-IP Configuration Utility supports these browsers and versions:
- Microsoft Internet Explorer 11.x, or later
- Mozilla Firefox v62.0, or later
- Google Chrome v69.0.3497, or later
Compatibility of BIG-IQ products with BIG-IP releases
K34133507: BIG-IQ Centralized Management compatibility matrix provides a summary of version compatibility between the BIG-IQ Centralized Management and BIG-IP releases.
Fixes, behavior changes, and known issues
New in 11.5.8
This release is provided to address the DNS Flag Day changes occurring on February 1st, 2019, at which time major public DNS providers are going to remove certain workarounds. There are no additional new features.
Installation overview
This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference this information to ensure successful completion of the installation process.
Installation checklist
Before you begin:
- Use BIG-IP iHealth to verify your configuration file. For more information, see K12878: Generating diagnostic data using the qkview utility.
- Update/reactivate your system or vCMP host license, if needed, to ensure that you have a valid service check date. For more information, see K7727: License activation may be required before a software upgrade for the BIG-IP or Enterprise Manager system.
- Ensure that your system is running version 12.x or later.
- Download the .iso file from F5 Downloads to /shared/images on the source for the operation. (If you need to create this directory, use the exact name /shared/images.)
- Configure a management port.
- Set the console and system baud rate to 19200, if it is not already.
- Log on as an administrator using the management port of the system you want to upgrade.
- Check all DNSSEC Key generation's 'expiration' and 'rollover' date:time fields before performing a GTM sync group upgrade. If any of the DNSSEC Key generations are set to rollover or expire during the planned upgrade window, modify the date:time of the 'expiration' and/or 'rollover' fields to extend past the anticipated upgrade window, to a date:time when all units in the sync group will again have GTM config sync enabled.
- Boot into an installation location other than the target for the installation.
- Save the user configuration set (UCS) in the /var/local/ucs directory on the source installation location, and copy the UCS file to a safe place on another device.
- Log on to the standby unit, and only upgrade the active unit after the standby upgrade is satisfactory.
- Turn off mirroring.
- If you are running Policy Enforcement Manager, set provisioning to Nominal.
- If you are running Advanced Firewall Manager, set provisioning to Nominal.
Installing the software
Installation method | Command |
---|---|
Install to existing volume, migrate source configuration to destination | tmsh install sys software image [image name] volume [volume name] |
Install from the browser-based Configuration utility | Use the Software Management screens in a web browser. |
Sample installation command
The following command installs version 13.0.0 to volume 3 of the main hard drive.
tmsh install sys software image BIGIP-13.0.0.0.0.1645.iso volume HD1.3
Post-installation tasks
This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference this information to ensure successful completion of the installation process.
- Ensure the system rebooted to the new installation location.
- Use BIG-IP iHealth to verify your configuration file. For more information, see K12878: Generating diagnostic data using the qkview utility.
- Log on to the browser-based Configuration utility.
- Run the Setup utility.
- Provision the modules.
Installation tips
- The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three minutes and seven minutes. During the upgrade process, you see messages posted on the screen. For example, you might see a prompt asking whether to upgrade the End User Diagnostics (EUD), depending on the version you have installed. To upgrade the EUD, type yes, otherwise, type no.
- You can check the status of an active installation operation by running the command watch tmsh show sys software, which runs the show sys software command every two seconds. Pressing Ctrl + C stops the watch feature.
- If installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.
Upgrading from earlier versions
Your upgrade process differs depending on the version of software you are currently running.
Upgrading from version 11.x or later
When you upgrade from version 11.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 11.x
You cannot roll forward a configuration directly to this version from BIG-IP version 10.x or earlier. You must be running version 11.x (or later) software. For details about upgrading from earlier versions, see the release notes for the associated release.
Upgrading to 4th element versions from versions earlier than 11.5.0
You cannot directly update from pre-11.5.0 versions (e.g., v11.4.x, v11.2.x, etc.) to any 4th element version (e.g., v12.1.3.1, v13.1.0.1, etc.). Direct upgrade to 4th element versions is supported only from v11.5.0 and later. For pre-11.5.0 versions, you must first upgrade to v11.5.0 or later. The recommended upgrade path is from v11.4.1 to v12.1.3, and then to v12.1.3.1. For details about upgrading to those 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.
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: -- i2800 2%-3% Full Proxy traffic. -- i4800 2%-3% Full Proxy traffic. -- i5800 3%-8% Fast HTTP/Full Proxy traffic. -- i7800 3%-7% Fast HTTP/Full Proxy traffic. -- i10800 3%-7% Fast HTTP/Full Proxy traffic. -- i11800 2%-3% Fast HTTP traffic. -- B2250 3%-6% OneConnect/Full Proxy traffic. -- B4450 4%-10% Fast HTTP/OneConnect/Full Proxy traffic.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: load_config_files: ""/usr/bin/tmsh -n -g load sys config partitions all "" - failed. -- Loading schema version: 13.0.0 Syntax Error:(/config/bigip.conf at line: 1790) invalid property value ""route-advertisement"":""selective"""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 : 01070312:3: Invalid keyword 'kedh' in ciphers list for profile /Common/name-of-server-ssl-profile" Workaround: "Reconfigure the cipher list to be valid according to both the OpenSSL cipher list and the Client SSL / Server SSL cipher list expectations.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: -- After upgrade from v13.1.0, perform manual config load by running the following command: tmsh load sys config(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.) -- Remove 'https' monitors prior to upgrade, and add again after upgrade." Fix: Config loads without error after upgrade from v13.1.0. |
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. 1a. In the GUI: -- Set the Primary and Secondary Local Mirror Address configurations to 'None' under Device Management :: Devices :: [Self] device :: Mirroring Configuration. 1b. From the command-line: -- Run the following command: tmsh modify cm device <name-of-self-device> mirror-ip any6 mirror-secondary-ip any6 && tmsh save sys configImportant: 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. Note: F5 recommends that BIG-IP systems in HA configurations run with the same software version on all devices." |
743970 | Ensure 8 GB RAM vCMP guests have no more than three modules provisioned before upgrading
|
Issues when upgrading from earlier ASM versions
If you upgrade from an earlier version of ASM, note the following issues.
Upgrade warnings and notes
The Application Security Manager supports .ucs files from versions 10.1.0 and later of the Application Security Manager. Additionally, you may import policies exported from versions 10.1.0 and later of the Application Security Manager.
Warning: With the introduction of the Local Traffic Policies feature in BIG-IP version 11.4.0, HTTP Class iRule events and commands are no longer available. If you plan to upgrade to 11.4.0 or later, and your configuration contains an iRule that uses an HTTP class iRule event or command, please read K14409: The HTTP Class profile is no longer available in BIG-IP 11.4.0 and later.
Warning: Local Traffic Policies do not support regular expressions for matching. While the upgrade process is able to migrate simple glob expressions, manual administrator intervention is required in order to ensure that the policies are properly configured. If you plan to upgrade to 11.4.0 or later, and your configuration contains regular expressions or glob expressions, please read K14409: The HTTP Class profile is no longer available in BIG-IP 11.4.0 and later.
Important: The system creates its internal cookie in versions 10.2.4 and later (including all versions of 11.x) differently than in versions prior to 10.2.4. As a result, while upgrading your system from a version prior to 10.2.4 to version 10.2.4 or later, the system will produce the Modified ASM Cookie violation for existing browser sessions. If the security policy has the Modified ASM Cookie violation enabled and set to block traffic when this violation occurs, after upgrading to version 10.2.4 or later, the system will block traffic to the web application. However, since the TS cookie is a session cookie, the system will block traffic only until the browser session ends (the end-user restarts the browser). To prevent the security policy from blocking traffic until the end-user’s browser is restarted, before upgrading to version 10.2.4 or later, we recommend you disable the security policy from blocking the Modified ASM Cookie violation, upgrade, and wait long enough to allow all users to restart their browsers (two weeks are expected to be enough). After enabling the violation, we recommend you monitor the logs. If the Modified ASM Cookie violation appears, consider disabling the violation again for a longer period of time, or communicate to the users to restart their browsers.
HTTP protocol compliance failed sub-violations
If you upgrade or import a security policy from a version prior to 11.6.0, the system automatically enables the following HTTP protocol compliance-failed sub-violations, even if they were previously disabled:
- Bad HTTP version
- Null in request
- Unparsable request content
You can manually disable these violations after the upgrade or import.
Layer 7
In version 11.4.0, local traffic policies replace HTTP Classes. When you create an ASM security policy, the system automatically creates a default Layer 7 local traffic policy. Note the following changes that occur to your system after upgrading from a version prior to 11.4.0:
- A Layer 7 local traffic policy is created and the HTTP class is removed. If the HTTP Class name is different than the name of the security policy, upon upgrade, the system changes the name of the security policy to the name of the HTTP Class.
- Security policies are now in folders (partitioned) like pools and virtual servers. Upon upgrade, the system places security policies in the folder to which the HTTP Class belonged. The system places security policies that were inactive in the /Common folder.
- iRules that use HTTP Class do not work here. Users must manually change the HTTP Class part of the iRule to Policy after the upgrade.
ASM cookie security
As a result of changes made to the signing of ASM 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 ASM 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
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
Web scraping
There was a check box for enabling web scraping that was removed in version 11.3.0.
- When you upgrade from versions 11.0.0 through 11.2.x, if the check box is enabled, the new Bot Detection setting has the option Alarm and Block enabled. If the check box is not enabled, the value is Off.
- When you upgrade from versions prior to 11.0.0 (where there was no enable flag), the Bot Detection setting is based on the blocking check boxes for web scraping:
- If the global Block check box is enabled, the value is Alarm and Block.
- If the global Block check box is disabled, and the global Alarm check box is enabled, the value is Alarm.
- If both Alarm and Block check boxes are disabled, the value is Off.
Brute Force
In versions prior to 11.3.0, if the Dynamic Brute Force Protection Operation Mode was Blocking, and the security policy’s Enforcement Mode was Transparent, the system blocked brute force attacks. In order to keep functionality after upgrading, the system continues to block brute force attacks if you upgrade to versions 11.3.0 or later, under these circumstances. However, in versions 11.3.0 and later, the functionality changed so that if the security policy’s Enforcement Mode is Transparent, so the system does not block brute force attacks even if the Dynamic Brute Force Protection Operation Mode setting is Alarm and Block (previously Blocking).
DoS profiles
In versions 11.3.0 and later, DoS profiles are assigned to virtual servers. Previously, they were assigned to security policies.
- Upon upgrading DoS Profiles from versions prior to 11.3.0, all active security policies have their DoS settings migrated and assigned to the virtual server associated with the HTTP Class. If a virtual server had more than one HTTP Class assigned to it, it inherits the settings of the last in the list.
- If you have a disabled DoS profile in a version prior to 11.3.0, and upgrade, after the upgrade the system automatically assigns the DoS profile to a virtual server. As a result, even though the system does not perform DoS protection, it still collects statistics, which impacts the system’s performance. To work around this issue, if you have a disabled DoS profile assigned to a virtual server, to improve system performance you should remove its association from the virtual server. (ID 405211)
- We do not support exporting and importing DoS profiles.
Logging Profiles
In versions 11.3.0 and later, logging profiles are assigned to virtual servers. Previously, they were assigned to security policies. Upon upgrading logging profiles from versions prior to 11.3.0, all active security policies have their logging profile settings migrated and assigned to the virtual server associated with the HTTP Class. If a virtual server had more than one HTTP Class assigned to it, it inherits the settings of the last in the list.
XFF configuration (ID 405312)
In versions prior to 11.3.0, DoS profiles used the Trust XFF setting that was a security policy setting. The Trust XFF setting was renamed Accept XFF, and moved from a security policy property to a property of the HTTP profile. If you upgrade a DoS profile and a security policy with the Trust XFF setting enabled, after the upgrade, the new XFF configuration setting is disabled. If you want the DoS profile to continue trusting XFF, navigate to screen, and enable the Accept XFF setting.
IP address whitelist
In version 11.2 we unified various whitelists for Policy Builder trusted IP addresses, and anomaly whitelists (DoS Attack Prevention, Brute Force Attack Prevention, and Web Scraping Detection) into a single list. When you upgrade, these separate lists are unified to a single whitelist (called the IP Address Exceptions List).
Security policy status after UCS installation
After you install a .ucs (user configuration set) file that was exported from version 10.1.0 or later, the system does not automatically apply changes that you made, but did not apply, to the security policies. The system enforces the web application according to the settings of the last set active security policy. However, the system preserves any changes to the current edited security policy, and marks the security policy as modified [M] if the changes have not been applied.
Running Application Security Manager on a vCMP system
If you are running Application Security Manager on a vCMP system: For best performance, F5 recommends configuring remote logging to store ASM logs remotely on Syslog servers rather than locally.
About changing the resource provisioning level of the Application Security Manager
After upgrading or installing a new version, before you can use the Application Security Manager, you must set the Application Security Manager resource provisioning level to Nominal. You can do this from the command line, or using the Configuration utility.
Setting the Application Security Manager resource provisioning level to Nominal from the command line
- Open the command-line interface utility.
- Type the command: tmsh modify sys provision asm level nominal
- Type the command: tmsh save sys config.
Setting the Application Security Manager resource provisioning level to Nominal using the Configuration utility
To prevent traffic from bypassing the Application Security Manager
Please read Solution 8018 (SOL8018) and Solution 12268 (SOL12268) on the AskF5 web site. These solutions contain important configuration information needed to prevent traffic from bypassing the Application Security Manager.
About working with device groups
When Application Security Manager (ASM) 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 ASM on a device that has version 11.6.0, or later, installed.
- Adding a device (with version 11.6.0 or later) to a trust-domain that has another device which already has the datasync-global-dg device-group.
- Upgrading to version 11.6.0, or later, when ASM is already provisioned.
- Upgrading to version 11.6.0, or later, 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 ASM provisioned, but are in a trust-domain with other units which do have ASM provisioned.
Synchronizing the device group
Supported ICAP servers
For BIG-IP version 11.6.0, F5 Networks tested the anti-virus feature on the following ICAP servers: McAfee®, Trend Micro™, Symantec™, and Kaspersky. The following table displays which version of each anti-virus vendor was tested, and the value of the virus_header_name variable that needs to be adjusted in ASM for each tool. (You can set the virus_header_name variable: .)
Anti-Virus Vendor | Anti-Virus Version | Value of virus_header_name |
---|---|---|
McAfee® VirusScan Enterprise | 7.0 | X-Infection-Found, X-Virus-Name |
Trend Micro™ InterScan™ Web Security | 5.0.1013 | X-Virus-ID |
Symantec™ Protection Engine | 7.0.2.4 | X-Violations-Found |
Kaspersky Anti-Virus | 5.5 | X-Virus-ID |
Contacting F5
North America | 1-888-882-7535 or (206) 272-6500 |
Outside North America, Universal Toll-Free | +800 11 ASK 4 F5 or (800 11275 435) |
Additional phone numbers | Regional Offices |
Web | http://www.f5.com |
support@f5.com |
Additional resources
You can find additional support resources and technical documentation through a variety of sources.
F5 Support | Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology. |
AskF5 Knowledge Base | The storehouse for thousands of knowledgebase articles that help you manage your F5 products more effectively. Whether you want to browse periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source. |
BIG-IP iHealth Diagnostics and BIG-IP iHealth Viewer | BIG-IP iHealth Diagnostics identifies issues, including common configuration problems and known software issues. It also provides solutions and links to more information. With BIG-IP iHealth Viewer, you can see the status of your system at-a-glance, drill down for details, and view your network configuration. |
F5 DevCentral | Collaborate and share innovations including code samples, new techniques, and other tips, with more than 300,000 F5 users worldwide. DevCentral is the place to ask questions, find solutions, learn to harness the power of F5’s powerful scripting language, iRules, and much more. |
Communications Preference Center | Here, you can subscribe to a number of communications from F5. For information about the types of notifications F5 provides, see K9970: Subscribing to email notifications regarding F5 products. |