Release Notes : BIG-IP Analytics 12.1.0

Applies To:

Show Versions Show Versions

BIG-IP Analytics

  • 12.1.0
Release Notes
Original Publication Date: 04/20/2017 Updated Date: 04/18/2019


This release note documents the version 12.1.0 release of BIG-IP Analytics (AVR). You can apply the software upgrade to systems running software versions 10.1.0 (or later), or 11.x/12.x.


These release notes document the version 12.1.0 release of BIG-IP Analytics (AVR). You can apply the software upgrade to systems running software versions 11.x.

Platform support

This version of the software is supported on the following platforms:

Platform name Platform ID
BIG-IP 1600 C102
BIG-IP 3600 C103
BIG-IP 3900 C106
BIG-IP 6900 D104
BIG-IP 8900 D106
BIG-IP 8950 D107
BIG-IP 11000 E101
BIG-IP 11050 E102
BIG-IP 2000s, BIG-IP 2200s C112
BIG-IP 4000s, BIG-IP 4200v C113
BIG-IP 5000s, 5050s, 5200v, 5250v C109
BIG-IP 7000s, 7050s, 7055, 7200v, 7250v, 7255 D110
BIG-IP 12250v D111
BIG-IP 10150s-NEBS, 10350v (AC), 10350v-NEBS (requires 12.0.0 HF1), 10350v-FIPS (requires 11.5.4 HF1) D112
BIG-IP 10000s, 10050s, 10055, 10200v, 10250v, 10255 D113
VIPRION B2100 Blade A109
VIPRION B2150 Blade A113
VIPRION B2250 Blade A112
VIPRION B4200, B4200N Blade A107, A111
VIPRION B4450 Blade A114
VIPRION B4300, B4340N Blade A108, A110
VIPRION C2200 Chassis D114
VIPRION C2400 Chassis F100
VIPRION C4400, C4400N Chassis J100, J101
VIPRION C4480, C4480N Chassis J102, J103
VIPRION C4800, C4800N Chassis S100, S101
Virtual Edition (VE) Z100
vCMP Guest Z101

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, B4200
    • VIPRION B4300 blades in the 4400(J100)/4480(J102) and the 4800(S100)
    • BIG-IP 5200v, 5250v, 7200v, 7250v, 10200v, 10250v, 10350v, 12250v

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, 3900, 6900 platforms, to the VIPRION B4100 and B4100N 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.
  • In the case of Access Policy Manager (APM) and SWG together, no module other than LTM may be provisioned, and 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

The following guidelines apply to the BIG-IP 1600 and 3600 platforms, and 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 can be provisioned with this amount of memory, but a sizing exercise should be performed to ensure that it does not hit capacity issues.

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.

For certain platforms, the vCMP host can allocate a single core to a vCMP guest. However, because a single-core guest has relatively small amounts of CPU resources and allocated memory, F5 supports only the following products or product combinations for a single-core guest:
  • BIG-IP LTM standalone only
  • BIG-IP GTM standalone only
  • BIG-IP LTM and GTM combination only

Configuration utility browser support

The BIG-IP Configuration Utility supports these browsers and versions:

  • Microsoft Internet Explorer 11.x
  • Mozilla Firefox 27.x
  • Google Chrome 32.x

BIG-IQ – BIG-IP compatibility

SOL14592: Compatibility between BIG-IQ and BIG-IP releases provides a summary of version compatibility for specific features between the BIG-IQ system and BIG-IP releases.

User documentation for this release

For a comprehensive list of documentation that is relevant to this release, refer to the BIG-IP Analytics / VE 12.1.0 Documentation page.

New features introduced in 12.1.0

This release includes the following new items.

Reporting TCP Statistics

After you create a TCP Analytics Profile, the system can display the following TCP statistics: RTT, Goodput, Delay State, Connections and Packets.

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 the 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 SOL12878: Generating BIG-IP 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 SOL7727 - License activation may be required prior to a software upgrade for the BIG-IP or Enterprise Manager system.
  • Ensure that your system is running version 10.1.0 or later and is using the volumes formatting scheme.
  • Download the .iso file (if needed) 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.
  • 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 Application Acceleration Manager, set provisioning to Minimum.
  • 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

You can install the software at the command line using the Traffic Management shell, tmsh, or in the browser-based Configuration utility using the Software Management screens, available in the System menu. Choose the installation method that best suits your environment.
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 11.2.0 to volume 3 of the main hard drive.

tmsh install sys software image BIGIP- 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 the information to ensure successful completion of the installation process.

After the installation finishes, you must complete the following steps before the system can pass traffic.
  1. Ensure the system rebooted to the new installation location.
  2. Use BIG-IP iHealth to verify your configuration file. For more information, see SOL12878: Generating BIG-IP diagnostic data using the qkview utility.
  3. Log on to the browser-based Configuration utility.
  4. Run the Setup utility.
  5. Provision the modules.
  6. Convert any bigpipe scripts to tmsh. (Version 11.x does not support the bigpipe utility.)
Note: You can find information about running the Setup utility and provisioning the modules in the BIG-IP TMOS implementations Creating an Active-Standby Configuration Using the Setup Utility and Creating an Active-Active Configuration Using the Setup Utility.

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.

Warning: Do not use the 10.x installation methods (the Software Management screens, the b software or tmsh sys software commands, or the image2disk utility) to install/downgrade to 9.x software or operate on partitions. Depending on the operations you perform, doing so might render the system unusable. If you need to downgrade from version 10.x to version 9.x, use the image2disk utility to format the system for partitions, and then use a version 9.x installation method described in the version 9.x release notes to install the version 9.x software.

Upgrading from version 10.1.0 (or later) or 11.x

When you upgrade from version 10.1.0 (or later) or 11.x software, 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 10.1.0 11.x

You cannot roll forward a configuration directly to this version from BIG-IP version 4.x, or from BIG-IP versions 9.0.x through 9.6.x. You must be running version 10.1.0 software. 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
223704 When you import a single configuration file (SCF file) that contain VLANs of the same name that exist in different administrative partitions, the operation fails with a unknown operation error. Upgrading configurations with VLANs of the same name in different administrative partitions. Upgrade operation fails with a unknown operation error. Workaround: Before installing an SCF file, run the command: tmsh load sys config default. This returns the system to the default configuration, so subsequent configuration import operations should succeed as expected.
366172 A pre-v11.x configuration that was created with the bigpipe cli ip addr option set to name may cause configuration load failure on upgrade due to resolved names saved to the bigp.conf file rather than IP addresses. pre-v11.x configuration that was created with the bigpipe cli ip addr option set to name. Configuration load failure. Workaround: The workaround is to change the cli setting to 'cli ip addr number', save the config on the pre-v11.x unit, and then run the upgrade.
401828 The following configurations are invalid for a SIP virtual server: a) TCP virtual server with a UDP profile and a SIP profile. b) UDP virtual server with a TCP profile and a SIP profile. TCP virtual server with a UDP profile and a SIP profile, or a UDP virtual server with a TCP profile and a SIP profile. If such a configuration exists in previous versions, it loads in 11.3.x but may cause a core. Workaround: "Fix the configuration manually, as follows: a) A SIP TCP virtual server must have TCP as one of its profile type. b) A SIP UDP virtual server must have UDP as one of its profile type."
415961 The upgrade process does not migrate unassigned HTTP Class profiles to BIG-IP 11.4.0 and later When you upgrade a BIG-IP system to BIG-IP 11.4.0 or later, the upgrade process attempts to convert all assigned HTTP Class profiles to their equivalent local traffic policies. If an HTTP Class profile is not assigned to a virtual server, the upgrade process will not perform the conversion and the unassigned HTTP Class profile will no longer exist in the configuration of the upgraded BIG-IP system. Similarly, if you restore a UCS archive that contains unassigned HTTP Class profiles in BIG-IP 11.4.0 and later, the restoration process will not convert the unassigned HTTP Class profiles and these profiles will no longer exist. This behavior is by design. You might lose unused HTTP Class profiles in the configuration. Workaround: "When upgrading to BIG-IP 11.4.0 and later or saving a UCS archive from a pre-11.4.0 system, you should consider the following factor: Prior to upgrading or saving a UCS archive, ensure that all HTTP Class profiles are assigned to a virtual server."
434364 "When upgrading from 10.x or installing a 10.x originated UCS on 11.x, bigpipe is used to parse the newly created file-object definitions which had been generated from files in the 10.x install. If the filename being upgraded to file-object starts with a '.', then on initial load, bigpipe will give an error while trying to load the generated configuration, resulting in an error message similar to: BIGpipe parsing error (/config/bigpipe/bigip.conf Line 107): 012e0017:3: The requested item (.myfile.txt {) is invalid (external_monitor_file_object_key | show | list | help) for 'external monitor file object'" The installation of a UCS or configuration roll-forward from 10.x to 11.x in which the previous install had files that were upgraded to file-objects, but whose filename started with a '.' The UCS will not install properly, and/or the configuration on initial boot will not load. Workaround: Edit the name of the file-object in question which would be found in /config/bigpipe/bigip.conf to remove the leading '.' character from the object name, and make any references to the file-object match that change.
435332 If there are users defined on a version 10.2.1 BIG-IP system to have administrator or resource-admin roles, and they have partition access to a single partition, these user config objects fail to load during an upgrade to version 11.x/12.x. "Here is a sample user config from 10.2.1: user v-abban { password crypt '$1$UIPmGYdY$yewCx.a2qNDauz/UB1Jbp/' description 'v-abban' group 500 home '/home/v-abban' shell '/bin/false' role administrator in Common }" Upgrade or load UCS fails with the following error: 01070821:3: User Restriction Error: The administrator, resource administrator, auditor and web application security administrator roles may not be restricted to a single partition. Workaround: Prior to upgrade, edit the bigip_sys.conf to have the role line as follows: ... role administrator in [All] }
435482 "BIG-IP configuration object names that include a space may cause an upgrade or user configuration set (UCS) load to fail. As a result of this issue, you may encounter the following symptoms: Your attempts to upgrade the BIG-IP system or load a UCS fail. After loading a UCS file or upgrading from a configuration that has object names with spaces on BIG-IP 11.4.0 or a later version, the Configuration utility displays an error message similar to the following example: The configuration has not yet loaded. If this message persists, it may indicate a configuration problem. After loading a UCS file that has configuration object names that include spaces on BIG-IP 11.4.0 or a later version, a message appears similar to following example: Unexpected Error: Configuration cannot be saved unless mcpd is in the running phase. Save was canceled. See 'show sys mcp' and 'show sys service'. If 'show sys service' indicates that mcpd is in the run state, but 'show sys mcp' is not in phase running, issue the command 'load sys config' to further diagnose the problem." "This issue occurs when one of the following conditions is met: You attempt to upgrade a BIG-IP system from 11.3.0, or an earlier version, with a configuration that has configuration object names with spaces. You attempt to load a BIG-IP 11.3.0 or earlier UCS file, that has configuration object names with spaces, on BIG-IP 11.4.0 or a later version." The BIG-IP system upgrade or UCS load fails. Workaround: "To work around this issue, you can boot back to the previous BIG-IP 11.3.0 or earlier version and rename all affected configuration objects to exclude spaces before upgrading or saving a UCS file. Impact of workaround: Performing the suggested workaround should not have a negative impact on your system."
436075 Using syslog include field when the command 'syslog-ng -s' does not succeed before the upgrade. Using syslog include field. It is possible to roll forward an include field with invalid syntax. This will cause the configuration to fail to load. Workaround: When using the syslog include field, ensure that the command 'syslog-ng -s' succeeds before the upgrade.
436825 Under certain conditions, nodes (or any other object with an IP address) in a partition that belong to route domain 0 will be treated as part of the default route domain for the partition after an upgrade. "All of these conditions must be true: - A system is being upgraded from any TMOS v10.x release to any TMOS v11.x release after 11.1 or any TMOS v12.x release. Upgrading to 11.0.0 or 11.1.0 is not affected, but the upgrade process resets the partition's default-route-domain setting to 0. - It has a partition that has its default route domain set to a nonzero route domain. - That partition contains nodes with no route domain set (so the default is used). - That partition contains other nodes in route domain 0." Those objects might no longer be addressable or able to connect. Workaround: "Set the partition's default route domain ID to 0 before upgrading, then set it back to its previous value after the upgrade. This field is only used by the GUI and shell, so temporarily changing it to 0 will have no effect on the dataplane."
449617 If a configuration file includes a passphrase for an ssl-key file object, the object may fail to validate when loading the configuration. Passphrase present in ssl-key file object Configuration fails to load Workaround: Remove passphrase line from the file object.
450050 "Following upgrade from 10.x to 11.x/12.x, the config file fails to load. An error similar to the following is logged: load_config_files: '/usr/libexec/bigpipe load' - failed. -- BIGpipe parsing error (/config/bigpipe/bigip.conf Line xxxx): 012e0020:3: The requested item (respondasm {) is invalid (<profile arg> | show | list | edit | delete | stats reset) for 'profile'." "- Upgrading from 10.x to 11.x/12.x. - respondclass configuration directives exist in /config/bigip.conf, for example: profile respondclass XXXX { ... }" Configuration fails to load. Workaround: It is safe in version 11.0.0 and later to manually delete the block: profile respondclass XXXX {.
489015 An LTM request-log profile that references a non-existent pool can pass validation in 11.0.0 or 11.1.0, but fails in 11.2.0 or later, with an error similar to the following: 'The requested Pool (/Common/poolname) was not found.' "This issue occurs when all of the following conditions are met: The UCS file has a Request Logging profile configuration with at least one of the following conditions: A Request Logging profile references a non-existent pool. A Request Logging profile references a pool in a non-default administrative partition without specifying the path to the /<partition>/<pool>. You upgrade from 11.0.0 or 11.1.0 to 11.2.0 or later and roll forward the configuration. You attempt to load an affected UCS created on 11.0.0 or 11.1.0 to a system running 11.2.0 or later." This can cause a load failure when rolling forward the configuration. Workaround: Correct the request-log profile in the config either prior to upgrade or by editing the config after.
490139 Loading iRules from the iRules file deletes last few comment lines immediately preceding the closing bracket. This occurs when loading an iRule file from versions prior to 11.5.1. Although the comments are removed, this does not affect iRule functionality. Workaround: Put comments in places other than immediately above the closing bracket.
496663 iRule object in non-Common partition referenced from another partition results in upgrade/configuration load failure in 11.x/12.x. This occurs when upgrading/loading a configuration containing an iRule in one non-Common partition that references an object in another non-Common partition. A configuration of this type can be saved only using pre-11.x versions of the software. The config upgrade fails, and the UCS/configuration files cannot be loaded. The system posts an error message similar to the following: 'myucs.ucs' failed with the following error message: 'Rule [/UNCOMMONPARTITION/RULEABC] error: Unable to find rule_object (...) referenced at line xyz: [element]'. Workaround: None.
499694 When upgrading from v10.2.x to v11.5.1, the node monitor name does not acquire full path or partition information. Similarly, creating a node with a monitor via TMSH, the node monitor name does not show partition information; however, configuring a node via GUI does add partition information. Upgrade from v10.2.x to v11.5.1. Cosmetic Workaround: Load sys config base, then load sys config. Then both GUI and TMSH add partition info to the node monitor.
513501 When upgrading from a version prior to 11.5.0 to 11.5.0 or newer, the configuration might fail to load with an error similar to the following: LSN pool is configured with a prefix address that overlaps with a prefix address on another LSN pool. "On versions prior to 11.5.0, tmsh allowed users to configure overlapping DNAT and NAPT pools, even though this configuration is invalid and non-functional. Version 11.5.0 and later contain validation to prohibit such configurations. However, when upgrading versions newer than 11.5.0, a configuration that contains overlapping DNAT and NAPT pools fails to load." Configuration fails to load on upgrade. Workaround: Edit bigip.conf and locate the overlapping LSN pools. Either remove one of the pools or change the mode on the DNAT pool to NAPT.
514729 "SSL ciphers 'DEFAULT:!HIGH:!MEDIUM' is allowed in 10.2.1 but will prevent a config from loading in 11.5.1, 11.5.2, 11.5.3, or 11.6.0. This cipher specification is not relevant for software versions 11.5.1, 11.5.2, 11.5.3, or 11.6.0, because all the DEFAULT ciphers fall within HIGH and MEDIUM ciphers. Turning off HIGH and MEDIUM effectively leaves the system with no ciphers to select from. This is the DEFAULT for 11.5.1. !SSLv2:!SSLv3:!MD5:!EXPORT:RSA+AES:RSA+3DES:RSA+RC4:ECDHE+AES:ECDHE+3DES:ECDHE+RC4" "This issue occurs when a 10.2.1 system with an SSL profile specifying ciphers 'DEFAULT:!HIGH:!MEDIUM' is used on a system running version 11.5.1, 11.5.2, 11.5.3, or 11.6.0, either by upgrading, or by manual UCS installation. This is an example of such a profile. profile serverssl serverssl-low_encryption { defaults from serverssl ciphers ""DEFAULT:!HIGH:!MEDIUM"" }" "Upon reboot into version 11.5.1, 11.5.2, 11.5.3, or 11.6.0, or upon load of a UCS from 10.2.1, the configuration fails to load. The operation fails with an error similar to the following. 01070311:3: Ciphers list <list>' for profile <profile name> denies all clients" Workaround: Search for this cipher 'DEFAULT:!HIGH:!MEDIUM' and modify before upgrading. For information about what value to use, see SOL13156: SSL ciphers used in the default SSL profiles (11.x - 12.x), available here:
523797 The upgrade operation might fail to update the file path name for snmp.process_name, causing a validation error. Upgrade from 10.x. The upgrade operation does not remove the parent path name from process-monitors, which might cause a validation error. Workaround: Edit the process name path to reflect the location. For more information, see SOL13540: The BIG-IP system may return inaccurate results for the prTable SNMP object at
532559 If the client-ssl profile is /Common/clientssl, its parent profile is supposed to be /Common/clientssl. But the configuration could potentially use 'defaults-from none'. "This condition could be caused by executing the following command when generating the configuration. 'tmsh modify ltm profile client-ssl clientssl defaults-from none'" The upgrade fails after booting into the new release, during the config loading phase. This occurs because the script extracts the line 'defaults-from none' and treats 'none' as its parent profile. Workaround: Edit the configuration prior to upgrading, changing the defaults-from value on the client-ssl profile to the name of that profile.
571333 When a VIP is configured with a fastl4 profile that enables full acceleration and offload state to embryonic, and if a flow is offloaded to be hardware accelerated, the connection idle timeout during the TCP handshake is set to the "idle timeout" value of the fastl4 profile, but it should be set to the "tcp handshake timeout" instead. "1. Configure fastl4 profile with ePVA=full, offload state=SYN, apply to network VS 2. Ensure ARP entry exists for server node (static arp, ping, etc.) to satisfy requirements for offloading initial SYN 3. Send over SYN packet from client to server via VS" The connection may remain in the half-open state longer than what is set in the TCP handshake timeout value. Workaround: Set the offload state to "established"
586878 "During upgrade, configuration fails to load due to invalid clientssl profile cert/key configuration. The validation to verify whether at least one valid key/cert pair exists in clientssl profiles was enforced in software versions through 11.5.0. This validation was not in effect in versions 11.5.1, 11.5.2, and 11.5.3. The lack of validation resulted in invalid clientssl profiles (those containing empty key/certs or a cert/key of 'default'). When you upgrade such a configuration to 11.5.4 or later, you will receive a validation error, and the configuration will fail to load after upgrade." "The issue occurs when all the below conditions are met. 1. You have a clientssl profile in a configuration from a version without validation (that is, 11.5.1, 11.5.2, or 11.5.3). 2. The clientssl profile in the configuration has an empty cert/key, or a cert/key of 'default'. 3. You upgrade to a version that has the cert/key validation (specifically, 11.5.4, 11.6.0, and versions 12.1.0 and later)." "Configuration fails to load. The system posts an error message that might appear similar to one of the following: -- 01070315:3: profile /Common/my_client_ssl requires a key Unexpected Error: Loading configuration process failed. -- 01071ac9:3: Unable to load the certificate file () - error:2006D080:BIO routines:BIO_new_file:no such file. Unexpected Error: Loading configuration process failed." Workaround: "To workaround this situation, modify the configuration file before upgrading: 1. Check the config file /config/bigip.conf. 2. Identify the clientssl profile without a cert/key. For example, it might look similar to the following: ltm profile client-ssl /Common/cssl_no-cert-key2 { app-service none cert none cert-key-chain { """" { } } chain none defaults-from /Common/clientssl inherit-certkeychain false key none passphrase none } Note: The profile might have cert-key-chain name but not the cert/key. In other words, it could also appear similar to the following example: ltm profile client-ssl /Common/cssl_no-cert-key2 { app-service none cert none cert-key-chain { default { } } chain none defaults-from /Common/clientssl inherit-certkeychain false key none passphrase none } 3. Remove the clientssl profile from /config/bigip.conf. 4. Run the command: tmsh load sys conf. 5. Re-create the clientssl profiles you need."
588946 You can install v11.5.4 on the 12250v platform, but are unable to license BIG-IP. This is because v11.5.4 is not supported on the 12250v platform. Install BIG-IP v11.5.4 on a 12250v platform. BIG-IP v11.5.4 is not supported on the 12250v platform. Even though installation succeeds, it is not possible to license BIG-IP system. Workaround: Install a supported version of BIG-IP on the 12250v. Supported versions are 11.6.0 HF2 or later and 12.0.0 or later.

Changing the resource provisioning level of the Analytics Module

After upgrading or installing a new version, before you can use the Analytics Module, you must set the Analytics Module 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 Analytics Module. The system overrides all configuration changes that are made before this process is completed. When the process is not completed, the system informs you by displaying, in the Configuration utility, this message: AVR is not ready. The system informs you when the process is completed by indicating in the log (/var/log/avr) the following message: AVR started successfully.

Setting the Analytics Module resource provisioning level to Nominal from the command line

You can set the Analytics Module resource provisioning level to Nominal from the command line.
  1. Open the command-line interface utility.
  2. Type the command: tmsh modify sys provision avr level nominal .
  3. Type the command: tmsh save sys config.
The screen refreshes, and the resource provisioning level of the Analytics Module is set to Nominal.

Setting the Analytics Module resource provisioning level to Nominal using the Configuration utility

You can set the Analytics Module resource provisioning level to Nominal using the Configuration utility.
  1. On the Main tab, click System > Resource Provisioning . The Resource Provisioning screen opens.
  2. Set the Application Visibility and Reporting (AVR) option to Nominal.
  3. Click Submit.
The screen refreshes, and the resource provisioning level of the Analytics Module is set to Nominal.

Fixes in 12.1.0

This release includes the following fixes.

ID Number Description
513757 We fixed DoS Layer 7 attack-ID blade synchronization.
525708 A new data aggregation mechanism was inserted, so that all reports include activity up to the last hour. There is an option to make it available even for the last 5 minutes, although that might lead to too much CPU and disk load every 5 minutes. There is also an option to turn off this new aggregation mechanism if you are not interested in accurate long-history reports, and the aggregation task that takes place once an hour is too heavy for this machine.
528031-1 We added device group support, and the user can now choose the device group to query from.
529900 Configuration changes in multiblade systems are now treated correctly.
529903 Reports on multi-bladed systems are now displayed correctly even when the blades are active at different times, and do not share the same level of history.
535246-4 In this release, the system handles AVR data in MySQL so that database size no longer grows beyond a certain point.
537435-3 Exporting a report by email in the middle of monpd's graceful termination (due to restart or other reason) will no longer cause a core dump.
542508 An option to disable each lookup table in the configuration file is now added to the code. Applying changes made to this configuration file requires restarting the machine.
Important: Modifying configuration file should be done only after consulting with F5 support.
549393-2 Secure Web Gateway (SWG) URL categorization no longer causes the /var file system to fill.
552488 This release provides upgrade support for AFM Network DoS reports.
557062 If an ASM predefined report was created in a previous version and the system was updated, it could have caused the configuration upgrade to fail. This failure no longer occurs.
559060-1 Correct data is now presented in the statistics of a configuration in which one BIG-IP system is acting as the server in a multiple BIG-IP device configuration.
560014-1 You no longer see an error that was logged in the monpd log after upgrading when there was traffic capture data in the database.
562780 You can now control the buffer size of HTTP traffic captured of both the request and response payload. To do this, perform the following steps:
  1. Edit /etc/bigstart/scripts/avr.provision.
  2. Change the lines: tc_request_buffsize=2048 and tc_response_buffsize=2048 to tc_request_buffsize=<new size> and tc_response_buffsize=<new size>
  3. Restart tmm by running the command: bigstart restart tmm
565412 When AVR gets a report on device-level mitigation, it correctly reports it as "Device Level" and not as "Aggregated".
567355 A saved scheduled report is no longer lost after loading the system configuration.
573697 Deleting Overview Widgets no longer leaves unneeded objects in the database.
578353-3 The aggregation process of statistics in DB which is done using monpd should be optimized, and skip redundant updates of tables.
578690 The error Unrecognized ASM violation code <<violation number>>... no longer appears in the monpd log.
579049 We fixed an issue that intermittently caused the TMM to core.
580898 We fixed an issue that caused memory corruption resulting in avrd running in an infinite loop and not collecting statistics.

Known issues

The following items are known issues in the current release.

ID Number Description
344054 The system calculates statistics in the graphs differently than in the table. In the graphs, the system displays a snapshot of statistics recorded at a specific point in time, every five minutes. In the table, the system displays a cumulative number of statistics recorded.
344763 It may take a few minutes for graphs to display changes made to the Analytics configuration.
346255 Analytics does not collect page load time statistics for gzipped (compressed) responses.
351257 Health monitor requests for Global Traffic Manager (GTM) pools or servers are shown in Analytics statistics. (Note that GTM is BIG-IP DNS as of version 12.0.)
368119 AVR+APM: If an Analytics profile is assigned to a virtual server and an Access Profile is assigned to the same virtual server, then statistics for pool members are not displayed for page load time.
372174 After changing the sampling ratio, you must restart the MD service by running the command: bigstart restart md.
379479 For chunked responses, the system reports the average HTTP response size in the Configuration utility and database as at least 25 bytes less than its actual size. This is because the system does not report the header "Transfer-Encoding:chunked" and the numbers that indicate the chunked size.
396068 Sometimes when you drill down on the Statistics > Analytics screen, the system displays the following error message: Cannot drilldown into entity: %s .
396131 Although the system permits you to select options from the filter to view statistics by a client IP address and then drill down to view statistics for a custom domain-name ("query name"), you should not. This filter combination is invalid and does not produce results.
397064 If you stop and restart a "bigstart" daemon (for example, if you run the command bigstart restart mysql) afterward, you must also run the command bigstart start to restart dependent daemons.
402353 AVR concurrent session statistics available in iRules are not reset to zero when the traffic is completely stopped. So a later event that triggers iRules and checks for the concurrent number of active sessions does not acquire a value of zero. Instead, it acquires the number of active sessions for some time in the past when there was traffic activity.
404106 When sending HTTP traffic through a virtual server configured with AVR and Response-Adapt profiles, and the ICAP server modifies the response, AVR does not report any activity for the virtual server.
407631 There may be situations where the system's DoS mechanism detects a DoS attack, but the RAM-cache handles the attacking transactions instead of the module. In these cases, while the system detects the attack, the system does not report the attack unless AVR is also assigned to the virtual server.
414273 The results of a user-created filter on the Event Logs > Application > Requests screen may appear differently when using the same filter on the Reporting > Application > Charts screen.
415883 On rare occasions, provisioning changes that involve the AVR, ASM or AFM modules can cause TMM to continuously restart after the machine is reactivated. A reboot to the machine solves the problem (by running the command "reboot").
419676 When you define an alert on an Analytics profile that is assigned to multiple virtual servers, and that alert is defined for any maximum TPS, latency or throughput on an application or pool member, that alert will not be notified, and the LTM log (/var/log/ltm) will show an error message: could not find id or measure field in report ....
441578 If you use an iRule to disable AVR from collecting statistics for a specific URL, that URL does not receive Application Security DoS protection even if Application Security DoS protection is enabled on the virtual server.
455027 Application-level DoS reporting: If traffic runs through a virtual server that is not assigned to DoS profile, it is published as Aggregated instead of using a more descriptive value, as "Unknown" or "N/A".
472291 If AVR is provisioned, and statistics are produced while traffic is running through a virtual server assigned to an Analytics profile, the Configuration utility does not automatically log out after the logout period (configured in the Idle Time Before Automatic Logout setting in the System > Preferences screen) when any Analytics screen under the Statistics menu is opened.
560114 When the monpd daemon is restarted, it starts printing non-stop error message to logs. Analytics statistics may be lost, and new data cannot be loaded. To work around this issue, run the following commands:

find /var/avr/loader/ -mindepth 1 -name "*" -print0 | xargs -0 rm

touch /var/avr/init_avrdb

bigstart restart monpd

575170 AVR reports on virtual server activity is sometimes missing due to the way these virtual servers are configured, and an error in the logic of AVR to correctly identify these virtual servers. This occurs if virtual servers are configured in one of these ways:
  1. Two virtual servers have the same IP-Port-RouteDomain setting, but are set for different protocols (such as TCP for one and UDP for the other) or different sources.
  2. Virtual server defined with masked IP address (that is, not an explicit address, but for example
As a result of this issue, reports made by AVR do not recognize the correct virtual server, and instead report on the Aggregated Virtual Server or a wrong one.

Contacting F5 Networks

Phone: (206) 272-6888
Fax: (206) 272-6802

For additional information, please visit

Additional resources

You can find additional support resources and technical documentation through a variety of sources.

F5 Networks Technical 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 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.

F5 DevCentral

The F5 DevCentral community helps you get more from F5 products and technologies. You can connect with user groups, learn about the latest F5 tools, and discuss F5 products and technology.

AskF5 TechNews

Weekly HTML TechNews
The weekly TechNews HTML email includes timely information about known issues, product releases, hotfix releases, updated and new solutions, and new feature notices. To subscribe, click TechNews Subscription, complete the required fields, and click the Subscribe button. You will receive a confirmation. Unsubscribe at any time by clicking the Unsubscribe link at the bottom of the TechNews email.
Periodic plain text TechNews
F5 Networks sends a timely TechNews email any time a product or hotfix is released. (This information is always included in the next weekly HTML TechNews email.) To subscribe, send a blank email to from the email address you are using to subscribe. Unsubscribe by sending a blank email to

Legal notices