Updated Date: 05/05/2026
New Features in BIG-IP Version 21.1.0
See the following articles for details of software lifecycle.
BIG-IP 21.1 introduces a new, faster way to upgrade BIG-IP software—the in‑place upgrade. Unlike the traditional full upgrade process that installs all RPMs into a new or existing software volume followed by a system reboot, the in‑place upgrade streamlines the experience by updating only the modified components directly within the active software volume.
Important:
This is not an in‑service upgrade.
Although the upgrade is faster, the device is still expected to be offline during the procedure to ensure safety and consistency.
Initially, only a carefully selected set of Engineering Hotfixes (EHFs) will support in‑place upgrade. The list will expand over time as the feature matures.
The following are the key benefits of an in-place upgrade:
-
Significantly faster upgrades
Only modified RPMs and their dependencies are installed, avoiding the full installation of the base version plus all EHF RPMs. -
Reduced maintenance windows
Since fewer components are being processed, the total downtime required for the upgrade is shortened. -
Focused component‑level updates
Each affected process is restarted individually in a proper order rather than triggering a full system reboot (unless required).
As part of this feature, Dry Run functionality is introduced. Dry run compares the image you select for upgrade with the version currently running on the active volume and determines whether the system supports:
- In‑place upgrade
- In‑place upgrade with reboot
- Full upgrade (reboot‑only)
Dry Run performs a set of compatibility checks to help you understand upgrade requirements and the scope of the change. Some checks apply only to in‑place upgrades, while others apply to both in‑place and full upgrade workflows.
For more information, refer to the In-place Upgrades section in BIG-IP New and Installation Release Notes.
BIG-IP 21.1 removes support for Node.js v0.12 and Node Inspector v0.12.10 to improve security and align with the platform roadmap. If you use iRules LX workspaces based on Node.js v0.12, you must update them to Node.js v6 to maintain functionality.
The node-inspector debugger is no longer supported. Node.js v6.3.0 and later include a built-in debugger based on Chrome DevTools, which replaces node-inspector. During the upgrade, affected workspaces are flagged, and log messages identify impacted configurations. Review and update your iRules LX workspaces before upgrading to avoid disruption.
BIG-IP 21.1 enhances the UCS-based migration workflow using the tmsh load sys ucs command with the platform-migrate option. A new validate option enables preview of configuration changes before loading a UCS archive, generating a JSON-formatted report and highlighting warnings for ignored objects and properties to help assess compatibility.
Full configuration migration capabilities were previously available in the F5 Journeys tool. These capabilities are now integrated into the platform-migrate workflow, which automatically handles platform-specific differences during UCS load.
The workflow also applies required adjustments for the target platform. These adjustments include removing unsupported trunks, STP settings, and other platform-dependent objects to help ensure successful migration to rSeries, VELOS, and BIG-IP VE. During validation, certain platform-dependent objects are not included in the JSON output but may still be processed during migration. These objects include interfaces, interface bundles, management IP and routes, and VLAN or trunk assignments. Management IP and DHCP settings on the destination system are preserved to prevent unintended overwrites.
BIG-IP 21.1 introduces the capability to change the primary administrator from the default “admin” account to an administrative user account of your choice using BIG-IP management interfaces, such as the Configuration utility (TMUI), TMSH, and iControl REST.
ACMEv2 protocol support in BIG-IP enables automated certificate management that aligns with modern security requirements and operational realities. Certificate lifespans are getting shorter across major certificate authorities. Automated certificate management is now essential, not just convenient.
BIG-IP now handles certificate provisioning, renewal, and deployment automatically, preventing the service disruptions and security risks associated with expired certificates.
The implementation supports ACMEv2-compliant CAs, not just Let’s Encrypt. This includes providers like ZeroSSL, DigiCert, Buypass, Google Trust Services, and SSL.com. Certificate Order Management provides direct API integration for all supported CAs.
This dual approach ensures flexibility in certificate management strategies while reducing the risk of downtime from expired certificates. Organizations gain operational efficiency, enhanced security, and compliance readiness through this essential capability.
BIG-IP 21.1 advances the ongoing platform modernization initiative by transitioning essential components from 32-bit to 64-bit (x86_64) architecture. This delivers improvements in scalability, memory utilization, and support for contemporary toolchains.
Key daemons such as mergeD have been converted to a 64-bit architecture. This conversion enables enhanced processing of TM stat tables by using expanded addressable memory. The restjavad component has been updated from Java 8 to Java 21, delivering improvements in garbage collection and memory management.
Support for the 64-bit architecture has been added to the TMSH libraries used by iControl services, enabling dependent components such as iControl REST (restjavad) and icrd_child to use a 64-bit address space and modern toolchains. To maintain compatibility with modules that have not yet been ported, both 32-bit and 64-bit TMSH libraries are supported.
This change applies only to internal iControl components and is transparent to end users, with no impact to TMSH CLI functionality or existing iControl REST and SOAP API clients.
The devmgmt_cpp_client control plane module has been migrated to a 64-bit architecture. This migration involved updates to build configurations, validation, and recursive dependencies. Hardcoded devfs paths were replaced with supported build macros to maintain architectural compliance.
These architectural updates introduce no functional changes and maintain full compatibility with existing configurations and client interactions. Comprehensive regression testing, including manual validation, BVT, and ATOM test suites, has verified system stability and backward compatibility.
OOM conditions occur because of application memory leaks or insufficient host memory configuration.
Enhanced OOM priority handling: To improve system stability during low-memory conditions, OOM priority handling for MCPd has been enhanced. MCPd now receives higher protection from termination by the kernel’s OOM killer to keep this critical system component available during memory pressure. These daemons restart with a 5-second delay to prevent continuous termination.
Impact of MCPd restarts: MCPd restarts disrupt system operation and interrupt the data path. They also affect other daemons and TMM, causing a temporary data path interruption.
For persistent OOM events: Increase host memory based on configuration objects in your system:
tmsh modify sys db provision.extramb value <value_in_MB>Example:
tmsh modify sys db provision.extramb value 4096 (for 4 GB)Automatic priority adjustment If MCPd consumes excessive memory and causes at least 10 consecutive OOM restarts of other processes within 2 minutes, the system automatically lowers MCPd’s priority. This allows the kernel to restart MCPd during the next OOM event, enabling recovery from potential memory leaks.
Rate-limiting capabilities are added to the TMOS iControl REST API, enhancing the security and responsiveness of the API.
The key features include:
- Configuring rate-limiting parameters through CLI commands and TMUI.
- Enforcing request limits per client on the /mgmt endpoint.
- Mitigating risks from unthrottled API usage and application-layer DoS attacks.
This initiative improves responsiveness to DoS attack scenarios by limiting iControl REST requests to the /mgmt endpoint based on configured rate limits.
You can use the following tmsh commands to modify the values of Request Rate Per Client, Maximum Concurrent Requests, and Error Response Code:
tmsh modify sys httpd api-ratelimit <value>
tmsh modify sys httpd api-requestlimit <value>
tmsh modify sys httpd api-ratelimit-errcode <value>For more information on the parameters and default values, refer to Rate-limiting iControl REST API Calls section in the BIG-IP System: Essentials Guide.
BigD has been enhanced to run as a multi-threaded daemon (single instance), enabling efficient monitoring of large-scale configurations. This update supports up to 15,000 control plane monitors, with each BigD thread distributing the monitor load equally while maintaining minimal CPU utilization. The tmctl commands for monitors will now display consolidated output reflecting the multi-threaded architecture related to monitor instances and statistics. This multi-thread enhancement increases scalability and monitoring efficiency without affecting existing configurations, ensuring seamless system stability and responsiveness.
Determining the number of threads The number of BigD threads is primarily determined based on the number of available vCPUs. The calculation method varies depending on the type of system:
Hyperthreaded use case: Since hyperthreaded (HT) cores operate at roughly 60% of the performance of a real core, BigD threads are allocated approximately 60% of the remaining half of the HT cores (assuming that TMM takes the other half).
Formula:
Number of BigD Threads = (Number of vCPUs × 6) ÷ 10
Normal use case: In a normal scenario (non-hyperthreaded), BigD threads are allocated slightly less than half the available cores.
Formula:
Number of BigD Threads = (Number of vCPUs ÷ 2) - 1
You can manually set the desired number of threads using the database variable bigd.numprocs. However, the number of threads a user can configure will be capped based on the number of available vCPUs, ensuring a balanced performance and effective resource utilization.
Note: By default, the value of bigd.numprocs is 0, indicating that the number of threads will be calculated automatically using the formula detailed above.
An initial version of the enhanced BIG-IP UI is introduced in this release. This version focuses on visual enhancements and minor usability improvements. The enhanced BIG-IP UI is disabled by default and can be accessed by selecting the New UI (Beta) option in Settings > Preferences. This is an early iteration, and the interface will continue to evolve in upcoming releases, with refinements driven by customer feedback wherever possible.
F5OS now supports cloud-init for BIG-IP tenant deployments on VELOS and rSeries platforms.
This release introduces support for configuring Round Robin DAG (RRDAG) on a per-protocol, per-port basis for BIG-IP tenants on VELOS and rSeries platforms.
The Q-in-Q feature is supported with F5OS 2.0.0 or later.
BIG-IP TMOS 21.x is not supported on iSeries and VIPRION platforms.
BIG-IP 21.1 introduces the following new features for LTM:
Introduced the MCP Persistence Profile that enables Large Language Model (LLM) AI systems to maintain stateful sessions with backend servers. It ensures seamless and consistent interaction by keeping the client connected to the same backend server throughout the session, even in environments with multiple servers. Once a connection is established, all subsequent requests from the client are routed to the same server, providing continuity and efficient session management.
TMM provides the client with a wrapped and encrypted Mcp-Session-ID value to ensure both session continuity and security.
BIG-IP 21.1 enhances TLS performance by adding hardware acceleration for X25519 key exchange using Intel QuickAssist Technology (QAT) on platforms equipped with QAT-capable hardware. X25519 is widely used in TLS 1.3 for forward secrecy, and offloading TLS handshake processing to QAT reduces CPU utilization and improves performance in high-traffic environments. The feature is enabled by default and applies to both ClientSSL and ServerSSL profiles. No configuration changes are required, and the system automatically falls back to software processing if hardware acceleration is unavailable.
The mergeD daemon, which integrates statistical data at defined intervals, has been converted from a 32-bit binary to a 64-bit binary on x86_64 platforms. The associated statsd component has also been converted to a 64-bit binary as part of the ongoing migration of BIG-IP system daemons from 32-bit to 64-bit architecture.
Memory usage for the mergeD and statsd daemons may increase moderately due to the 64-bit architecture, while disk usage changes are minimal. Although performance improvements were not the objective of this change, some improvements may be observed due to the 64-bit implementation.
BIG-IP now supports SecP256r1MLKEM768 and SecP384r1MLKEM1024 hybrid key exchanges in TLS for both client-side and server-side communications. These mechanisms combine the widely trusted SecP256r1 and SecP384r1 elliptic curve key exchanges with MLKEM768 and MLKEM1024, respectively, ensuring enhanced security and resilience against future quantum threats.
This release strengthens BIG-IP’s cryptographic flexibility, offering improved compatibility and robust protection for secure communications in both classical and post-quantum environments. Existing configurations remain unchanged. These new options deliver an additional layer of security where supported. This enhancement underscores BIG-IP’s commitment to advancing secure and modern application communications.
In-TMM health monitors (GATEWAY ICMP, TCP, HTTP/HTTPS) now support SNAT Pool as the source address for monitor probes. By default, monitors use self-IP addresses as the source; enabling SNAT Pool IPs allows monitor traffic to originate from public or customer-recognized IP addresses. This is critical for outbound VIP configurations where backend Pool members reside in customer networks that don’t route to private Self IP addresses. In HA deployments, only the active unit sends monitor probes and automatically syncs endpoint status to the standby unit.
BIG-IP 21.1 supports MAC-based health checks directly within its Traffic Management Microkernel (TMM) using Address Resolution Protocol (ARP). These health checks monitor devices at the MAC (Layer 2) level instead of relying on IP-based methods, allowing faster and more accurate validation of device availability.
BIG-IP 21.1 supports Client and Server SSL/TLS parent profiles with TLS 1.3 and DTLS 1.2 as Default settings, to balance security, compatibility, and performance, while retaining legacy client and server configurations to prevent disruptions to existing child profiles.
BIG-IP 21.1 provides the ability to control whether a nonce is included in OCSP requests during cert-LDAP authentication. By default, nonce usage remains enabled, preserving existing behavior and aligning with security best practices.
This enhancement provides greater flexibility for environments using legacy or non-compliant OCSP responders that may not properly handle nonce-enabled requests. Administrators can disable the nonce when required to improve compatibility and avoid authentication failures, while still adhering to security best practices by keeping nonce usage enabled by default.
Optimized OCSP handling in the BIG-IP UI by avoiding OCSP checks on every HTTP request, reducing unnecessary OCSP traffic, and improving authentication stability.
Example:
tmsh modify sys httpd ssl-ocsp-use-request-nonce off
C3D functionality now includes the ability to override the notBefore (valid-from) attribute of forged certificates. This enables you to dynamically set the certificate’s start time to match the exact time of certificate forging. The Override Certificate Start Date option is introduced on the Server SSL Profile page, providing greater flexibility for real-time traffic and compliance requirements. You can now cache forged client certificates, reducing the need to repeatedly generate them for similar transactions, thereby improving efficiency during high-traffic scenarios. This Cache Forged Certificate option is introduced on the Server SSL Profile page, enabling optimized traffic handling and reducing computational overhead in TLS proxy flows.
The SubjectDirectoryAttributes extension has been added to the list of available certificate extensions for forged certificates in C3D. This extension provides additional attributes about the certificate subject, such as geographic location, organizational attributes, or other metadata. You can now include SubjectDirectoryAttributes in dynamically forged certificates if required. This can be configured through the Server SSL Profile settings. You can now use the following iRules for C3D:
| Command | Description |
|---|---|
SSL::c3d cert_lifespan [1-8760] |
Overrides the profile’s configured C3D lifespan. |
SSL::c3d cert_start_date [override / original] |
If set with override: Overrides notBefore with the time of certificate forging. If set with original: Retains the notBefore value of the original client certificate irrespective of the profile configuration. |
SSL::c3d extension KU "digitalSignature, keyEncipherment" |
Injects KeyUsage constraints into the forged certificate. |
SSL::c3d extension EKU "serverAuth, clientAuth" |
Injects extendedKeyUsage constraints into the forged certificate. |
SSL::c3d extension SDA "dateOfBirth:20000101000000Z, countryOfCitizenship:US" |
Injects subjectDirectoryAttributes constraints into the forged certificate. |
BIG-IP 21.1 introduces the following new features for WAF:
Support for Web Application Firewall (WAF) inspection of HTTP/3 client-side traffic is now available. HTTP/3, built on QUIC (UDP), is increasingly adopted for modern web applications, and BIG-IP now extends WAF, Bot Defense, and L7 DoS protections to HTTP/3-enabled virtual servers.
Note: The underlying HTTP/3 implementation on BIG-IP LTM remains experimental. For details, see K60235402: Overview of the HTTP/3 protocol on BIG-IP.
BIG-IP Application Security Manager (ASM) supports OpenAPI Specification version 3.1 for API Security policy creation. OpenAPI 3.1 files can be imported using the existing workflow, with no changes to configuration or usage.
This release introduces MCP Protocol Protection, enabling WAF inspection and inline detection and blocking of Model Context Protocol (MCP) traffic to secure AI and agentic workflows. It includes a dedicated MCP policy template supporting prompt/tool injection detection, SSRF protection, sensitive data masking (Data Guard), JWT validation, and local or remote event logging.
The solution secures MCP integrations with minimal latency impact while allowing legitimate traffic. For streaming and SSE-based responses (text/event-stream), response-side inspection and logging are bypassed, and only request-side protections are applied. Guidance is provided for SSE-based applications, logging configuration, JWT setup, and signature tuning.
A new logging format, Splunk Key-Value Pairs – Extended, is introduced to enrich remote logs with additional violation context via an XML violation_details element. The existing Key-Value Pairs (Splunk) format is renamed to Splunk Key-Value Pairs – Basic. This enhancement improves visibility and analysis of security violations in Splunk.
Note: Configurations using the Extended format cannot be loaded on releases that do not support this logging option.
BIG-IP 21.1 introduces the following new features for APM:
Support for the HTTP Connector in per-session policies is now available in F5 BIG-IP Access Policy Manager (APM). This feature enables administrators to send HTTP requests to external services during session establishment and use the response for authentication, authorization, and access control decisions.
The documentation has been updated to reflect the current configuration model, including a clear separation between HTTP Connector Transport, Request, and Agent objects. Navigation paths and procedures have been refined to align with the BIG-IP UI and configuration workflow, making it easier to configure and integrate with external services such as custom authentication and authorization systems.
Support for modern ECMAScript versions has been enhanced in Portal Access within APM. Previously limited to ES6, the JavaScript rewriting engine now supports syntax and features up to ES13, improving compatibility with modern web applications. The update extends parsing, transformation, and runtime capabilities to handle newer language constructs while preserving backward compatibility. No changes to existing Portal Access configuration or rewrite profiles are required.
This enhancement enables modern applications using the latest ECMAScript features to function correctly without manual URL rewriting or troubleshooting. It reduces support cases, improves application reliability, and ensures seamless end-user access to contemporary applications through F5 BIG-IP Access Policy Manager.
This release adds support for OAuth 2.0 Dynamic Client Registration (RFC 7591). Administrators can enable DCR on OAuth profiles to allow authorized clients to dynamically register using an Initial Access Token (IAT). The feature includes support for the Client Credentials grant type, configurable client authentication settings, client secret expiration, and enhanced logging.
The Windows Edge Client now offers custom logging preferences, giving you enhanced control over log verbosity to improve both security and flexibility.
You can select the required log level from the APM Client Log Level drop-down in General Settings while creating a connectivity profile from Access > Connectivity / VPN > Connectivity > Profiles in BIG-IP. By default, it is set to Info.
Note: If the BIG-IP Server log level is set to ERROR, WARN, or INFO, it will override the Client Log Level. The APM Client Log Level is considered only when the BIG-IP Server log level is set to DEBUG or TRACE. If they differ, the lower log level (less verbose) is applied.
Important: The changes to ServerLogLevel are applied dynamically and do not require reinstalling the Edge Client. The updated settings will automatically reflect when the client connects to the APM Virtual Server with a connectivity profile that has the Custom Logging option enabled. However, the MachineLogLevel must be manually created in the Registry Editor if detailed debug-level logging is required on the client side. For more information, refer to APM Clients Documentation.
This feature requires the BIG-IP version 21.1 or later.
Previously, SAML authentication through default browsers in APM Clients on Windows was facilitated using iRules. However, this functionality is now natively implemented on BIG-IP, eliminating the need for iRules. This feature significantly improves user experience, simplifies maintainability, and improves overall supportability. Edge Client on macOS and Windows can use the system’s default browser to authenticate users with identity providers (IdPs). This enables modern authentication methods such as FIDO2 and Microsoft Entra ID device authentication.
To enable this feature, select the Enable System Browser checkbox in Desktop Client Settings while creating a connectivity profile from Access > Connectivity / VPN > Connectivity > Profiles in BIG-IP.
The Enable System Browser setting takes effect dynamically and does not require reinstallation of clients.
Added support for IPsec VPN tunnels in Access to enable the transition from SSL/TLS-VPNs to IPsec VPNs. Clients can now connect to BIG-IP over IPsec VPN using the BIG-IP Edge Client on Windows or F5 Access on macOS, and securely access the backend network.
A new field, VPN Type, is introduced in the Connectivity Profile screen. When you set it to IPsec, the system automatically generates an Access IPsec Policy.
You can modify the properties as per your requirement and update the policy.
The associated IPsec objects, IPsec Policy, IKE Peer, and Traffic Selector are created when you configure a Virtual Server with the IPsec VPN type connectivity profile.
Notes:
- When using LTM IPsec, the traffic intended for the Access Virtual Server may be incorrectly routed to the LTM IPsec forward virtual server. To avoid this, do not deploy LTM IPsec and Access IPsec simultaneously in the same environment and use separate VLANs for each use case.
- IPsec authentication supports only machine certificate authentication, requiring the machine certificate agent to be configured within the access policy. Without the configured machine certificate agent, IPsec will fail to establish a connection.
- The IPsec configurations are applied dynamically and do not require reinstallation of Windows Edge Client or F5 Access for macOS.
- You can convert an existing connectivity profile from SSL-VPN to IPsec by updating the VPN Profile type from SSL to IPsec in the Connectivity Profile. However, converting an existing connectivity profile from IPsec to SSL-VPN is not supported and requires new profile creation.
Windows Edge Client can now automatically upgrade the F5 Machine Tunnel Service when a newer version is available on BIG-IP, and the auto-upgrade feature is enabled. Additionally, if the Machine Tunnel service is running before the upgrade, it continues to run after the upgrade completes without affecting existing VPN configuration settings. This feature requires the Edge Client to be installed and successfully connected to the VPN at least once after installing the latest version of the client.
Endpoint Inspection is now supported on Ubuntu with ARM64, allowing seamless management and inspection of endpoints on Linux ARM64 platforms.
For detailed information on the additional system libraries required, refer to BIG-IP Edge Client for Linux: Additional System Libraries Required for F5 VPN and F5 Endpoint Inspector.
BIG-IP 21.1 introduces the following new features for DNS.
BIG-IP DNS now supports associating multiple Response Policy Zone (RPZ) feed zones (up to 65,535) with a single DNS cache. This enables integration of multiple policy sources such as regulatory feeds, third-party threat intelligence, and internally managed policies.