Applies To:

Show Versions Show Versions

Release Note: BIG-IP 14.0.0 New and Installation
Release Note

Original Publication Date: 10/30/2018

Summary:

These release notes document the BIG-IP version 14.0.0.x releases. You can apply the software upgrade to systems running software version 12.0.0 or later (except as detailed in the upgrading sections).

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, BIG-IP DNS, Application Security Manager, Access Policy Manager, Policy Enforcement Manager, Application Firewall Manager, Application Acceleration 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.

Note: The BIG-IP VE product license determines the maximum allowed throughput rate. To view this rate limit, you can display the licensing page within the BIG-IP Configuration utility.

Contents:

- Platform support
- Module combination and memory considerations
- Release fixes, behavior changes, and known issues
- User documentation for this release
- Compatibility of BIG-IQ products with BIG-IP releases
- Configuration utility browser support
- New in 14.0.0 :: LTM/TMOS
- New in 14.0.0 :: ASM
- New in 14.0.0 :: AFM
- New in 14.0.0 :: APM
- New in 14.0.0 :: AVR
- New in 14.0.0 :: DNS
- New in 14.0.0 :: FPS
- New in 14.0.0 :: PEM
- New in 14.0.0 :: Cloud
- New in 14.0.0.1 :: Cloud
- New in 14.0.0 :: VE
- New in 14.0.0 :: AAM
- New in 14.0.0 :: Hardware
- 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
     - Setting the Application Security Manager resource provisioning level to Nominal from the command line
     - Setting the Application Security Manager resource provisioning level to Nominal using the Configuration utility
- To prevent traffic from bypassing the Application Security Manager
- FPS 14.0.0 Upgrade and Compatibility Information
- About working with device groups
- Synchronizing the device group
- Supported ICAP servers
- AVR :: Merged metrics to HTTP statistics tables
- AVR :: New and updated dimensions
- AVR :: New and updated metrics
- AVR :: Updated HTTP statistic tables
- Contacting F5
- Legal notices

Platform support

For comprehensive information about supported platforms, see:

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.

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

 

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

Release fixes, behavior changes, and known issues

User documentation for this release

For a list of Virtual Edition (VE) hypervisor support, see the Virtual Edition and Supported Hypervisors Matrix.

Compatibility of BIG-IQ products with BIG-IP releases

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

Configuration utility browser support

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

  • Microsoft Internet Explorer 11.x
  • Mozilla Firefox v40, or later
  • Google Chrome v44, or later

New in 14.0.0 :: LTM/TMOS

Default change: Secure Password Policy now enabled by default

Beginning in v14.0.0, Secure Password Policy is enabled by default. On new installations, the passwords for root and admin accounts are expired and must be changed upon initial login. This does not apply to upgrades or UCS load. For more information, see Secure Password Policy is enabled by default :: https://support.f5.com/csp/article/K10612010 or the BIG-IP System: Secure Password Policy guide.

UltraFast L4 CPS Profile

On certain F5 hardware platforms (namely B4450 blade models and TurboFlex-enabled iSeries platforms), you can deploy a load-balancing optimization feature known as an Ultra Fast Layer 4 CPS profile. This profile enables specific hardware-acceleration features for high-performance load balancing, when you need the BIG-IP system to do mostly basic Round Robin load balancing only. For more information, see F5 Platforms: TurboFlex Profiles.

Support for IPv6 management IP addresses

This version of the BIG-IP software allows you to configure IPv6 management IP addresses. On appliance models, if you enable the Dynamic Host Configuration Protocol (DHCP), the system assigns a management address in IPv4 format, but also allows you to manually specify an IPv6 address as an alternate address. If you disable DHCP, you can specify either a single management address (in IPv4 or IPv6 format) or an IPv4 address and an alternate IPv6 address. On VIPRION platforms, the BIG-IP system supports floating cluster IP addresses in both IPv4 and IPv6 formats, as well as static IPv4 and IPv6 addresses for each slot in the cluster.

Support for TLS v1.3 (Internet-Draft 26 only)

The BIG-IP system now supports IETF Internet-Draft 26 for Transport Layer Security (TLS) Protocol version 1.3. Because the BIG-IP system supports Internet-Draft 26 only, this support for TLS version 1.3 is considered to be in beta phase and is not meant to be deployed in production environments. A list of major differences from TLS version 1.2 is included in Internet-Draft 26, here: https://tools.ietf.org/html/draft-ietf-tls-tls13-26.

BIG-IP supports importing existing NetHSM keys

For this release, you can now import existing Network HSM keys to the BIG-IP system. Multi-slots are not yet supported. For more information, see the implementation guides for Thales and SafeNet.

Local Attestation for TPM Chain of Custody

The BIG-IP iSeries and VIPRION B4450 platforms include a Trusted Platform Module (TPM) that comes with functionality to aid in attestation and confirming chain of custody for the device locally without the need for doing it manually. TPM Chain of Custody provides assurance that the software loaded on your platform at startup time has the same signature as the software that is loaded by F5 when the system is manufactured. For more information, see BIG-IP System: Essentials.

Removal of cipher keyword COMPAT

In this release of the BIG-IP system, the cipher keyword COMPAT and any subset keywords such as SSLV2 and RC2 have been removed, due to increased support for ciphers formerly supported in the OpenSSL cipher stack only. Due to the removal of the COMPAT keywords, the keyword NATIVE is now equivalent to All.

Support for ECC curve25519

The BIG-IP system now supports Elliptic Curve Cryptography (ECC) curve25519, for use with cipher strings that specify Elliptic Curve Diffie-Hellman (ECDH) key agreement. Support for curve25519 appears in the BIG-IP cipher groups feature as Diffie-Hellman (DH) group X25519 and is used when building a cipher string on the BIG-IP system for SSL negotiation.

Support for ECDSA key management on CAVIUM NITROX III FIPS HSMs (10350F, 7820F, 5820F)

On F5 platforms containing a CAVIUM NITROX III hardware security module (HSM), you can now manage Elliptic Curve Digital Signature Algorithm (ECDSA) keys. Note that the supported key exchange method for ECDSA keys on these platforms is Elliptic Curve Diffie-Hellman Ephemeral (ECDHE).

Support for ECDSA key management for SafeNet and Thales HSM

For this release, you can now create, list, and delete Elliptic Curve Digital Signature Algorithm (ECDSA) keys for Thales and SafeNet using TMSH, iControl, or the GUI. The Network HSM client must still be installed and configured beforehand. For more information see the implementation guides for Thales and SafeNet.

MQTT is using MRF

For this release, in a Message Queuing Telemetry Transport (MQTT) configuration, MQTT switched to using a Message Routing Framework (MRF) proxy while supporting the existing behavior of connection based load balancing.

iRule for allowing cloning of messages

For this release, there is a new iRule command that lets users clone incoming messages and identify for routing. This feature is part of the Message Routing Framework (MRF) and works for all protocols.

Support for insertion of header options into server-side SYN

You can now use the iRule TCP:option commands to insert header options into a server-side SYN during the initial three-way handshake, instead of after the handshake is complete.

Dashboard at the top level of the Statistics menu

This release includes a Dashboard with a new look and feel (the old one was removed) based on web technologies and open source visualization and charting tools. All of the elements from the old Dashboard have been migrated to the new one.

UDP Bandwidth Control

This release of the BIG-IP system includes performance enhancements with respect to UDP bandwidth control. Specifically, you can control bandwidth for egress UDP traffic flows by specifying an upper limit for the UDP packet flow rate. When the flow rate exceeds a certain value, the BIG-IP system queues the packets in a buffer up to a configured threshold. When the upper limit is reached, the system drops packets intelligently, according to a defined queue dropping strategy.

New in 14.0.0 :: ASM

Web Threat Campaigns

A Threat Campaign is an attack associated with a specific malicious actor, attack vector, technique or intent. F5 discovers and investigates these attacks. The Web Threat Campaign is implemented as a new ASM policy entity. Threat Campaigns are inherited from parent policies to child policies. Threat Campaigns are accessed from Security :: Options : Application Security : Threat Campaigns.

The Web Threat Campaign feature requires a separate license. Licensed machines receive dynamic updates, in the form of a binary image file. Users can decide if a Threat Campaign is added in staging after an update. The default is no staging. When upgrading, existing Threat Campaigns are preserved. If a Web Threat Campaign license expires, all campaigns on a device are inactivated.

Threat campaigns include iRule support.
  • ASM::threat_campaign <names | staged_names>: Returns the list of threat campaigns found in the transaction.
    • ASM::threat_campaign names: Returns a list with the names of the threat campaigns found in the transaction.
    • ASM::threat_campaign staged_names: Returns a list with the names of the staged threat campaigns found in the transaction.

Layered Policy Enhancements

To increase the functionality of layered policies, the following enhancements have been made:
  • Administrators can mandate that all new security policies created must be attached to a compatible parent policy.
  • All attached child policies for a parent policy are listed in the parent policy details.
  • Parent policy suggestions now have a maximum score of parallel suggestions in its child policies. All locked child suggestions propagate to the parent policy. The score of the parallel suggestion in each child is shown in the parent policy pane per suggestion, with the top scoring children marked.
  • All inherited attributes are marked with an icon to distinguish them from non-inherited attributes.

URL Positional Parameters Support

URL positional parameters are supported as part of global parameters. The URL with positional parameters is a non-pure wildcard, e.g. /p/* or */cart/*/item/php. When creating a New Allowed URL, enable Positional Parameters to use this feature. It is possible to modify or delete URL segments before the URL is created but note that global parameters used as positional parameters cannot be deleted once created. Both the URL and the parameter names are immutable after creation. Positional parameters are not supported for WebSocket URLs.

Increased Sensitive Data Masking

Sensitive data values disclosing personal details about users and credit cards can be masked in:

  • HTTP Header fields, especially Authorization
  • URL segments with personal identification using positional parameters
  • Cookie values
  • HTTP Request body using positional parameters

The field Sensitive Data was renamed to Mask in logs. These data values are masked in the ASM, local and remote request logs. If at least one of the entities marked for masking is present in a violation, the violation details snippet will not be shown, even if the violation did not occur within the masked entity.

Sensitive data values are not masked in:

  • Response log header and body. In this case, Data Guard applies.
  • Antivirus over ICAP
  • Database security
  • Policy Builder.

Cookie Modifications

The ASM policy and Device ID cookie names can be modified. This can be used to mask ASM cookies or to allow users to rename ASM cookies to fit in-house cookie conventions. The maximum cookie size is increased from 8 KB to 16 KB to accommodate user applications which block 8 KB cookies. The new database variable Strip ASM cookies from request is enabled by default.

The system must be restarted for cookie name modifications to take effect.

Support for Wildcards in Disallowed HTTP, HTTPS and WebSocket URLs

Wildcards are supported in disallowed URLs, though a pure wildcard is only supported in allowed URLs. Both allowed and disallowed wildcards are listed in the Wildcards Order table and their rule application is by order in the list. For example: when the rules allow /a/*/b and disallow /a/c/* are configured, to allow or disallow /a/c/b.html is decided by which rule, allow or disallow, is first in the Wildcards Order table. Adding a new wildcard places it first in the wildcard order. Allowed and disallowed wildcards can be subsets of each other.

Expanded Health Monitoring

The scope of resource utilization is expanded to include request queue sizes with threshold alerts triggered and sent over local log, SNMP or SMTP. In this way, users can spot capacity issues in real time. Reported values are the averages of the last 1 minute.

Metric Description Default Threshold Range of Values
TMM CPU Usage CPU Usage percentage of the TMM processes averaged over all cores 85% 1-100
Total CPU Usage CPU Usage percentage of all processes averaged over all cores 90% 1-100
ASM CPU Usage CPU Usage percentage of BD processes averaged over all cores 85% 1-100
ASM CPU Usage per VS CPU Usage of BD per a specific Virtual Server 35% 1-100
TMM Memory Usage Memory Usage percentage of the TMM taken from the total memory provisioned for TMM. 95% 1-100
UMU Memory Usage BD UMU memory pool Usage: used for most purposes except for XML traffic 90% 1-100
XML Memory Usage BD XML memory pool Usage 90% 1-100
Total Swap memory Usage Swap memory consumed by all processes out of the total swap area 10% 1-100
ASM Swap memory in MB Swap memory consumed by BD out of the total swap area 5% 0-MAX_INT
Event message queue Usage Events waiting for BD in the MPI queue out of the queue capacity averaged over all queues 90% 1-100
Backlog message queue Usage Messages that fell off the MPI queue and put in the backlog queue out of the queue capacity averaged over all queues 5% 1-100
Bypassed transaction rate Number of HTTP transactions per second that bypassed ASM due to unavailability of BD service 0.1 0.1-1 million

Subcommands of asm health-alerts are used to set the global alerts.

Subcommand Values Default Comment
notification-by-email enabled/disabled disabled Requires SMTP configuration profile. See alert configuration below.
notification-by-syslog enabled/disabled disabled Writes to /var/log/ltm
notification-by-snmp enabled/disabled disabled Requires SNMP configuration. See alert configuration below.
alerts Structure of alerts as in Analytics profile. empty See configuration below.
external-logging-publisher Publisher name none  
notification-email-addresses List of email addresses empty  
<metric-name>-enable enabled/disabled disabled Enables or disables the threshold notification for the respective metric. The <metric-name> is the name as it appears in the Metrics and Thresholds table above but all lower case and dashed instead of spaces. For example: tmm-cpu-usage.
<metric-name>-threshold Integer See table above The metric threshold value for notification.

Cross Origin Requests with Single Page Applications

The system database, tmsh list sys db dosl7.allowed_origins, allows the addition of a list of domains allowed to send out AJAX requests with custom headers. When configured with single page application support, BIG-IP adds additional CORS headers to AJAX responses generated by BIG-IP. This prevents browsers from blocking cross domain AJAX requests while still enforcing a CORS policy with single page applications.

Policy Properties Information Restructuring

The Policy Properties page has been removed and the information previously contained in the Policy Properties screen has been integrated into the Policy Summary which is renamed to Policy Properties. The Signature Staging field appears in the Learning and Blocking Settings screen. The Enforcement Readiness Period field has moved to the Learning and Blocking Settings screen..

Exporting Incidents

Incidents can be exported, individually or in multiples, to HTML format. The export includes all details of the incident record(s).

Exporting Learning Suggestions

Learning Suggestions can be exported, individually or in multiples, to HTML format. The export includes all details of the Learning Suggestions record(s).

Improved Application Request Filtering

Several filtering options have been added for application requests. The default filter now shows all requests, legal and illegal, and not just 5 as previously. A single log can be refreshed and the Refresh option includes no refresh. After configuring the requests filters, the filter settings can be flagged to be remembered for the logged in user.

Improved Violation Details

The state of each entity, either blocked or staged, is displayed. This applies for attack signature, wildcard parameter name, cookie, URL and threat campaign entities.

MySQL Database Replacement

The Oracle MySQL database has been replaced with the open source MariaDB database across the BIG-IP product.

Pane Expand and Collapse Functionality

An expand/collapse functionality was added to the right panes, to replace the full screen button, for these screens:
  • Traffic Learning
  • Requests
  • Event Correlation
  • Brute Force Attacks
  • Policies List

Policy Toolbar Improvements

The Policy toolbar includes details of the selected policy's Learning Mode, Auto-Apply setting and Parent policy. The Policy toolbar also includes clickable icons to the Policy Properties and Learning and Blocking Settings of the selected policy.

One-Click Apply Multiple Policies

After modifying one or more policies, a new Apply Policies button on the Policies List page enables the user to apply all changes to all selected modified policies with a single click.

Brute Force Attacks Filter for Login Stress

The Login Stress table on the Brute Force Attacks page includes a filter to display all brute force attacks for a corresponding login page.

Requests and Triggered Violations Table Improvements

The Triggered Violations are now presented in a table with links to further details.

Security Log Profile Rewritten with Angular over REST

The Security Log Profile was rewritten with Angular over REST. Users will see inline validations in red as the graphic manifestation of this infrastructure improvement.

Scheduled ASM and DoS Data Obfuscation

The daily start times of system obfuscation can be scheduled from the Background Tasks screen via Security :: Options. This allows the tasks to begin during less active website hours.

New in 14.0.0 :: AFM

Hardware enhancements to DoS protection

This release includes three compatibility levels that enable different levels of DoS protection and several types of whitelists, depending on the hardware platform of your system.

  • Compatibility level 0 provides basic hardware DoS capabilities with device protection and rich whitelists.
  • Compatibility level 1 applies to either a VE system with no hardware offload or a system with hardware DoS and sPVA capabilities. In addition to level 0 features, provides hardware DoS protection per protected object, whitelist address list, IP intelligence, and bad actor/attacked destination discovery.
  • Comnpatibility level 2 applies to a system with hardware DoS, sPVA, and Neuron capabilities (in addition to level 1 features provides extended whitelist).

Simplified user interface

The 14.0.0 release has a new, simplified user interface that is easy to use. Terminology has been simplified for DoS Protection. You now configure protected objects (instead of virtual servers) and protection profiles (instead of DoS profiles).

Visual network configuration

Network quick configuration includes visual aids to help determine the appropriate way to configure DoS protection your network. You can select different methods for inline and out-of-band deployments, and are prompted for information needed for the quick configuration of common network topologies.

DoS protection enhancements

Several enhancements improve DoS protection in the network firewall. New vectors protect against attacks for NXdomain, SSL (renegotiation, flood, and incomplete handshake), non-TCP connection rate limit, and listener mismatch. You can associate a DNS profile with a protection profile.

Protocol Inspection improvements

Protocol inspection functionality now includes additional compliance checks for DNS, FTP, and HTTP protocols. The system provides learning and staging suggestions as a result of examining protocol to detect real attack attempts and reduce false positives. Protocol inspection analytics, charts and event logs allow users to filter information for events of interest, identify top inspections, attacking IP addresses, and applications under attack. Enhancements to the SSH profile support the SSH proxy including setting the LANG variable, event type in the log, the public key is derived from the supplied private key making it optional.

Netflow changes

You can now define Netflow Protected Server objects that represent subsets of traffic for use in developing distinct scrubbing policies.

Dynamic Signature support

Dynamic signature creation is supported in this release.

Advertisement of Flowspec routes

The system allows for advertisement of flowspec routes using flowspec route injector profiles. The flowspec route injector profile lets you deploy filtering rules among BGP peer routers to mitigate DDoS attacks.

Dual stack management support

You can configure both firewall rules with IPv4 source and destination addresses and firewall rules with IPv6 source/destination addresses in the management port context. The system selects appropriate rules from the configuration and applies them to the incoming traffic based on the address family of the management port IP addresses.

New in 14.0.0 :: APM

APM Dashboard refresh

The APM Dashboard, which displays statistics about APM connections, has been redesigned with a new look. It no longer requires the Adobe Flash plugin. Click Access > Overview > Dashboard to see it.

SAML inline SSO support

APM and LTM support configurations where customers use the BIG-IP system as a SAML Identity Provider. You can implement WebSSO-like functionality for SAML Service Providers that are located behind the BIG-IP system, such as when the Service Provider is not directly reachable by the clients.

Authorization server support for OpenID Connect

APM includes OpenID Connect support in the APM Authorization Server Framework for ID token and UserInfo generation.

OpenID Connect metadata discovery

APM can retrieve OpenID Connect metadata periodically and automatically update the configuration, including JSON Web Key configuration, without administrator intervention. Set this up with the Use Auto JWT and discovery task settings when creating an OAuth provider.

VMware Blast Extreme Adaptive Transport (BEAT) protocol support

APM now supports Blast Extreme Adaptive Transport (BEAT), an enhanced version of VMware’s Blast Extreme protocol. By dynamically adapting to network conditions, BEAT provides improved user experience in LAN as well as in high-latency, low-bandwidth WAN, and mobile networks.

VMware Workspace ONE integration

APM now supports VMware deployments wherein users first authenticate with VMware vIDM (vIDM can be on-premises or in cloud as part of the Workspace ONE suite); when users access resources protected by APM, they are redirected to APM. In this scenario, vIDM acts as an Identity Provider (IdP) and APM as a Service Provider (SP).

Multi-factor Authentication and device posture check for Office clients

APM now supports multi-factor authentication and a device posture check for native Microsoft Office clients (Word, Excel, PowerPoint, OneNote, OneDrive, and Skype for Business) accessing documents on Office 365 with on-premises SharePoint. APM uses f5epi helper applications for the device posture check.

Authorization support for Access policy with SSLO

APM access policies can provide authorization for HTTP and non-HTTP traffic in conjunction with SSL Orchestrator (SSLO). The session check agent in the SSLO per-request policy can identify whether a main access session is present or not and take actions based on that.

Additional data for SSLO per-request policies

SSLO per-request policies now have access to the following information for use with branching:

  • TCP/IP address/port
  • SSL SNI and SAN
  • IP Intelligence data
  • IP Geolocation data

New in 14.0.0 :: AVR

Enhanced viewing options for DoS Visibility data with real time

In this release, the BIG-IP system can present within the tables and charts of DoS Visibility screens with real time data. The DoS Dashboard and DoS Analysis screens allow you to activate the a time view option that updates data over 10 second intervals. When activated, both charts and tables display data in real time. Charts display a one-hour summary of data that was collected over real time, while data presented in the tables displays data in real time. Real time does not extend to dimension data, which is presented as a one-hour summary and refreshed over a 5 minute interval.

Note: When enabling real time while running a device cluster, DoS Visibility displays data for the entire cluster, which results in an additional 10 second delay for displayed data.

Extended traffic capturing filters for URLs

Traffic capturing for URLs now allows for configuration of white list or black list filters in the HTTP Analytics profile. You can configure your profile to exclude or include traffic information from up to 10 specific URLs. You can modify traffic capturing filters via the BIG-IP GUI or Traffic Management Shell (tmsh) command.

Extended configuration options for collected entities

Profile now allows you to add filters for specific URLs, IPs, Subnets and countries. Once each is selected for data collection in your HTTP Analytics profile, you can further configure statistics collection to include up to 10 specific entities. The system includes all available combinations of entity filters when collecting data.

Collected entities for your HTTP Analytics

Your HTTP Analytics Profile now allows you to enable filters that only collect traffic that is qualified for JavaScript injection.

You can modify these collected entity filters via the BIG-IP GUI or tmsh command.

Limit number of entities in a snapshot per virtual server

AVR now allows you to enable and configure a limit to the combined number of entities in a snapshot per virtual server. This feature extends to all dimensions excluding:
  • Virtual Servers
  • Transaction Outcomes
  • Pool Members
  • Response Codes

Enhanced data transferring capabilities

AVR statistics data transfer capabilities to BIG-IQ have been enhanced to ensure secure and efficient data processing.

Improved performance for complex data queries

AVR now support multiple data queries in a single request, improving response time for displaying statistics data.

New in 14.0.0 :: DNS

DNS cache statistics

For this release, the TMSH command 'show ltm dns resolver', which is used to monitor DNS cache resolver, has new statistics added to give insight into traffic from the resolvers to nameservers and for various types of zones. Relabeling and reformatting of the output was also completed.

Support for large DNS zones

Increased the stability and scalability of the DNS Express system to allow hundreds of thousands of DNS zones with a combined hundreds of millions of records to be hosted with a total zone database size approaching 100GB on suitable F5 platforms.

Running gtm_add and bigip_add without requiring passwords

Extending existing scripts, gtm_add and bigip_add, to run without requiring interactive input of passwords.

Support for EDNS0

For this release, the BIG-IP system now supports certain functionality associated with the Extended DNS (EDNS0 or EDNS) client subnet option.

New in 14.0.0 :: FPS

SPA support - page/view identification

Single Page Application (SPA) Views: BIG-IP 14.0.0 supports configuring FPS on Single Page Application (SPA) views. In a Single Page Application, a URL can have multiple views (layouts/content sets), where views change without a full page reload. SPA views can be configured in BIG-IP 14.0.0 with Malware Detection, Automatic Transactions Detection, and Application Level Encryption; and a SPA view can be configured as a login page.

Add wildcard support for parameters

Wildcard Parameters: Parameters can now be defined on a URL or SPA view using wildcard expressions, which allows applying the various types of FPS detection and encryption to a much broader range of parameters.

GUI: improve parameters view

GUI Improvements: The user interface for defining parameters on a URL or SPA view has been improved. Parameters are now defined in their own screen so that all the settings for a parameter are clearly visible and logically presented to the user. Only parameter settings relevant to the URL type (web-based or mobile-based) are displayed.

New in 14.0.0 :: PEM

No new features

There are no new policy-enforcement-specific features in this release.

New in 14.0.0 :: Cloud

No new features

There are no new cloud-specific features in this release.

New in 14.0.0.1 :: Cloud

Support for C5 and M5 AWS instance types

When deploying BIG-IP in AWS EC2, the C5 (compute optimized) and M5 (general purpose) series of instances are now supported. This includes support for NVMe storage as well as the Elastic Network Adapter (ENA). Versions of BIG-IP prior to 14.0.0.1 do not support these instance types.

New in 14.0.0 :: VE

No new features

There are no new VE-specific features in this release.

New in 14.0.0 :: AAM

No new features

There are no new acceleration-specific features in this release.

New in 14.0.0 :: Hardware

BIG-IP i850 Platform

This release adds software support for the BIG-IP i850 platform. For more information, see Platform Guide: i800 Series.

BIG-IP i11000 Series Platform

This release adds software support for the BIG-IP i11000 Series platform. For more information, see Platform Guide: i5000/i7000/i10000/i11000 Series.

Support for vCMP on i15000 Series Platforms

This release adds software support for Virtual Clustered Multiprocessing (vCMP) on BIG-IP i15000 Series platforms.

Enhanced support for vCMP on i15000-Series platforms

This release enhances performance for Virtual Clustered Multiprocessing (vCMP) guests on BIG-IP i15000 Series through improved core allocation. A guest on this platform is no longer limited to a maximum of eight cores; you can now deploy a guest with any number of cores up to the maximum available on the platform. Furthermore, this enhancement improves efficiency by reducing the chance that cores will remain unused on the system. For more information, see F5 Platforms: Platform Diagnostics.

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

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

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 K12878: Generating diagnostic data using the qkview utility.
  3. Log on to the browser-based Configuration utility.
  4. Run the Setup utility.
  5. Provision the modules.
Note: You can find information about running the Setup utility and provisioning the modules in 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.

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.

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
394873 Upgrade process does not update Tcl scripts Upgrading Tcl scripts (such as iRules). This might cause issues when iRule syntax changes between releases. After upgrading, you might need to modify iRules to reflect any changes in iRule syntax. The upgrade process does not update Tcl scripts (such as iRules) in the configuration. Workaround: None.
530010 FIPS firmware v2.2 update on BIG-IP 5250, 7200F, 10200F, and 11050F platforms running the Cavium Nitrox XL FIPS cards. "This impacts BIG-IP 5250, 7200F, 10200F, and 11050F FIPS platforms running FIPS firmware 2.1 or earlier. You can tell what firmware you have installed by running the following command at the command line: fipsutil info The firmware version listed should be the following: CN16XX-NFBE-FW-2.2-130013." "All platforms shipped prior to June 30th, 2016, contain an older firmware version and must be updated to run the NIST-approved version. To comply with current NIST requirements, the new firmware has deprecated support for 1024-bit key creation. Existing 1024-bit keys in the device can still be used normally." On BIG-IP 5250, 7200F, 10200F, and 11050F platforms running the Cavium Nitrox XL FIPS cards, the FIPS firmware version 2.1 has been moved to the Legacy list by NIST as the RNG function does not meet modern-day FIPS standards. For more information, see the external resource, available here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm. Workaround: "F5 Networks has released a downloadable firmware installer that you can download and apply to the platforms containing the FIPS firmware 2.1 or earlier. For more information about FIPS compliance, see SOL7837: Overview of FIPS 140-2 EAL Level 2 and 3 RoHS Certification Status, available here: https://support.f5.com/kb/en-us/solutions/public/7000/800/sol7837.html." FIPS firmware v2.2 update on BIG-IP 5250, 7200F, 10200F, and 11050F platforms running the Cavium Nitrox XL FIPS cards.
566998 Edge client upgrade fails if client was configured in locked mode "Edge client package was downloaded with ""Enable Always Connected mode"" option checked Server contains a newer version of edge client" Automatic upgrade of edge client will fail Edge client cannot be upgraded automatically to a newer version Workaround: Manually uninstall and re-install client
575347 Unexpected backslashes remain in monitor 'username' attribute after upgrade Upgrading from an earlier version with a configuration that contains a monitor 'username' attribute with at least one escaped backslash ('\\'). Monitor probes contain excess backslashes which can lead to monitor failures. The monitor 'username' attribute contains unexpected backslashes. Workaround: Un-escape backslashes after upgrade by transforming '\\' sequences to '\'. Removed excess backslashes from monitor 'username' attribute during upgrade process.
576521 If you have MSSQL proxy feature configured, you will lose it upon upgrading to v13.0.0 or later. "-- MSSQL proxy is configured. -- Upgrade to v13.0.0 or later." You will lose MSSQL proxy feature upon upgrade to v13.0.0 or later. MSSQL proxy is no longer supported. MSSQL proxy is removed from BIG-IP product. Workaround: None. If you have MSSQL proxy feature configured, you will lose it upon upgrading to v13.0.0 or later.
580602 Configuration containing LTM nodes with IPv6 link-local addresses fail to load. Attempt to load a configuration containing a LTM node with a IPv6 link-local address. Configuration fails to load. As a result of a known issue a configuration containing LTM nodes with IPv6 link-local addresses may fail to load. Workaround: Use IPv6 global addresses instead. Bigip now loads correctly a configuration containing a LTM node with a IPv6 link-local address.
581824 "Instance not found" error when viewing the properties of GSLB monitors gateway_icmp and bigip_link. Viewing the GSLB Monitors tcp_half_open, gateway_icmp and bigip_link's properties page. You cannot view some of their monitors' properties. When you attempt to view the monitors' properties, the page throws an "Instance not found" error. Workaround: Fixed the "Instance not found" error.
596104 HA trunk unavailable for vCMP guest "This occurs when an HA trunk is configured a vCMP guest, with a threshold value greater than 0. This may occur by any of the following means: 1) Attempting to upgrade a guest to an affected version of BIG-IP, with an HA trunk configured with a threshold value greater than 0. The upgrade fails with the indicated error message. 2) Attempting to load a UCS from a guest with an HA trunk configured with a threshold value greater than 0. The UCS load fails with the indicated error message. 3) Creating an HA group and then attempting to modify the threshold value for the HA trunk. The modify command fails with the indicated error message." "HA trunks do not work. You cannot upgrade the vCMP guest to an affected version of BIG-IP or load a configuration with an HA trunk configured with a threshold value greater than 0." "If a vCMP guest is configured with a high availability (HA) trunk with a threshold value greater than 0, the HA trunk configuration fails with a message similar to the following: err mcpd[5926]: 01071569:3: Ha group ha_group threshold for trunk _your_trunk_name_here_ 1 is greater than the maximum number of members 0." Workaround: "To allow the upgrade to succeed or the configuration to load, configure the HA trunk threshold to 0. Important! This disables the HA trunk feature." HA trunks with a threshold value greater than 0 are supported on vCMP guests.
596826 Don't set the mirroring address to a floating self IP address Accidentally setting the mirroring IP address to the floating self IP address using tmsh. Mirroring does not work in this case. If you configured it this way using tmsh, the GUI will show the primary and secondary mirroring address as "None". "Using tmsh, you can configure the mirroring IP address using the command tmsh modify cm device devicename mirror-secondary-ip ip_address It is possible to set ip_address to a floating self IP address when using tmsh, but BIG-IP can't mirror to a floating self IP address. The tmsh command will complete without error." Workaround: "Change the mirroring address to a non floating self IP address. The GUI will only present non floating self IP addresses. For more information about mirroring, see K13478: Overview of connection and persistence mirroring at https://support.f5.com/csp/#/article/K13478"
597253 HTTP::respond tcl command may incorrectly identify parameters as ifiles "HTTP::respond command making use of a variable as a header name. For instance: HTTP::respond 500 -version 1.1 content ""<content>"" ""$VariableHeaderName"" ""header_value_text"" ""Connection"" ""close"" Configure a HTTP/TCP virtual server and attach the iRule." 1070151:3: Rule [/Common/example_rule] error: Unable to find ifile (header_value_text) referenced at line 3: [HTTP::respond 500 -version 1.1 content "<content>" "$VariableHeaderName" "header_value_text" "Connection" "close"] The HTTP::respond iRule command may incorrectly identify parameters as an iFile parameter when attaching the iRule to a Virtual Server. Workaround: Ensure the offending header name and value are either both literal strings or variables. BigIP no longer incorrectly identifies parameters as an iFile parameter.
597951 Upgrade fails when MSSQL and IIOP profiles exist in bigip.conf. This occurs when an MSSQL or IIOP profile exists in the configuration. Configuration does not load after upgrading. "Beginning with this version of the software, the MSSQL and IIOP profiles are no longer supported. If you upgrade a configuration that contains a MSSQL and IIOP profile, the config load fails, and the system posts the following error message: emerg load_config_files: ""/usr/bin/tmsh -n -g load sys config partitions all"" - failed. -- 01020036:3: The requested profile (/Common/mssql) was not found. Unexpected Error: Loading configuration process failed." Workaround: Manually delete the profiles from bigip.conf and try the upgrade again.
600811 Starting in v12.1.1, the CATEGORY::lookup iRule command will no longer accept an HTTP URI in its argument to the command if the BIG-IP system has APM and URL Filtering provisioned or just URL Filtering provisioned along for SSL Bypass decisions. Only a valid hostname can be used and have its category returned. In versions prior to v12.1.1, the following iRule command was valid:

              when HTTP_REQUEST {
              set this_uri http://[HTTP::host][HTTP::uri]
              set reply [CATEGORY::lookup $this_uri]
              log local0. "Category lookup for $this_uri returns $reply"
              }

Starting in v12.1.1, using the previous example, you must remove the HTTP::uri statement. If an HTTP::uri is provided to the command, the system returns an error similar to the following: err tmm2[12601]: 01220001:3: TCL error: /Common/_1_categ_test <HTTP_REQUEST> - Categorization engine returned an error. invoked from within "CATEGORY::lookup $this_uri" Correcting the iRule for post-v12.1.1 installation, the example must be modified to pass in the HTTP::host only, as follows:

                when HTTP_REQUEST {
                set this_uri http://[HTTP::host]
                set reply [CATEGORY::lookup $this_uri]
                log local0. "Category lookup for $this_uri returns $reply"
                }

Note: If APM and SWG are licensed and provisioned, the CATEGORY::lookup iRule command will accept an HTTP URI as a part of the argument to the command. - BIG-IP licensed and provisioned for: o APM and URL Filtering o URL Filtering (used for SSL Bypass decisions in SSL Air-Gap deployments). - An iRule that supplies a URI path to the CATEGORY::lookup iRule command. - Upgrading from pre-v12.1.1 versions that use the CATEGORY::lookup iRule command and use an HTTP::uri or pass in a plain text string that contains anything other than an HTTP hostname. There is an error returned from the command. This can cause errors in existing deployments. Workaround: Update the iRule to only pass an HTTP hostname to the CATEGORY::lookup iRule command.
601420 Possible SAML authentication loop with IE and multi-domain SSO. APM is configured with SAML authentication and multi-domain SSO. Using Internet Explorer, the client may not be unable to connect to its desired destination. When APM is configured with SAML authentication and multi-domain SSO, Internet Explorer may encounter authentication loop and never complete the access policy. Workaround: Chrome and Firefox do not seem to be affected. Use cookie for session for multi-domain if TOKEN lookup fails. Previously, the cookie was ignored for multi-domain response URI. However, with the introduction of TOKEN based session lookup, this causes a failure if the client retries the request (since the TOKEN was consumed in the request prior to the retry).
606573 FTP traffic does not work through SNAT when configured without Virtual Server The BIG-IP system configured to allow FTP traffic through, and SNAT is configured without a virtual server. The BIG-IP system does not SNAT port 21 traffic. In rare circumstances this can cause tmm to restart. After upgrading to 12.1.0 or 12.1.1, FTP traffic no longer works correctly with SNAT, when SNAT is configured without a virtual server. Workaround: None. FTP traffic now works through SNAT when SNAT is configured without a virtual server.
621374 "abbrev" argument in "whereis" iRule returns nothing iRule relying on whereis abbrev is used. The whereis iRule command will not return the expected value. The iRule [whereis <ip|ldns> abbrev] does not return a value. Workaround:
624044 LTM Monitor custom recv/send/recv-disable parameters have backslash at the end may fail to load Any of the "recv", "send", or "recv-disable" parameters having a backslash at the end, and the configuration is saved. The new configuration fails upon reload. If LTM monitor configuration parameters have custom strings that end with backslash, the saved configuration will fail to load. Workaround: Do not end custom strings with backslashes. BIG-IP no longer allows custom strings to end with backslash. The system presents a validation error.
630430 IPsec ALG: Traffic may not go through IPsec tunnel if ipsec.lookupspi is disabled and default DAG is used This may occur on appliances when the IPsec ALG is used with default DAG and the sys db variable ipsec.lookupspi is disabled. Connections going through the IPsec tunnel may fail. The connection table and IPsec ALG profile stats may indicate that the IPsec tunnel has been established, but traffic may not be passing through it. Workaround: Ensure the db variable ipsec.lookupspi is enabled.
631369 Empty external data-groups fail to load Config references an empty or missing datagroup. Config fails to load. "Config will fail to load after upgrade or ucs restore with error regarding an empty or missing data group: 01070630:3: The requested data group file (/config/filestore/.stage_d/130_d/Common_d/data_group_d/:Common:empty_48650_1) was not found or empty)." Workaround: Remove references to empty or missing datagroups. You can now use an empty file as an external data-group, and it will simply behave as though it has 0 elements.
637811 Upgrade failure when Common Criteria Mode is enabled Common criteria mode is enabled (i.e., the db variable security.commoncriteria is set to true). Software cannot be updated using the Web UI. The install fails with no indication as to why. When the software is in "Common Criteria Mode", an upgrade via the Web UI is not possible, because the upgrade process automatically generates a UCS file, but Common Criteria requires that a password be supplied whenever a UCS is generated. The Web UI does not take this in to account, and never asks for a password for the UCS file. Workaround: Disable Common Criteria Mode before upgrade by setting the db variable security.commoncriteria to false.
638935 Monitor with send/receive string containing double-quote may cause upgrade to fail. Configuration where monitor string contains \" (backslash double-quote) but does not contain one of the following characters: ' (single quote), | (pipe), { (open brace), } (close brace), ; (semicolon), # (hashtag), literal newline, or literal space. Configuration fails to load. When you upgrade from an affected version, the config gets saved before moving to the new version, thus dropping the enclosing quotes and causing a load failure when booting into the new version. Workaround: Manually edit each string in the bigip.conf to include enclosing quotes in order to get the config to load the first time. "Configs load successfully after upgrade. Surrounding quotes, if missing, are added to strings in the bigip.conf file after upgrade. For example: \""service_status\"":\""on\"".+\""maintenance\"":\""off\"" in the recv, send recv-disable and username fields. Output of list ltm monitor and bigip.conf match. Reloading the same config via tmsh does not cause unintentional changes, such as losing a level of escape in monitor strings. If you have an escaped quote in your configuration, and are moving to a configuration with this the dependency of this fix, you cannot reload the configuration or the license which also reloads the configuration. Doing so, will cause the config load to fail."
643768 Invalid entries in SNMP allowed-address and SNMP community fields can cause upgrade failure. "This can happen when upgrading from a release older than 13.0.0, and there is an invalid entry in the SNMP allowed-address field or communities source field, such as: sys snmp { allowed-address { 1.0.0.0/2.0.0.0 ""1.1.1.1 2.2.2.2"" 3.3.3.3,4.4.4.4 } communities { /Common/test { community-name test source 1.0.0.0/foo } } }" Upgrade to 13.0.0 fails if the configuration contains these invalid values, due to input validation that was added in this version. "If there are invalid entries in the SNMP allowed-address field, or in the SNMP communities source field, upgrade to v13.0.0 fails to load the configuration on validation of the input, with this error signature: 01070911:3: The requested host (<host-ip-address>) is invalid for allow in snmpd (/Common/snmpd), Unexpected Error: Loading configuration process failed." Workaround: Remove the invalid entries from these 2 field types before doing an upgrade to 13.0.0. The fix removes the invalid entries from the configuration on upgrade automatically.
645203 Configuration load fails after upgrade when a SAML SSO config object is put in a sync-only device group When a SAML SSO config object or a Form-Based SSO config object is configured in a folder and that folder is in a Sync-Only device group. When upgrading with the existing configuration, the configuration load will fail. The configuration does not load. Configuration load fails after upgrading BIG-IP from a previous version. The system posts an error similar to the following: 01070734:3: Configuration error: Invalid Devicegroup Reference. The sso_config_saml (/Common/Auth/<object>) requires apm_log_config (/Common/sso-log-setting-Notice) to be syncd to the same devices Unexpected Error: Loading configuration process failed." Workaround:

              1. Disassociate the folder from Sync-Only device group using the following commands: tmsh modify sys folder <folder name> device-group none tmsh save sys config.
              2. Upgrade and verify config loads.
              3. Create log-setting in each folder.
                  root@(temp12)(cfg-sync In Sync (Sync Only))(/S1-green-P:Active)(/Common)(tmos)# cd <folder name>/
                  root@(temp12)(cfg-sync In Sync (Sync Only))(/S1-green-P:Active)(/Common/<folder name>)(tmos)# create apm
                      log-setting sso-log-setting-Notice { access add { general-log { log-level { access-control notice } publisher sys-sso-access-publisher } } }
              4. Repeat this step for each log level: Alert, Critical, Debug, Emergency, Error, Informational, Notice, Warning, and use the appropriate log level accordingly.
              5. Modify SSO log-settings to use log-setting created under the folder (<folder name>), according to their previous log level before upgrading. For example,
                      root@(temp12)(cfg-sync In Sync (Sync Only))(/S1-green-P:Active)(/Common)(tmos)# modify apm sso saml <folder name>/<sso object
                      name> apm-log-config <folder name>/sso-log-setting-Notice
              6. Associate Sync-Only device group SO1 to folder, as shown in the following example:
                      root@(temp12)(cfg-sync In Sync (Sync Only))(/S1-green-P:Active)(/Common)(tmos)# modify sys folder <folder name>/ device-group <DG name>
              7. Verify config load.

Configuration load now completes successfully after upgrade when a SAML SSO config object is put in a sync-only device group.
645206 Missing cipher suites in outgoing LDAP TLS ClientHello You have LDAP servers requiring SHA256 and SHA384 ciphers for LDAP/TLS authentication. Servers requiring SHA for LDAP/TLS authentication will no longer be able to authenticate. This could suddenly break LDAP auth if you are upgrading from version 11.x where SHA256 and SHA384 existed. BIG-IP drops all SHA256 and SHA384 ciphers in the advertised ciphers list in the Client Hello when initiating LDAP/TLS with a pool member (in the case of a monitor). The same behavior is also seen for BIG-IP system auth via LDAP or AD when TLS is used. Workaround: Configure LDAP servers not to be dependent on SHA256 and SHA384 ciphers. The BIG-IP system now supports SHA256 and SHA384 ciphers in the advertised ciphers list in the Client Hello when initiating LDAP/TLS with a pool member (in the case of a monitor). You also see the same behavior for the BIG-IP system auth by way of LDAP or AD when TLS is used.
649759 ssmtp RewriteDomain setting is set to the empty string. This applies when the 'sys outbound-smtp rewrite-domain' setting is unset. It is difficult to determine the originating device for system email. The ssmtp RewriteDomain setting is set to the empty string. Therefore, the From address in any email sent by the BIG-IP has an empty domain. Workaround: Set the 'sys outbound-smtp rewrite-domain' to the local hostname. The ssmtp RewriteDomain setting is no longer set to the empty string. If 'sys outbound-smtp rewrite-domain' is unset, no rewriting will occur and the From address will have the hostname as its domain.
652052 PEM:sessions iRule made the order of parameters strict Some parameters, for example, subscriber-id come before the parameter user-name. Configuration that was valid in earlier versions is not accepted in newer versions. This may result in the configuration failing to load during an upgrade and return an MCP validation error. "In the versions before 12.0, the order of parameters for ""PEM::SESSIONS"" rule was flexible. It was made strict because of the new validation infrastructure in 12.0. This breaks some existing iRules. The system will report a validation error such as: 01070151:3: Rule [/Common/test_irule] error: /Common/test_irule:2: error: [""invalid argument subscriber-type""][PEM::session create $ip subscriber-type e164 user-name $user imsi $imsi subscriber-id $callingstationid]" Workaround: Change the order of the parameters.
653930 Monitor with description containing backslash may fail to load. Monitor with description containing backslash. Configuration changes without human intervention. Potential load failure. When a monitor description contains a \ (backslash) character, the system adds another backslash for every save-load operation. After enough saves/loads, the description eventually hits the maximum length, causing an error message: '01020057:3: The string with more than 65535 characters cannot be stored in a message' upon loading the config. Workaround: Don't use backslashes in monitor descriptions.
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.
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. Fixed issue preventing GTM configurations from loading when non-Common partitioned items present.
673018 Parsed text violates expected format error encountered while upgrading or loading UCS "This can occur under the following conditions: -- When loading a configuration that contains iFiles. -- During an upgrade process, when the source-path for an iFile contain a URL with a space or other invalid URL character in it, for example: http://myfiles.com/get this file.txt." Configuration fails to load, and the system reports the following error: Parsed text violates expected format. "During a configuration roll-forward on an upgrade, the UCS load fails and reports the following error: Parsed text violates expected format." Workaround: "You can use either of the following workarounds: -- Modify the URL to the iFile to remove any spaces, and then reload the configuration. -- Use the HTTP specification for specifying spaces (and other characters) in URLs. For example, represent a space using the string %20 in the URL: http://myfiles.com/get%20this%20file.txt."
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% FastHTTP/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. 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. 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 fast L4 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:
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. 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. 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. 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."
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. "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 with an error similar to this in /var/ltm/log: 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""" Workaround: "Prior to the upgrade: 1. Note any virtual address route-advertisement settings that are ""selective"", ""any"", or ""all"". 2. Change all of these values to either ""enabled"" or ""disabled"" (note that this will change their route advertisement behavior temporarily). 3. Perform the upgrade. 4. Change the route advertisement settings back to their original values."
702792 Upgrade creates Server SSL profiles with invalid cipher strings Custom HTTPS monitors configured prior to an upgrade will 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 will not prevent the configuration from loading, but attempting to modify the existing SSL profile or create a new one with matching configuration will fail: 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, ""DEFAULT:+SHA:+3DES:+EDH"" instead of ""DEFAULT:+SHA:+3DES:+kEDH""."
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." Config loads without error after upgrade from v13.1.0.

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 K14381: HTTP Class iRule events and commands are 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.

ASM Logging Profile behavior in 12.1.0 and later

In 12.1.0 ASM logging profiles have changed from a single profile that can support remote and/or local logging to multiple profile support for profiles that are either remote, or local logging. No functionality is lost, however what was previously a single profile now becomes two profiles. This occurs when you upgrade from a pre-12.1.0 release to 12.1.0 or later, and there is an ASM logging profile exists in the configuration. In this case, logging profiles have changed from a single profile that can support remote and/or local logging to multiple profile support for profiles that are either remote OR local logging. No functionality is lost, however what was previously a single profile now becomes two profiles.

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 found here: https://wkhtmltopdf.org/

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

In version 13.1 the session-based and dynamic brute force protections are discontinued and replaced with source-based brute force protection. When upgrading:

  • Source-based mitigation will be set to Alarm and CAPTCHA for Username, Device IP and Source ID.
  • Dynamic mitigation will be set to Alarm and CAPTCHA.
  • Client Side Integrity Bypass Mitigation will be set to Alarm and CAPTCHA.
  • CAPTCHA Bypass Mitigation will be set to Alarm and CAPTCHA.
  • Detection and prevention duration will be derived from previous values.
  • Enforcement of both the source-based and distributed brute force protections depends on the Blocking settings of the Brute Force: Maximum login attempts are exceeded violation.
  • The Learning flag for Brute Force: Maximum login attempts are exceeded violation is discontinued.
  • The Unlimited value for Prevention Duration is discontinued.

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 Local Traffic > Profiles > Services > HTTP > Properties 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.

Important: Wait 5 minutes after you set the resource provisioning level before making any configuration changes to the Application Security Manager. 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.

Setting the Application Security Manager resource provisioning level to Nominal from the command line

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

Setting the Application Security Manager resource provisioning level to Nominal using the Configuration utility

You can set the Application Security Manager 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 Security (ASM) option to Nominal.
  3. Click Submit.
The screen refreshes, and the resource provisioning level of the Application Security Manager is set to Nominal.

To prevent traffic from bypassing the Application Security Manager

Please read 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 on the AskF5 web site. These articles contain important configuration information needed to prevent traffic from bypassing the Application Security Manager.

FPS 14.0.0 Upgrade and Compatibility Information

Upgrading to Fraud Protection Service (FPS) 14.0.0

  • When upgrading to FPS 14.0.0 from any BIG-IP version (13.0.0 and earlier) you should be aware of the following:
    1. The standard FPS Data Manipulation Check is disabled for URL parameters that are marked with both the attributes Substitute Value and Check Data Manipulation.
    2. The Route to Pool user-defined FPS rule has been deprecated and replaced with the Redirect to URL FPS rule, using the URL /changeme.
    3. Real Time Encryption is disabled on URLs using a custom encryption function.
    4. The settings for the location of the FPS Main JavaScript have moved from the profile level to the URL level. For profiles with more than one URL, these settings are applied on all URLs in the profile.
      Note: If upgrading from BIG-IP 12.1.2-hf1-BIG-IP 13.0 (but not including 13.0.0) and you enabled the antifraud.internalconfig.flag1 database variable to allow using multiple FPS JavaScript location settings for multiple URLs in a profile, when upgrading to BIG-IP 14.0.0 the first location settings in the list will applied to all URLs in the profile.
    5. The following Phishing Detection settings have moved from the profile level to the URL level:
      • Location of CSS Link Injection (previously called Inject CSS Link)
      • Location of Phishing Inline JavaScript and Image Injection (previously called Inject Phishing Inline JavaScript and Image)
      • Location of CSS Element Injection (previously called Inject CSS Element)

      For profiles with more than one URL, these settings are applied on all URLs in the profile.

    6. In FPS 14.0.0, a valid Fingerprint URL Location (called Fingerprint JavaScript Location in BIG 13.0.0 and earlier versions) is non-empty, starts with ‘/’, and ends with .html. When upgrading to FPS 14.0.0, any Fingerprint URL Location that differs from this syntax is changed to /changeme.html.
  • When upgrading to FPS 14.0.0 from BIG-IP 12.0.0 or 12.1.0, you should delete the mobile security alerts URL (typically /rstats) and the alert routing iRule on all mobile security profiles.

  • When upgrading to FPS 14.0.0 from BIG-IP 12.0.0 or 12.1.0, a user-defined malware type is automatically created by the system that contains the malware detection configuration from the previous BIG-IP version. The name of this malware type is general.

WebSafe Dashboard Compatibility

FPS 14.0.0 can be used with WebSafe Dashboard version 4.1 and later versions. Earlier versions of the WebSafe Dashboard are not compatible with FPS 14.0.0.

MobileSafe Compatibility

For Mobile Security users, FPS 14.0.0 should be used with MobileSafe SDK 2.0 or a later version, as all MobileSafe SDK versions prior to 2.0 are end-of-life.

About working with device groups

Note: This section is relevant only if you are 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.
  • Adding a device to a trust-domain that has another device which already has the datasync-global-dg device-group.
  • Upgrading to this version when ASM is already provisioned.
  • Upgrading to this version 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

When adding a device to the trust-domain, or when upgrading from a previous release, you must manually synchronize this device group.
  1. In the Configuration utility, navigate to Device Management > Overview .
  2. In the Device Groups area, click datasync-global-dg.
  3. In the Devices area, click the device which is chosen to have the master scripts and keys. These scripts and keys will be sent to the rest of the devices.
  4. Under Sync Options, select Sync Device to Group.
  5. Check Overwrite Configuration.
  6. Click Sync.
  7. When the warning message appears, click OK.
The device that you selected continues to work seamlessly. The rest of the devices go OFFLINE, and will not receive traffic for approximately 3 minutes. During this time, the new client-side scripts and keys are synchronized and prepared. After about 3 minutes, all units should return to the ONLINE (Active) state, and the units should be in sync.

Supported ICAP servers

For this version, 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: Security > Options > Application Security > Advanced Configuration > System Variables .)

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

AVR :: Merged metrics to HTTP statistics tables

Metrics used in select HTTP tables in versions 12.X and lower, were merged into additional HTTP tables in this version, resulting in default values immediately following the upgrade.

The following table lists the metrics, the tables they were merged into, and the initial values displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed value will appear as expected in the merged metric field in the additional HTTP tables.
Metric Title Applying Metric(s) in GUI Tables with Added Metric Initial Value After Upgrade Version Before Upgrade
sessions Average Sessions URLs, Pool Members, Response Codes, Client IP Addresses, User Agents, HTTP Method 0 12.X or lower
max_tps Max TPS User Agents, HTTP Method 0 12.X or lower
client_latency_hits Avg Page Load time, Sampled Transactions User Agents, HTTP Method 0 12.X or lower
max_client_latency Max Page Load Time User Agents, HTTP Method 0 12.X or lower
client_latency Avg Page Load time User Agents, HTTP Method 0 12.X or lower
max_server_latency Max Server Latency User Agents, HTTP Method 0 12.X or lower
min_server_latency Min Server Latency User Agents, HTTP Method MAX_INT 12.X or lower
server_latency Avg Server Latency User Agents, HTTP Method 0 12.X or lower
max_request_throughput Max Request Throughput User Agents, HTTP Method 0 12.X or lower
total_request_size Avg Request Throughput User Agents, HTTP Method 0 12.X or lower
max_response_throughput Max Response Throughput User Agents, HTTP Method 0 12.X or lower
total_response_size Avg Transaction Response size User Agents, HTTP Method 0 12.X or lower

AVR :: New and updated dimensions

Dimensions were added since previous versions, resulting in default values immediately following the upgrade.

The following table lists the new dimension titles and the initial values displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed values for each dimension will appear as expected.

Dimension Title Dimension Module Location in GUI Initial Value After Upgrade Version Before Upgrade
Behavioral Signatures HTTP Security > Reporting > DoS Aggregated 12.X or lower
Bot Defense Reasons HTTP Security > Reporting > DoS Aggregated 12.X or lower
Browser Names HTTP Statistics > Analytics > HTTP Aggregated 12.X or lower
OS Names HTTP Security > Reporting > DoS Statistics > Analytics > HTTP Aggregated 12.X or lower
Vectors Common Security > Reporting > DoS Aggregated 12.X or lower
Triggers Common Security > Reporting > DoS Aggregated 12.X or lower
Mitigations Common Security > Reporting > DoS Aggregated 12.X or lower
Activity Types Common Security > Reporting > DoS Regular Activity 12.X or lower
Destination Countries Network Security > Reporting > DoS Aggregated 13.X or lower
Destination IP Address Network Security > Reporting > DoS Aggregated 13.X or lower
Client Types HTTP Security > Reporting > DoS Aggregated 13.X or lower
Human Behavior Indications HTTP Security > Reporting > DoS Aggregated 13.X or lower
Application Versions HTTP Security > Reporting > DoS Aggregated 13.X or lower
Application Display Names HTTP Security > Reporting > DoS Aggregated 13.X or lower
Jail Break HTTP Security > Reporting > DoS Aggregated 13.X or lower
Emulation Modes HTTP Security > Reporting > DoS Aggregated 13.X or lower

AVR :: New and updated metrics

Metrics were added since previous versions, resulting in default values immediately following the upgrade.

The following table lists the new metrics and the initial value displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed value will appear as expected in the metric field.

Metric Title Applying Metric(s) in GUI Initial Value After Upgrade Version Before Upgrade
min_server_latency Min Server Latency MAX_INT 12.X or lower
server_hitcount Avg Server Latency, Avg Application Response Time, Avg Server Network Latency 0 12.X or lower
application_response_time Avg Application Response Time 0 12.X or lower
max_application_response_time Max Application Response Time 0 12.X or lower
min_application_response_time Min Application Response Time MAX_INT 12.X or lower
client_ttfb_hitcount Avg Client TTFB 0 12.X or lower
max_client_ttfb Max Client TTFB 0 12.X or lower
min_client_ttfb Min Client TTFB MAX_INT 12.X or lower
clientside_network_latency Avg Client Network Latency 0 12.X or lower
max_clientside_network_latency Max Client Network Latency 0 12.X or lower
min_clientside_network_latency Min Client Network Latency MAX_INT 12.X or lower
serverside_network_latency Avg Server Network Latency 0 12.X or lower
max_serverside_network_latency Max Server Network Latency 0 12.X or lower
min_serverside_network_latency Min Server Network Latency MAX_INT 12.X or lower
request_duration_hitcount Avg Request Duration 0 12.X or lower
max_request_duration Max Request Duration 0 12.X or lower
min_request_duration Min Request Duration MAX_INT 12.X or lower
response_duration_hitcount Avg Response Duration 0 12.X or lower
max_response_duration Max Response Duration 0 12.X or lower
min_response_duration Min Response Duration MAX_INT 12.X or lower

AVR :: Updated HTTP statistic tables

The HTTP statistics tables were updated in this version. When upgrading from version 12.X or lower, non-cumulative metrics of the affected dimensions may display slightly different values after the upgrade.

The following table lists the affected HTTP dimensions and the initial values displayed in the GUI following an upgrade from a previous version. Once new data is collected, the displayed value will appear as expected for the dimension.

Dimension Title Initial Value After Upgrade Version before Upgrade
DoS Profiles Aggregated 12.X or lower
Bot Signatures Aggregated 12.X or lower
Bot Signature categories Aggregated 12.X or lower
Countries N/A 12.X or lower

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
Email support@f5.com

Additional resources

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

F5 Support

https://f5.com/support :: Self-solve Options

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

https://support.f5.com/csp/home

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

https://f5.com/support/tools/ihealth

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

https://devcentral.f5.com/

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

https://interact.f5.com/F5-Preference-Center.html

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.

Legal notices

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.

Additional Comments (optional)