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) and Application Visibility and Reporting (AVR) 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 or AVR) should be provisioned together. On v14.x 8 GB of memory is the very bare minimum to get three modules provisioned; suitable for a lab environment or very light production traffic; especially with a memory intensive module such as AVR.
• 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.

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

HTTP/2 full-proxy support

You can now configure the BIG-IP system to operate as a full proxy for HTTP/2 traffic, providing HTTP/2 support for both client- and server-side web traffic. This HTTP/2 full-proxy architecture provides greater network efficiency by allowing the BIG-IP system to transport multiple simultaneous, bi-directional streams of messages between the client and server, using the BIG-IP system’s message routing framework.

Support for IP address and service port lists for a virtual server

With this release, you can specify multiple IP addresses and service ports with a virtual server, for either source or destination addresses and ports. In this way, you can apply the same set of policies and profiles to traffic originating from, or destined for, disparate IP addresses and ports. This can reduce the number of virtual servers required to manage traffic, leading to simplified cloud deployments.

IPv6 support for VXLAN multipoint tunnels and the OVSDB management component

The BIG-IP system now supports the deployment of VXLAN multipoint tunnels over an IPv6 network. Also, when configuring the BIG-IP system OVSDB component, you can now specify IPv6 addresses to connect to a controller cluster.

Configuration of the BIG-IP system as a lightweight SDN controller

With this release, you can configure a BIG-IP system to function as a lightweight SDN controller to define service function chains on a network. Using an iAppLX user interface, you can configure service chains that consist of multiple BIG-IP nodes providing functions such as a lightweight SDN controller, service classifier functions (SCFs), and service forwarder functions (SFFs). You can also configure BIG-IP or non-BIG-IP service functions (SFs) within the chain.

Enhancement to VLAN-based DAG behavior

The VLAN-based CMP hash function now provides well-defined disaggregator (DAG) behavior for uncommon protocols. The BIG-IP system now uses local and remote IP addresses and service ports to disaggregate uncommon protocols across TMMs.

System Availability Metric for Phone Home and Qkview

In this release, a new command allows a BIG-IP administrator to see how long the system has been available, unavailable, or in maintenance mode since the last upgrade or software install: tmsh show sys availability. This command is useful for customers who wish to see availability data across all their BIG-IP devices.

BBR Congestion Control

In this release, TCP profiles can now be customized to use BBR congestion control. You can configure congestion control using TMSH, iControl REST, iRules, and the user interface. For more information, see https://support.f5.com/csp/article/K29377715 or the BIG-IP System: Congestion Control guide

Diameter Retransmission

This release includes an enhancement to the existing Message Routing Framework (MRF) to retransmit selected request messages that do not receive an answer message within a configurable period of time.

Support for new SCTP parameters

The BIG-IP system now supports new Stream Control Transmission Protocol (SCTP) configurable parameters (Initial, Minimum, and Maximum Retransmission Timeout, and Delayed SACK Timeout) for the SCTP profile.

Non-SIP message pass-through in ALG mode

For this release, the MR SIP ALG mode can now transparently forward invalid protocol messages sent to the SIP Service port, which bypasses the ALG.

Network map with new capabilities

For this release, the Network map has a new framework. A new information pane displays details after selecting an object, and pushing a button takes you to the BIG-IP system UI, where you can configure the object you previously selected.

H.323 ALG iApp

This release includes an H.323 Application Level Gateway (ALG) iApp that scales to support up to 100M of traffic and support Polycom and Avaya H.323 phones.

ALG iRule tool kit

For this release, BIG-IP system users can now build their own Application Level Gateways (ALGs) from an ALG iRule tool kit. The tool kit comprises a new iRule event (SA_PICKED), and a new set of iRule commands, which support all CGNAT and AFM use cases, even if no address translation is required.

Remote 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 remotely using F5 iHealth. 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.

Support for network firewall rules on the management port

This release includes the ability to configure network firewall rules for the management port to ensure that only specified IP or web network addresses can access the management port. This feature is available only when BIG-IP Advanced Firewall Manager (AFM) is not licensed and provisioned. For more information, see BIG-IP System: Essentials.

SM2, SM3, and SM4 Cryptographic Algorithm support

F5 has added SM2, SM3, and SM4 Cryptographic Algorithm support for the Chinese market. The algorithms were independently developed by the China State Cryptography Administration, where SM2 is the public key algorithm, SM3 is the hash algorithm, and SM4 is the block cipher algorithm. SM2 is based on the Elliptic Curve Discrete Logarithm Problem (ECDLP).

Support for TLS 1.3 based on RFC8446 and required cipher suites

This release provides support for 1-RTT (Round Trip Time) and improve performance support for earlier released Curve25519 (BIG-IP 14.0.0) and now ChaCha20/Poly1305 (14.1.0). TLS 1.3 Cipher Suites are included in ‘DEFAULT’.

F5 Certificate Manager introduces remote CA support

BIG-IP 14.1.0.1 includes CA support for: Symantec/DigiCert and Comodo. You can now use your CA account to automate your F5 on-box management of certificates, which includes: create, update, renew/auto-renew, revoke, order status, and alerts.

Unified Anti-Bot Detection and Protection

The anti-bot features of DoS profiles, both bot signatures and proactive bot defense, and ASM policy web scraping are now united in a Bot Defense profile. Predefined Bot Defense profile templates enable quicker and easier defense configuration. A Bot Defense profile is now DoS profile and ASM policy agnostic. Rather, it is attached to a virtual server. Bot mitigation actions are defined per bot type and mitigation exceptions can be configured. A transparent mitigation mode is available for logging, but not mitigating, bot detection. Bot Defense is logged and reported. Bot Defense Profiles can be configured on Security :: Bot Defense : Bot Defense Profiles.

Microservices

A microservice can override the security policy Enforcement Mode and / or Learning and Blocking Settings for a defined unique identifier of Hostname + URL. Microservices can be configured on Security :: Application Security : Microservices.

Selective Security Live Software Updates

Running devices can receive scheduled and real time selective live updates of ASM attack signatures, bot signatures, browser challenges, server technologies and threat campaigns. Only automatically downloaded files are automatically installed. Manually downloaded files must be manually installed. A manually downloaded file will not be automatically installed at the scheduled install time. After attack signatures are updated, the system places newly added and updated signatures in staging if they match the criteria of signature sets associated with security policies with staging enabled. This feature is activated on System :: Software Management : Live Update. This upgrades and replaces the functionalities on Security :: Security Update :: Application Security :: Attack Signatures and Security :: Security Update :: Application Security :: Threat Campaigns which have been deprecated.

Accelerated Signature Enforcement

Accelerated attack signature detection and mitigation works at the speed of L4 DoS to handle very strong high rate DoS attacks. The traffic is evaluated before the connection is initiated to boost performance over L7 signature enforcement. This feature is activated in the Bad Actors Behavior / Signatures section of a DoS profile via Security :: DoS Protection : Protection Profiles.

API Protection

API calls originating from enterprise, partner, and consumer applications that access cloud and on-prem resources require strong authentication and identity mediation in the current federated identity environment. Access Policy Manager lets you configure an API protection proxy for securing API calls. Configuration is simplified using the Guided Configuration for API Protection, and by having the ability to import API definitions by specifying an industry standard OpenAPI spec file. An API Protection Proxy template is provided in the Guided Configuration ( Access > Guided Configuration ). You can also use the Access menus to implement API protection use cases.

Logon Credential Protection

Access Policy Manager together with a DataSafe profile protects logon credentials, such as username and password, from potential man-in-the-browser attacks (browser-based man-in-the-middle attacks). When you configure credential protection, credentials that users type on the login page are not visible in browser developer tools. To integrate DataSafe credential protection, Fraud Protection (FPS) needs to be provisioned. For an easy way to implement this protection, follow the steps and instructions in the Guided Configuration template for Credential Protection.

New Single Sign-On for OAuth Bearer

Single Sign-On now supports creating, signing, and sending a new Java Web Token (JWT) to the backend as an OAuth bearer token. An OAuth Bearer SSO can be configured as passthrough to use the JWT received from the client. It can also be configured to create, sign, and send a JWT to applications that require them.

Visibility and performance dashboard enhancements

The APM Dashboard was enhanced to provide better visibility into system performance and now includes enhanced real-time data, current connectivity sessions, Access sessions, SWG sessions, and per-request ending results.

Subsession Variables available

A Subsession Variable contains a numeric or string value that an action in a subroutine returns in a per-request policy. You use them to customize access rules or specify different outcomes based on their values. Subsession Variables are used within subroutines or outside subroutines in a per-request policy. For example, Subsession Variables can access the results of recently completed subroutines.

Request Variables available

A Request Variable is a type of perflow variable that allows a per-request policy to inspect the properties of requests such as URI, method, parameters, cookies, header, and so on. You can use Request Variables in Access control checks and make policy decisions based on properties of the request. For example, Request Variables are commonly used in OAuth scope checks.

Additional gating criteria

Gating criteria can now be specified using expressions in addition to perflow variables.

iRule support for SAML assertions and authentication requests

To simplify the customized representation of data, APM now supports using iRules to modify four SAML protocol messages. Following are the new events:

• ACCESS_SAML_AUTHN – authentication request
• ACCESS_SAML_ASSERTION – assertion
• ACCESS_SAML_SLO_REQ – single logout request
• ACCESS_SAML_SLO_RESP – single logout response

The new iRule events and commands allow editing of SAML messages including the removal of XML elements and attributes, the modification of existing ones, and the injection of custom elements.

Custom DoS Signatures

You can now create custom Network and DNS type DoS attack signatures, allowing you customize DoS signatures for unique traffic types and respond more quickly to next generation DoS / DDoS attacks.

Dynamic Signature Persistence

You can now persist Dynamic Signatures, allowing signatures deemed useful to remain permanently in the AFM system configuration.

Support for UUID Functionality

This release provides support for firewall rule UUIDs (Universally Unique Identifiers). To improve troubleshooting and system auditing, firewall rules can now be identified using a 32 character UUID. The AFM system can also report UUIDs in log messages, contributing to more efficient event monitoring and response.

Protocol Inspection Enhancements

Protocol inspection now continuously provides learning and staging suggestions. Protocol inspection also provides a new confidence level, between 0 and 100, indicating the completeness of information being used as a basis for inspection suggestions.

Network Address Translation Exclusions

The AFM NAT feature now allows you to exclude individual IP addresses from configured NAT IP address ranges.

Secure Zone Delegation

For this release, you can configure a BIG-IP DNSSEC zone to correctly delegate to a secure (signed) child zone.

Cipher configuration of the client and server side of iQuery connections

For this release, you can configure the SSL cipher list and TLS minimum version for iQuery connections.

Parameter configuration enhancements

Prior to BIG-IP 14.1, the BIG-IP would use either the GET or POST request methods assigned to parameters to obtain parameter data. In BIG-IP 14.1, the GET and POST methods are no longer assigned to parameters and instead the user now selects a Search In option to define where the BIG-IP searches for the parameter in the HTTP request (either Payload, Query String, or both). This search is performed on all types of HTTP methods.

Allowing logins after encryption failure

A new fail-close mechanism was added in BIG-IP 14.1 so that in a case where the BIG-IP system fails to decrypt a parameter, the system administrator can choose to either disable Application Level Encryption for the remainder of the user-session or keep Application Level Encryption enabled.

Additional Alerts for triggering a Rule on the profile

The following alerts have been added to the list of alerts that can trigger a “Rule” on the BIG-IP profile: Detection of disabled enter key, Detection of matched URL patterns, Detection of matched SRC patterns, Detection of malware's function names, Self-Bait External, Same Domain Script Validation, Xtreme RAT Detected, Deferred Execution Detected, and Self-Bait Inline.

Support for PEM-based service classifier functions

By provisioning BIG-IP Policy Enforcement Manager (PEM), you can configure the BIG-IP system to function as a service classifier function (SCF). As an SCF in a service function chain, the BIG-IP system can match a traffic flow to custom policies and steer the flow to an ordered set of service functions within the service chain.

Enhancements to BIG-IP PEM module

This release includes several enhancements to BIG-IP Policy Enforcement Manager (PEM) policy selection, including the addition of a Diameter profile type.

Improved Support for AWS Elastic Network Adapter

BIG-IP Virtual Edition (VE) now has a native DPDK driver for AWS ENA. Because of this, dataplane interfaces are no longer represented as 'ethN' (with Linux tools like ifconfig, ethconfig, and ip).

Support for DHCP with IPv6

BIG-IP VE now supports DHCP with IPv6 for management, and it's enabled by default.

Support for Intel QuickAssist Technology

F5 now supports compression and SSL acceleration utilizing Intel QuickAssist Technology (QAT).

Optimized drivers for Mellanox NICs

F5 now provides optimized drivers for high performance, SR-IOV-enabled Mellanox ConnectX-3/4/5 family of NIC’s, including support for multiple 100 Gb/s dual port cards.

No new features

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

Support for Alibaba Cloud

This release adds support for the international Alibaba cloud.

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

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.

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

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.

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.

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.

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.

Additional resources

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