Updated Date: 03/25/2026
New Features in BIG-IP Version 21.0.0
See the following articles for details of software lifecycle.
BIG-IP 21.0.0 release introduces significant improvements to the BIG-IP control plane, including better scalability and support for large-scale configurations.
Following are the recommended control plane scaling guidelines for BIG-IP configurations:
BIGd Monitor Instances Count:
The BIGd monitor instances count should be limited to 5,000 instances or fewer. To determine the current monitor instance count,
- Use the following tmctl commands:
tmctl monitor_stattmctl monitor_instance_stat
- Alternatively, upload a qkview to iHealth and check the monitor instances count on the summary page.
If the monitor instances count exceeds 5,000, it is recommended to use In-TMM Monitors.
Important:
- Up to 25,000 In-TMM Monitors are supported.
- Allocate extraMB setting to 8GB for handling up to 25,000 monitors.
Recommended Total Object Limits:
- The total number of objects managed by the system is limited to 30,000 objects for LTM application.
- Specific object limits include:
- Virtual Servers (VS): ≤ 10,000
- Pools: ≤ 10,000
- Endpoints: ≤ 25,000
- Services: ≤ 25,000
- iRules: ≤ 1,000
- SNAT: ≤ 10,000
- In-TMM Monitors: ≤ 25,000
- BIGd Monitors: ≤ 5,000
Starting with the 21.0.0 release, some applications are running 64-bit binaries. As a result, there is an increase in the resident memory of these applications compared to its 32-bit architecture in the previous release version.
Before performing the upgrade, run the following command to verify available memory:
tmsh show sys memory
Check the “Other” free memory value.
- If the configuration contains fewer than 10,000 objects, the “Other” free memory must be at least 150 MB.
- If the configuration contains 10,000 or more objects, the “Other” free memory must be at least 250 MB.
If the required “Other” free memory is not available, run the following command to increase the extra memory:
tmsh modify sys db provision.extramb value <value_in_mb>
Increase the value by 150 MB or 250 MB, depending on the object count. This ensures that no process enters an Out-of-Memory (OOM) condition during the upgrade.
Previously, configuration changes were retained only after running save sys config. If the mcpd process restarted before the configuration was saved, the system reverted to the last stored configuration, resulting in potential loss of changes. With the introduction of configuration persistence, any committed changes now remain available even after an mcpd restart, improving reliability and reducing the need to reload configurations.
A new database variable has been introduced:
dbconfig.reset = false(default): Unsaved configuration changes persist across mcpd restarts.dbconfig.reset = true: The system reverts to the previous behavior, loading stored configurations from the conf files after restart. In this case, the unsaved configuration will be lost.
By default, this feature preserves unsaved changes across system restarts, streamlining workflows and preventing accidental configuration loss.
BIG-IP now uses a custom F5 CA bundle, instead of just Entrust CA, to communicate with F5 services, ensuring continued access to F5 services even after the Entrust CA certificate expiry in February 2026.
MCPD has been enhanced to support multithreaded request handling, removing the sequential bottleneck of the previous single-threaded design. With multithreading enabled:
-
Control-plane scalability is significantly improved.
-
Concurrent configuration and system requests (such as SNMP or state - tmstats queries) are processed concurrently by different MCPD worker threads, improving overall responsiveness.
-
Control-plane performance is much faster.
Worker threads are designed to handle query requests. Queries for small objects typically complete quickly, while queries for larger objects may result in temporary CPU spikes, which is expected. If worker threads consistently use more than 80% CPU for 1–2 minutes, and you expect more frequent read operations, or if query timeouts occur (such as SNMP requests timing out due to busy worker threads), then you should consider increasing the thread count to manage the load effectively.
Important:
- Before increasing the thread count, ensure that other CPUs in the system are free (low usage, less than 50%) using tools like top, pidstat, or mpstat.
- Increase the thread count gradually (by 1 at a time) to prevent oversaturating the system, allowing safe performance improvements.
Use the following command to configure the number of MCPD worker threads:
tmsh modify sys db mcpd.workerthreads value <number_of_worker_threads>
Notes:
- Adjustments are not done automatically within the MCPD process. External monitoring can provide a more holistic view of system health and allows for safe manual adjustments.
- By default, MCPd uses 1 worker thread for request handling, but it can be configured to use a range of 0 to 4 worker threads. Setting the value to 0 disables additional worker threads, causing MCPd to operate in single-threaded mode as in earlier releases.
- Simultaneous configuration create, update, and delete operations are not supported. These operations are processed sequentially.
- Only query and statistics requests are processed concurrently along with configuration create, update, and delete operations.
Starting with BIG-IP version 21.1, iRules LX will not support Node.js v0.12. If you have iRules LX workspaces that rely on Node.js v0.12, you need to update them to use Node.js v6 as an interim solution. This is a temporary measure until the platform adopts Rocky Linux, which will include a more recent version of Node.js.
BIG-IP version 21.0.0 introduces the following new features for LTM:
The Model Context Protocol (MCP) is introduced to enhance AI applications using large language models (LLMs) by addressing the gaps of built-in memory and real-time awareness. MCP acts as a structured bridge between the models and external systems, ensuring relevant context is managed and delivered effectively while enabling seamless integration with tools and data sources. This will enable AI systems to handle conversational context, perform real-time tasks, and provide more coherent and capable interactions to users.
Introduced default S3 profiles for TCP and Client SSL Protocols to optimize performance and simplify S3 workload deployments by providing pre-configured settings specifically tuned for S3 workflows, including enhanced buffer management, optimized congestion control, efficient SSL session handling, and high-throughput data transfer capabilities. These profiles enable seamless TLS offload, improve encrypted communication performance, and integrate as one-click default options within the LTM configuration, offering customers an intuitive, streamlined experience with reduced complexity while maximizing performance and scalability for S3 operations.
BIG-IP version 21.0.0 introduces the following new features for DNS:
Previously, APM locked client mode allowed a maximum of 10 exclusions, preventing administrators from adding more than 10 destinations. This limitation has now been removed, and the exclusion list can contain more than 10 entries.
The max claim data size is set to 8kb by default, but large claim size can lead to excessive memory consumption. You must allocate the right amount of memory dynamically as required based on claims configuration.
BIG-IP version 21.0.0 introduces the following new features for DNS:
A new database variable, DNS.DNS64NXDomainAsNoError, has been introduced to control how DNS64 handles AAAA NXDomain responses.When this variable is enabled, NXDomain errors are treated as NoError, and the system proceeds to issue an A query. When disabled (default), BIG-IP follows RFC 6147 behavior and immediately returns the NXDomain error to the client.
BIG-IP can now process and return Extended DNS Errors (EDE) received from upstream name servers when acting as a DNS forwarder.
This feature is disabled by default and can be enabled using the following DB variable:
sys db dns.forwardextendeddnserrorcode {
value "enable"
}To prevent DNS message truncation caused by overly long EDE text fields, the returned EDE text is limited to 64 bytes.