Release Notes : BIG-IP DNS (formerly GTM) and BIG-IP Link Controller 12.0.0

Applies To:

Show Versions Show Versions


  • 12.0.0
Release Notes
Original Publication Date: 05/27/2016 Updated Date: 04/18/2019


This release note documents the version 12.0.0 release of BIG-IP DNS (formerly Global Traffic Manager) and BIG-IP Link Controller. You can apply the software upgrade to systems running software versions 11.x.

Note: To upgrade 10.x GTM installations to BIG-IP DNS 12.0.0, you must first upgrade to software version 11.x. For more information, see SOL17158: Upgrading 10.x GTM installations to BIG-IP DNS 12.0.0, available on AskF5.


Platform support

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

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

These platforms support various licensable combinations of product modules. This section provides general guidelines for module support.

Most of the support guidelines relate to memory. The following list applies for all memory levels:

  • vCMP supported platforms
    • VIPRION B2100, B2150, B2250, B4200, B4300, B4340N
    • BIG-IP 5200v, 7200v, 10200v

Memory: 12 GB or more

All licensable module-combinations may be run on platforms with 12 GB or more of memory, and on VE and vCMP guests provisioned with 12 GB or more of memory. Note that this does not mean that all modules may be simultaneously provisioned on all platforms with 12 GB or more of memory. The BIG-IP license for the platform determines which combination of modules are available for provisioning.

Memory: 8 GB

The following guidelines apply to the BIG-IP 2000s, 2200s, 3900, 6900 platforms, to the VIPRION B4100 and B4100N platforms, and to VE guests configured with 8 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus does not fit in this category.)

  • No more than three modules should be provisioned together.
  • On the 2000s and 2200s, Application Acceleration Manager (AAM) can be provisioned with only one other module.
  • In the case of Access Policy Manager (APM) and SWG together, no module other than LTM may be provisioned, and LTM provisioning must be set to None.

Memory: Less than 8 GB and more than 4 GB

The following guidelines apply to platforms, and to VE and vCMP guests provisioned with less than 8 GB and more than 4 GB of memory. (A vCMP guest provisioned with 8 GB of memory has less than 8 GB of memory actually available and thus fits in this category.)

  • No more than three modules (not including AAM) should be provisioned together.
  • Application Acceleration Manager (AAM) cannot be provisioned with any other module; AAM can only be provisioned standalone.
  • Analytics (AVR) counts towards the two module-combination limit (for platforms with less than 6.25 GB of memory).

Memory: 4 GB or less

The following guidelines apply to the BIG-IP 1600 and 3600 platforms, and to VE and vCMP guests provisioned with 4 GB or less of memory.

  • No more than two modules may be configured together.
  • AAM should not be provisioned, except as Dedicated.
  • ASM can be provisioned with this amount of memory, but a sizing exercise should be performed to ensure that it does not hit capacity issues.

vCMP memory provisioning calculations

The amount of memory provisioned to a vCMP guest is calculated using the following formula: (platform_memory- 3 GB) x (cpus_assigned_to_guest/ total_cpus).

As an example, for the B2100 with two guests, provisioned memory calculates as: (16-3) x (2/4) ~= 6.5 GB.

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

Configuration utility browser support

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

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

BIG-IQ – BIG-IP Compatibility

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

User documentation for this release

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

New in 12.0.0

GTM name change to BIG-IP DNS

In this release, F5 has changed the name of Global Traffic Manager (GTM) to BIG-IP DNS to more fully convey the breadth of the product offering with its functionality. BIG-IP DNS reinforces our mission to solve DNS availability problems at hyperscale for fastest application responses. In addition, F5 secure DNS services mitigates malicious communications and enables highly available global applications across data centers and hybrid cloud. References to GTM are being replaced in all appropriate occurrences going forward. BIG-IP GTM v11.x and prior versions will remain with the previous name.

DNS DDoS Hardware Features

This release adds support for two new hardware based features; DNS cache and Protocol Validation. Shifting the most active part of a DNS cache to hardware results in faster query responses for cached items. This feature differs from the current DNS Cache because it holds both authoritative and non-authoritative responses. Protocol Validation in hardware will quickly drop any poorly formed requests in hardware to free up the CPU for other processing. These features are only available in B2250 blades for VIPRION 2x00 Chassis and are not supported with vCMP.

"Return Code on Failure" for GSLB Load Balancing Failures

This release provides support for specifying a return code (RCODE) to return in a response to the client when GSLB load balancing fails. If this feature is enabled, a response with the selected RCODE is returned to the client.

Additional Record Support

This release adds Global Server Load Balancing (GSLB) support for additional resource record types. BIG-IP DNS now supports Wide IPs of resource record types: MX, SRV, and NAPTR. By adding GSLB support for these new record types, BIG-IP DNS can now load balance queries whose responses contain content other than IP addresses. This allows GSLB for responses that are DNS names to other objects in the DNS hierarchy. This new record support is in addition to the already supported Wide IP record types: A, AAAA and CNAME.

Installation overview

This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference the information to ensure successful completion of the installation process.

Installation checklist

Before you begin:

  • Use BIG-IP iHealth to verify your configuration file. For more information, see SOL12878: Generating BIG-IP diagnostic data using the qkview utility.
  • Update/reactivate your system license, if needed, to ensure that you have a valid service check date.
  • Ensure that your system is running version 10.1.0 or later and is using the volumes formatting scheme.
  • Download the .iso file (if needed) from F5 Downloads to /shared/images on the source for the operation. (If you need to create this directory, use the exact name /shared/images.)
  • Configure a management port.
  • Set the console and system baud rate to 19200, if it is not already.
  • Log on as an administrator using the management port of the system you want to upgrade.
  • Boot into an installation location other than the target for the installation.
  • Save the user configuration set (UCS) in the /var/local/ucs directory on the source installation location, and copy the UCS file to a safe place on another device.
  • Log on to the standby unit, and only upgrade the active unit after the standby upgrade is satisfactory.
  • Turn off mirroring.
  • If you are running Application Acceleration Manager, set provisioning to Minimum.
  • If you are running Policy Enforcement Manager, set provisioning to Nominal.
  • If you are running Advanced Firewall Manager, set provisioning to Nominal.

Installing the software

You can install the software at the command line using the Traffic Management shell, tmsh, or in the browser-based Configuration utility using the Software Management screens, available in the System menu. Choose the installation method that best suits your environment.
Installation method Command
Install to existing volume, migrate source configuration to destination tmsh install sys software image [image name] volume [volume name]
Install from the browser-based Configuration utility Use the Software Management screens in a web browser.

Sample installation command

The following command installs version 11.2.0 to volume 3 of the main hard drive.

tmsh install sys software image BIGIP- volume HD1.3

Post-installation tasks

This document covers very basic steps for installing the software. You can find complete, step-by-step installation and upgrade instructions in BIG-IP Systems: Upgrading Software, and we strongly recommend that you reference the information to ensure successful completion of the installation process.

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

Installation tips

  • The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three minutes and seven minutes. During the upgrade process, you see messages posted on the screen. For example, you might see a prompt asking whether to upgrade the End User Diagnostics (EUD), depending on the version you have installed. To upgrade the EUD, type yes, otherwise, type no.
  • You can check the status of an active installation operation by running the command watch tmsh show sys software, which runs the show sys software command every two seconds. Pressing Ctrl + C stops the watch feature.
  • If installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.

Upgrading from earlier versions

Your upgrade process differs depending on the version of software you are currently running.

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

Upgrading from version 11.x

When you upgrade from version 11.x software, you use the Software Management screens in the Configuration utility to complete these steps. To open the Software Management screens, in the navigation pane of the Configuration utility, expand System, and click Software Management. For information about using the Software Management screens, see the online help.

Upgrading from versions earlier than 11.x

You cannot roll forward a configuration directly to this version from BIG-IP version 4.x, or from BIG-IP versions 9.0.x through 9.6.x, and any version 10.x software. You must be running version 11.x software. For details about upgrading to those versions, see the release notes for the associated release.

Automatic firmware upgrades

If this version includes new firmware for your specific hardware platform, after you install and activate this version, the system might reboot additional times to perform all necessary firmware upgrades.

Fixes in 12.0.0

ID Number Description
353556 Fixed, now when big3d fails to connect to the https web server it will clear the session entry from the session cache and initiate a new SSL negotiation.
372856 Can now add members with ? (question mark) in name when creating a BIG-IP DNS pool.
418128 iRule LB::Status now returns 'unset' on a BIG-IP DNS Pool Member if no load-balancing has occurred yet. This is correct behavior.
422107 Queries answered by DNS transparent cache will no longer add RRSIG to the response if DO bit is not set in the query.
428163 Deleting a cache resolver no longer results in outstanding packet issues.
446526 Non-datagram-LB mode and DNS iRule suspension no longer cause TMM crash.
452439 TMM will not crash when enabling DOS sweep/flood detection feature regardless of threading.
452443 DNS cache resolver or validating resolver now functions properly, successfully resolving DNS requests when using non-default cmp hashes configured on its egress VLANs.
455762 DNS Cache Statistics are no longer being incremented multiple times for the same action.
461334 Log message will show the root cause when DNS Express fails to answer a query.
463202 If the EDNS version is not zero, the query passes through the filter and is not dropped.
465951 An issue that caused gtmd to restart because of long descriptions has been fixed.
468503 The Update Check operation now reports the correct (installed) version of the IP geolocation database.
468519 Depends-on block is populated correctly with the virtual server info and no error was thrown when reloading BIG-IP DNS config.
471819 The big3d agent has been modified to run in a mode that eliminates inconsistencies with version 11.4.0 and earlier.
471856 Version 11.x TMSH and REST GTM Pool and Wide IP related commands are not supported in BIG-IP DNS version 12.x. The changes to iControl REST API and iRules commands are documented on DevCentral.
472081 BIG-IP DNS Monitor attributes (ignore-down-response, transparent, and reverse) are now properly inherited by their parent when the child monitor is initially created.
473139 BIG-IP DNS IMAP monitor now marks a working IMAP server up.
475680 "The 'add' and 'remove' commands for Wide IP iRules have been removed in tmsh, and the system presents an iRule list of 'none' or re-lists all iRules on a given Wide IP. The listed order of iRules on a given Wide IP implies the priority for these iRules. For example, to set Wide IP '' A-type Resource Record iRules rule_A, rule_B, and rule_C to have priorities 0, 2, 1, respectively, via tmsh: (tmos)# modify /gtm wideip a rules { rule_A, rule_C, rule_B }."
478812 With this fix, zone data is no longer vulnerable to corruption from power loss.
479084 ZoneRunner now uses the tmm0 interface to communicate with BIND.
479142 Deleting a virtual server now correctly deletes the resource record (RR) in ZoneRunner Daemon (ZRD).
485481 Corrected a print error in Load-Balancing Decision Log for QoS score.
487808 Link cost and inbound link path load balancing software support has reached EOL. For more information, see SOL15834: End of Life announcement for inbound and outbound cost-based link load balancing and inbound link path-based load balancing, available here:
490225 BIG-IP DNS/mcpd now checks for an existing key and does not import keys that already exist.
491554 big3d no longer leaks memory during auto-discovery failure events.
493673 Fields are properly not compressed, e.g., the NAPTR Replacement field.
494070 Now, a BIG-IP DNS Pool fallback IP address can be localhost.
494305 You can now use the GUI to remove the alphabetically first virtual server from the dependent list of virtual servers.
495311 Resolved build issues to install updated library and include files.
498334 TMM will correctly send a response message back when processing a zone notify message from a remote name server.
500639 Modifying the log level for ZoneRunner now changes the log level as expected.
503795 Debug logs are no longer displayed when log level is set to notice.
503979 The CPU usage does not increase unexpectedly when the cache resolver sends a large number of DNS queries to slow backend name servers.
506282 DNSSEC key generation is now synchronized upon key creation.
506423 The system now displays an explanatory failure message if the resource-record creation operation does not actually result in a creation.
507127 DNS cache resolver is added to the correct linklist on creation and removed from the correct linklist on deletion.
508486 Return status of queued TCP initialization messages allowing cleanup upon failure.
508716 DNS cache resolver no longer drops chunked TCP responses
510164 DNS Express zone RR type-count statistics are correctly set after restarting zxfrd.
510638 Config change in DNS cache resolver now take effect immediately and no longer require tmm restart.
510888 snmp_link monitor is now listed as available when creating link objects.
512016 There is now a DB variable to control DNS UDP truncation behavior: dns.udptruncate. When dns.udptruncate is enabled, UDP DNS responses are truncated if the response is larger than 512 bytes. When dns.udptruncate is disabled, the message is not truncated, and the full message is received. If the client specifies a non-default size via EDNS, the message is truncated if the response is larger than the specified size regardless of the value of dns.udptruncate.
513202 A DNS client will be properly filtered by the RPZ database.
514236 GUI now adds the partition prefix to device-name for BIG-IP DNS Server IP addresses, so IP addresses associated with a BIG-IP DNS server object are now viewable from the Configuration utility.
515030 Memory no longer leaks in zrd when performing multiple wide IP alias updating.
515797 qos_score command is disallowed in RULE_INIT event.
516680 ZoneRunner will no longer crash when parsing zone files containing $TTL directives, blank lines, comment-only lines, or some combination of the above.
516685 ZoneRunner now successfully loads zone files that contain $TTL directives, blank lines, comment-only lines, or some combination of the above.
517556 NS type added to NSEC3 type bitmap.
517582 Able to delete regions after failed deletion.
520405 A max-concurrent-queries configuration setting significantly above default no longer leads to a situation that causes tmm to restart in certain traffic loads.
524666 DNS licensed rate limits are now handled as expected.
526699 TMM no longer crashes when using an incorrect IP/Port in a nodes_up BIG-IP DNS iRule.
528739 The DNS Cache now correctly ignores data from the ADDITIONAL section when constructing the ANSWER section.
529460 BIG-IP DNS HTTP/1.x monitor probe now requires 17, rather than 64 bytes of response payload, so HTTP monitor responses HTTP response that is shorter than 64 bytes no longer incorrectly mark virtual servers down.
530761 Corrected system to properly handle the above combination of conditions.
532107 Maximum RTT value for nameserver cache is now deleted when the nameserver cache is deleted, which is correct behavior.
533658 DNS decision logging will no longer cause TMM to crash when a last resort pool is configured for a WIP, that last resort pool is unavailable, and a query is load balanced to that last resort pool.

Behavior changes in 12.0.0

ID Number Description
418128 When an iRule attempts to get the status of a BIG-IP DNS Pool Member prior to any Load-Balancing selections being made, it returns 'unset', instead of 'session_disabled' or 'down' when used in the LB_SELECTED event.
469020 Passing in the '-y' flag to the gtm_add command confirms that you want to overwrite the existing BIG-IP DNS configuration. If you do not include this flag, the system asks for this, and you must respond with 'Y' or 'N'. The '-y' flag enables you to bypass the question.
471856 Version 11.x TMSH and REST GTM Pool and Wide IP related commands are not supported in BIG-IP DNS version 12.x. The changes to iControl REST API and iRules commands are documented on DevCentral. This occurs because of the GSLB Additional Record Types feature in version 12.0.0. This feature adds query types to BIG-IP DNS Pools, Wide IPs, and related objects. That means that version 11.x TMSH and REST commands for GTM Pool, Wide IP, and related objects (Pool Members, Aliases, Wide IP Pools, Wide IP Rules, and so on) are not supported in version 12.x. The changes to iControl REST API and iRules commands are documented on DevCentral.
474024 "Zone states have been redefined as follows: - Unknown (blue) only on startup OR re-enable. - Available (green) only on successful transfer. - Unavailable (yellow) on successful db reload after a crash OR failed to connect to master server but not yet expired. - Offline (red) failed in the middle of a transfer OR zone expired. The zxfrd db dump is scheduled every time zone data changes (on transition to unknown, offline or available state)."
475680 "Previously, tmsh did not allow GTM Wide IP iRule priority modification, although iRule priority could still be set via iControl SOAP and the GUI. In this release, the 'add' and 'remove' commands for BIG-IP DNS (formerly GTM) Wide IP iRules have been removed in tmsh, and the system presents an iRule list of 'none' or re-lists all iRules on a given Wide IP. The listed order of iRules on a given Wide IP implies the priority for these iRules. For example, to set Wide IP '' A-type Resource Record iRules rule_A, rule_B, and rule_C to have priorities 0, 2, 1, respectively, via tmsh, use the following command: (tmos)# modify /gtm wideip a rules { rule_A, rule_C, rule_B }."
485104 There is now a WideIP option for WideIP-specific as well as Global settings for Return Code on Failure. When enabled, you can specify one of six different error codes (NOERROR (No Error), FORMERR (Query Format Error), SERVFAIL (Server Failure), NXDOMAIN (Non Existent Domain), NOTIMPL (Not Implemented), and REFUSED (Refuse to Answer)). You can view the updates in TMSH, and saving your sys config and loading your sys config shows the changes both in the configuration file, and in TMSH after loading the saved config.
501090 If you attempt to create a BIG-IP DNS Listener with a one-sided BIG-IP DNS Listener Profile context, the system automatically fills the other side of the context with the default profile for the given protocol (tcp or udp_gtm_dns). If you attempt to set one of those default profiles to be one-sided, the system automatically converts the Listener Profile to a two-sided context.
501287 Users with the Operator roles can now Enable and Disable Pools, Pool Members, and WideIPs.
502385 When a user with an Operator role types the command 'modify gtm <tab>', the result no longer lists the invalid options: distributed-app, prober-pool, and wideip. An Operator can only enable or disable pools.
512016 There is now a DB variable to control DNS UDP truncation behavior: dns.udptruncate. When dns.udptruncate is enabled, UDP DNS responses are truncated if the response is larger than 512 bytes. When dns.udptruncate is disabled, the message is not truncated, and the full message is received. If the client specifies a non-default size via EDNS, the message is truncated if the response is larger than the specified size regardless of the value of dns.udptruncate.

Known issues

ID Number Description
225759 Master key is not synchronized when you upgrade a BIG-IP Global Traffic Manager synchronization group to version 10.1.0 or later, The master key is not synchronized to all members within the synchronization group. For step-by-step instructions to fix this known issue, see SOL11868: The master key may not be synchronized after upgrading a BIG-IP GTM synchronization group, available here: Upgrading synchronization group to 10.1.0 or later. Workaround: After upgrading an existing sync group to dnssec, manually run fipssync and f5mku.
325318 If log level is set to info, the system logs in the zrd log RR add/delete changes. The system does not log which user performed the change, or any changes other than add/delete of RR. Audit logging for ZoneRunner. Workaround: None.
358268 The system allows you to specify a DNS64 Prefix of up to 128 bits (a full IPv6 address). However, a valid prefix is only the first 96 bits. The system uses only the first 96 bits. This occurs when specifying a DNS64 prefix. Workaround: if user enters 64:ff9b::1234:1234 and provides message that last 32 bits (last 2 hex tuples) must be all zeros. For example, 64:ff9b:0:0:0:0:0:0.
363134 [Link Controller] Links get auto-discovered when global Auto-Discovery is disabled and Link Discovery is on. Links get auto-discovered. This occurs when disabling Auto-Discovery in Link Controller. Workaround: Disabling Link Discovery is the only way to truly disable this option.
363142 [Link Controller] Global Auto-Discovery can be disabled while there is a link with the bigip_link monitor. Global Auto-Discovery stays disabled. This occurs when using the bigip_link monitor. Workaround: Do not disable global Auto-Discovery while having a link with bigip_link monitor.
370131 Pool members loaded from the UCS are not in the configuration. If there are objects dependent on them, this may prevent the GTM config from loading completely. GTM config loaded from the UCS might be overwritten and Pool Members might be lost from it. GTM and LTM are enabled, Autoconf Delay is very low, there are GTM autoconfigured pool members from LTM virtual servers, and subsequently a UCS is loaded. Workaround: bigstart stop gtmd during UCS load, or set the autoconf delay to be much higher than the time required to load the UCS.
411515 The editing of builtin objects is not compatible with incremental sync. Incremental sync does not work because the system cannot sync read-only/builtin objects. Editing of builtin objects and incremental sync. Note: It is not recommended to edit builtin objects; you should use inheritance when possible. For example, instead of editing a base profile you should create a new profile that inherits from the base profile using the defaults-from option; this profile can be synchronized over incremental sync. The same practice can be applied to monitors. For objects without inheritance (such as iApp templates) you must copy the builtin object into a new object. Workaround: To synchronize an edit to a builtin object you must temporarily enable the device group's full-load-on-sync option; this option can be disabled after synchronizing the changes.
421139 GTM not probing all accessible links, marking some in other data centers as down when they are up. Incorrect traffic re-direction, status reporting and synced GTM systems reporting different object statuses. GTM systems 1 and 2 exist in two data centers, each with a different link, but both GTM systems can access both links. If on GTM1 Big3d goes down, GTM2 flags the link associated with GTM1 as down instead of trying to probe it. Workaround: Create a new GTM data center that contains the unprobed link and the GTM system that is up.
425108 If you create or modify a GTM link in tmsh to include a monitor, and attempt to list the available monitors using tab completion, only monitors of type bigip-link or gateway-icmp are listed. If the user attempts to apply a transparent http, https, tcp, tcp-half-open, or udp monitor, to a link, it will not be listed by tab completion. This issue occurs when all of the following conditions are met: -- Custom transparent monitor. -- Monitor type is not Gateway ICMP. -- Use tab completion in tmsh to display all available custom transparent. Workaround: You can work around this issue when associating the monitor with a GTM link using the tmsh utility. To do so, you can manually type the name of a custom transparent monitor.
439979 "big3d uses SSL ticket extension, which caused problems with servers running old versions of OpenSSL. This causes the customer's webserver, that doesn't support this option, to fail with (alert 21, decryption failure)." GTM Object is incorrectly marked down. GTM HTTPs monitor connecting to a webserver that doesn't support RFC 4507/RFC 5077 Workaround: To work around this issue, you can write an external script that you can import to the BIG-IP GTM system, and then configure the system to use that script instead of the GTM HTTPS health monitor: For detailed information about how to work around this issue, see SOL15053: The BIG-IP GTM system may incorrectly mark a resource down when using the GTM HTTPS health monitor, available at
456047 When using the web user interface to add server IP addresses to an existing Global Server Load Balancing (GSLB) server, any existing server IP addresses that have an explicit link configured are lost. If a link goes down, everything on the link goes down, so it is possible that unexpected resources will go down, if the GTM servers or virtual servers lose their explicitly defined links. Preliminary testing suggests that when these explicit links are lost, GTM might auto-match the server IP addresses (or virtual servers) to a different link, and this link might be different from the one the user explicitly configured. This occurs after adding a new IP address to the server. This can be examined by using tmsh to list the server and its associated explicit link. Workaround: When configuring servers that are using explicit links, using tmsh (not the web UI) to edit the server properties, prevents explicit links from being erased.
464708 "DNS logging does not support Splunk format log. It failed to log the events, instead logging err msg: hostname=""XXXXXXXXXXXXX.XX"",errdefs_msgno=""01230140:3:""" DNS logging does not log Splunk format to HSL. DNS logging and Splunk format log. Workaround: None.
471467 gtmparse segfaults when loading wideip.conf with duplicate virtual server names, or whose names differ only by spaces. gtmparse segfaults during a wideip.conf load, causing GTM configuration load to fail. wideip.conf contains duplicate virtual server name definitions, or the virtual server names are unique only because of leading or trailing spaces. Workaround: Change virtual server definitions so that there are no duplicate named virtual servers. Note that adding only leading or trailing spaces does not result in a unique virtual server name.
474215 The period and colon characters in GTM virtual server names are converted to underscores ( _ ) after upgrading to version 11.x. Upgrading from version 10.x to version 11.x. Production monitoring when customer's production GTM systems are upgraded. Workaround: None.
475246 There may be cases where the Instances tab on a GTM monitor fails to list virtual servers which use the monitor. The user cannot rely on the instances tab to provide information about what a monitor is applied to. In the case where there are multiple monitors applied to a server, which are inherited by a virtual server. Workaround: None.
480795 [GTM] Move address from one HA redundant LTM to another could cause bigip monitor failure. Only one of the redundant LTM systems get probed. If the probed LTM is standby, it ignores the probe request. Available BIG-IP redundant LTM server is marked down; the monitor does not work, and all hosted virtual servers are marked down. BIG-IP redundant LTM server configuration with one address at 'Address List' and another at 'Peer Address List', one of the addresses is moved from another. Workaround: Delete the moved address and add it back, or delete the redundant server and re-create it.
486995 Objects that are dependent on a specific server name do not work as expected. For example, if the configuration contained a large number of objects (900 objects) based off one core GTM server, there is no way to rename an object if the GTM server is created with an incorrect name. Cannot rename GTM server object after creation. This occurs when creating a GTM object using an incorrect name. Workaround: A workaround for this situation is to directly modify the GTM configuration file, bigip_gtm.conf, doing a search and replace for old name with the new name. Perform the edits in a temporary file using a copy of the original. Once modified, You can replace the existing bigip_gtm.conf. Once replaced, run the command: 'tmsh load sys config gtm-only'. Important: This action causes the renamed server and its related pool members to become unavailable for the duration of one monitor interval.
487144 Customer may see the following critical error message showing that they can not locate the keys from the FIPS: "FIPS acceleration device failure: cannot locate key" SSL can not locate the key from the FIPS card, and SSL will not function properly. There is FIPS card in the BIG-IP and the key is retrieved. Workaround: None.
511865 GTM external monitor is not correctly synced in GTM sync group without device group. The GTM external monitor is not synced correctly and configuration fails on the peer GTM system. The system posts an error similar to the following: err iqsyncer[20361]: 011ae104:3: Gtm config sync result from local mcpd: result { result_code 17237778 result_message '01070712:3: Values (/Common/ specified for external monitor parameter (/Common/external_test 2 RUN_I=): foreign key index (to_file) do not point at an item that exists in the database.' } This occurs when the following conditions are met: 1. GTM systems exist in the same GTM sync group but not in the same device group. The GTM external monitor refers to non-default system file. Workaround: Configure both GTM systems in the same GTM sync group and the same device group.
516055 [GTM] Continuous Autoconfig scheduling write of wideip.conf happens when two LTM systems have two virtual servers configured with same IP:port. When issue occurs, the GTM gets unmanageable. No configuration is possible because wideip reload overwrites the new configuration. The wideip.conf file reloads repeatedly, reporting messages similar to the following: notice gtmd[3808]: 011ae040:5: Autoconfig scheduling write of wideip.conf after receiving update from: 1. Two LTM systems having two virtual servers configured with same IP:port. 2. The GTM system managing these two LTM systems has virtual server discovery set to 'Enabled. Workaround: None.
517609 When searching received data for bytes that are regex metacharacters such as $ (dollar sign), . (period), ? (question mark), etc., the search string typically requires backslash characters to escape these. Such escaped characters result in non-matching behavior in GTM monitors without warning in the GUI. The GUI also validates Perl (non-POSIX) character classes such as \d rather than [:digit:], but these Perl extensions do not search properly. If a GTM monitor's expression contains regex Perl extension character classes or escaped regex metacharacters, a member's status might be incorrectly labeled. Any running GTM monitor. Workaround: "When escaping a regular expression metacharacter, an \x5C can be entered as a substitute for a backslash. If searching for whitespace or digits, use [:space:] and [:digit:] rather than \s and \d. For example, searching for 'HTTP/ 1.1' in a GTM HTTP monitor, you can enter the search expression HTTP/ 1\x5C.1, which the regex compiler interprets as 'HTTP/ 1\.1', to search for the period character rather than interpreting the period ( . ) as the 'any non-null byte' metacharacter."
523198 DNS resolver multiplexing might cause unexpected behaviors, resulting in multiple error message: notice hud_msg_queue is full. TMM cores or connflows not expiring. System posts messages similar to the following: notice hud_msg_queue is full. This occurs with a DNS resolver configured. Workaround: None.
532859 ZRD could not be able to create reverse zones for zone types other than Master. Could not create reverse zones for types other than MASTER. Creating zone for ZRD with zone types other than Master. Workaround: None.
540576 When a BIG-IP is configured to display a banner at SSH login, big3d_install may be unable to update the big3d daemon on that device. big3d_install fails to install big3d on the target remote BIG-IP sshd banner enabled Workaround: "Disable the SSH banner: tmsh modify /sys sshd banner enabled"
540766 Cannot upgrade directly to 12.x from 10.x GTM. This is by design. Note: This is true if GTM was ever provisioned on the system, even if it is not currently provisioned. "Upgrade halts with an error message similar to the following: ERROR: UCS version(v10.2.4) is less than v11.0.0 and GTM module config exists. Upgrade not supported to v12.0.0 or greater versions - exiting installation. See Solution SOL17158. Operation aborted." This occurs when upgrading a version 10.x GTM configuration directly to 12.x BIG-IP DNS. Workaround: Upgrade 10.x GTM configurations to 11.x GTM, and then upgrade to 12.x BIG-IP DNS.

Contacting F5 Networks

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

For additional information, please visit

Additional resources

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

F5 Networks Technical Support

Free self-service tools give you 24x7 access to a wealth of knowledge and technical support. Whether it is providing quick answers to questions, training your staff, or handling entire implementations from design to deployment, F5 services teams are ready to ensure that you get the most from your F5 technology.


AskF5 is your storehouse for thousands of solutions to help you manage your F5 products more effectively. Whether you want to search the knowledge base periodically to research a solution, or you need the most recent news about your F5 products, AskF5 is your source.

F5 DevCentral

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

AskF5 TechNews

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

Legal notices