Applies To:
Show VersionsBIG-IP GTM
- 11.5.3
BIG-IP Link Controller
- 11.5.3
Summary:
This release note documents the version 11.5.3 release of BIG-IP Global Traffic Manager and BIG-IP Link Controller. You can apply the software upgrade to systems running software versions 10.1.0 (or later) or 11.x.
Contents:
- Platform support
- Configuration utility browser support
- User documentation for this release
- New in 11.5.3
- New in 11.5.2
- New in 11.5.1
- New in 11.5.0
- Installation overview
- Upgrading from earlier versions
- Fixes in 11.5.3
- Fixes in 11.5.2
- Fixes in 11.5.1
- Fixes in 11.5.0
- Behavior changes in 11.5.3
- Behavior changes in 11.5.2
- Behavior changes in 11.5.1
- Behavior changes in 11.5.0
- Known issues
- Contacting F5 Networks
- Legal notices
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 10000s, 10050s, 10055, 10200v, 10250v, 10255 | D113 |
VIPRION B2100 Blade | A109 |
VIPRION B2150 Blade | A113 |
VIPRION B2250 Blade | A112 |
VIPRION B4100, B4100N Blade | A100, A105 |
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.
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.
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
User documentation for this release
For a comprehensive list of documentation that is relevant to this release, refer to the BIG-IP GTM / VE 11.5.3 Documentation page.
New in 11.5.0
Global Traffic Menu Changes
In previous releases, in the Configuration utility of the BIG-IP Global Traffic Manager, the Global Traffic menu was a top-level menu on the Main tab. With this release, the Global Traffic menu has been changed to the GSLB menu and placed under the top-level DNS menu. The purpose of this change is to illustrate that global server load balancing is a subset of the DNS features that are available on the BIG-IP system. This is important, because F5 Networks will be offering expanded DNS features in the future.
DNS Zone Replaces DNS Express Zone
In previous releases, in the Configuration utility of the BIG-IP system, you could create a DNS Express zone to utilize the DNS Express engine. With this release, the DNS Express zone has been renamed to DNS zone, and the configuration options for this object have changed. This change allows you to use one zone object to manage multiple features for each zone. For example, you can create a DNS zone and configure it to use the DNS Express engine by selecting an authoritative DNS server from which the BIG-IP system receives zone transfers for the zone. Additionally, you can specify DNS nameservers that are zone transfer clients for the zone. Alternatively, you can create a DNS zone proxy using the DNS zone.
DNS Cache and DNS64
You can now create a DNS profile where the DNS Cache field is Enabled and a resolver DNS cache is associated with the profile and the DSN IPv6 to IPv4 is set Secondary or Immediate. With this configuration, if a AAAA record request does not return a response, then the system makes an A record request and rewrites the A record response to a AAAA record and sends the response to the client.
DNS Cache and Local Zones
With this release, you can add a local zone to a transparent, resolver, or validating resolver DNS cache. You do this when you want the BIG-IP system to resolve queries, for small local zones, with authoritative responses.
DNS Cache and Forward Zones
With this release, you can add a forward zone to resolver or validating resolver DNS cache. You do this when you want the BIG-IP system to forward DNS queries that match the forward zones to specific nameservers, which resolve the query when the cache does not contain a response.
GPRS Tunneling Protocol (GTP) Monitor
You can now add a GTP monitor to the BIG-IP GTM system configuration. This monitor operates over the UDP protocol and supports GTP protocol versions 1 and 2. It sends a GTP Echo Request to a target and requires a well-formed GTP Echo Reply before marking the target as Up.
DNS Express and NAPTR Queries
The DNS Express engine now returns A, AAAA, and SRV records in the Additional section of a DNS response in response to a NAPTR query.
New iRule Command: DNS::scrape
A new LTM DNS iRule command was added to the BIG-IP system in this release. You can use the DNS::scrape command in the DNS_REQUEST and DNS_RESPONSE events for a virtual server with an associated DNS profile. You can use this command to parse the information in a DNS message based on user supplied arguments.
DNS Express and Zone Transfers
In previous releases, you could perform a zone transfer from a DNS Server to the BIG-IP system. With this release, additionally, zones that are transferred into DNS Express can notify other secondary DNS servers using AXFR NOTIFY. The DNS Express engine also supports TSIG keys for zones.
Maximized Enterprise Application Delivery Value
To make it easier and more affordable to get the Software Defined Application Services capabilities all organizations need, F5 introduces three software bundle offerings: Good, Better, and Best.- Good
- Provides intelligent local traffic management for increased operational efficiency and peak network performance of applications.
- Better
- Good plus enhanced network security, global server load balancing, and advanced application delivery optimization.
- Best
- Better plus advanced access management and total application security. Delivers the ultimate in security, performance, and availability for your applications and network.
Installation overview
- Upgrade from 11.x configurations: BIG-IP Systems: Upgrading 11.x Software
- Upgrade from 10.x Active-Standby configurations: BIG-IP Systems: Upgrading Active-Standby Systems
- Upgrade from 10.x Active-Active configurations: BIG-IP Systems: Upgrading Active-Active Systems
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 (10.x - 11.x).
- 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
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-11.2.0.2446.0.iso volume HD1.3
Post-installation tasks
- Upgrade from 11.x configurations: BIG-IP Systems: Upgrading 11.x Software
- Upgrade from 10.x Active-Standby configurations: BIG-IP Systems: Upgrading Active-Standby Systems
- Upgrade from 10.x Active-Active configurations: BIG-IP Systems: Upgrading Active-Active Systems
- Ensure the system rebooted to the new installation location.
- Use BIG-IP iHealth to verify your configuration file. For more information, see SOL12878: Generating BIG-IP diagnostic data using the qkview utility (10.x - 11.x).
- Log on to the browser-based Configuration utility.
- Run the Setup utility.
- Provision the modules.
- Convert any bigpipe scripts to tmsh. (Version 11.x does not support the bigpipe utility.)
Installation tips
- The upgrade process installs the software on the inactive installation location that you specify. This process usually takes between three minutes and seven minutes. During the upgrade process, you see messages posted on the screen. For example, you might see a prompt asking whether to upgrade the End User Diagnostics (EUD), depending on the version you have installed. To upgrade the EUD, type yes, otherwise, type no.
- You can check the status of an active installation operation by running the command watch tmsh show sys software, which runs the show sys software command every two seconds. Pressing Ctrl + C stops the watch feature.
- If installation fails, you can view the log file. The system stores the installation log file as /var/log/liveinstall.log.
Upgrading from earlier versions
Your upgrade process differs depending on the version of software you are currently running.
Upgrading from version 10.1.0 (or later) or 11.x
When you upgrade from version 10.1.0 (or later) or 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 10.1.0
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. You must be running version 10.1.0 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 11.5.3
ID Number | Description |
---|---|
ID 420440 | Multi-line TXT records are no longer truncated. |
ID 428163 | Deleting a cache resolver no longer results in outstanding packet issues. |
ID 436468 | DNS cache resolver TCP current connection stats are now decremented properly. |
ID 468519 | Depends-on block is populated correctly with the VS info and no error was thrown when reloading gtm config. |
ID 479142 | Deleting a virtual server now correctly deletes the resource record (RR) in ZoneRunner Daemon (ZRD). |
ID 491554 | big3d releases some memory. |
ID 493673 | Fields are properly not compressed. e.g. the NAPTR Replacement field. |
ID 503979 | The CPU usage will not be overwhelmed when cache resolver is sending massive DNS queries to slow back end name servers. |
ID 506282 | DNSSEC key generation is now synchronized upon key creation. |
ID 508716 | DNS cache resolver no longer drops chunked TCP responses |
Fixes in 11.5.2
ID Number | Description |
---|---|
ID 442980 | All pool members returned now have their statistics increased. |
ID 473577 | GTMd now receives updated information about changes to WideIP Alias/topology configuration items. |
ID 473759 | Unrecognized DNS records no longer cause mcpd to core during a DNS cache query. |
ID 476599 | In this release, the system clears suspended iRules that have failed before executing new events. |
ID 476683 | DNS_RESPONSE events are now resumed after suspension. |
ID 473139 | GTM IMAP monitor now marks a working IMAP server up. |
ID 490225 | GTM/mcpd now checks for an existing key and does not import keys that already exist. |
Fixes in 11.5.1
ID Number | Description |
---|---|
446540 | TMM will no longer core/restart with this backtrace due to large DNS sub-cache sizes. Please note that it is still advised to restrict cache size to 10x the defaults to avoid TMM memory starvation issues. |
448846 | A crash bug related to HSM and memory exhaustion has been fixed. |
Fixes in 11.5.0
ID Number | Description |
---|---|
ID 391999 | [LB::server addr] will now return an empty object if there's no address and will no longer return previous address. |
ID 412112 | "GTM has in the past incorrectly added Self IPs that correspond to gateway pool members. GTM should only add these Self IPs if Link Discovery is enabled on the server. LC will always add these Self IPs. This bug corrects that behavior." |
ID 422698 | Since DHCP Relay servers are link local, we no longer attempt to send them to any GTMs. |
ID 423317 | Link status for GTM server and virtual server IPs should work properly now after a config load. |
ID 424997 | Big3d no longer restarts in certain circumstances when retrying a connection to mcpd, and no longer produces a segmentation fault. |
ID 425568 | This release contains a fix for the intermittent hang of SQL monitors when cached database connections are closed on the server. |
ID 429127 | Changes in the DNS Zone Files are now properly synchronized between peer GTM group members. |
ID 430200 | When an explicit link is changed by a user on a server or virtual server configuration, the updated links should apply immediately. |
ID 431157 | GTM will now correctly include all information necessary for the monitor to make the correct determination of status. |
ID 432541 | GTM topology longest match sorting now correctly orders wildcard and negated records above other types of topology records. |
ID 433358 | The Active member of the HA Link Controller pair will not display the correct stats and the will apply the correct traffic based limits. |
Behavior changes in 11.5.3
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
Behavior changes in 11.5.2
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
Behavior changes in 11.5.1
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
Behavior changes in 11.5.0
ID Number | Description |
---|---|
ID 415432 | "lsn-pool Inbound setting now has 3 possible values. DISABLED - no inbound connections can be established. EXPLICIT - Inbound connections may only be established (EIF supported) only when explicitly created by iRules or PCP AUTOMATIC - EIF is enabled for all LSN connections. This is the same behavior as ""Enabled"" in 11.4.0 and 11.3.0." |
ID 417956 | "For CGNAT NAT64 inbound connection, the inbound packet's source IPv6 address will be an RFC6052 mapped address using the 96 bit prefix associated with the virtual server for the subscriber's NAT session. In order for this to work, the virtual server should have a destination prefix that could then be used to correctly apply the IPv4-in-IPv6 address mapping. If the destination network is a wildcard, 0::0 then the mapped address will be prefixed by all 0's. The Self-IP will only be used as the source address in the case of global SNAT." |
ID 423663 | There is now a command to list the PCP filters in the LSN database. Running the command 'lsndb list filters' displays the LSN Inbound mappings. |
ID 423701 | There is now a BIGDB variable called tm.lsn.dnat_suppress_logs_period that controls the initial interval time in seconds in which DNAT logs are suppressed to avoid flooding the log when blades are inserted and removed. Its default value is 300 seconds (5 minutes); and it can go down to zero; in which case no logs will be suppressed. |
ID 425505 | User can no longer associate virtual server with source prefix length of 0, with a lsn-pool in deterministic NAT mode. It is not a functional configuration, translation with source prefix length of 0 will use backup member pool if available, fail otherwise. |
ID 427255 | A global snat used to apply to LSN inbound connections. LSN inbound connections are now always transparent and never snatted. |
Known issues
ID Number | Description |
---|---|
ID 222220 | Distributed application statistics shows only requests passed to its first wide IP. Using Distributed application statistics and multiple wide-IP-members. The system does not include statistics for requests passed to other wide-IP-members of the distributed application. Workaround: |
ID 225759 | Master key is not synchronized when you upgrade a BIG-IP Global Traffic Manager synchronization group to version 10.1.0 or later, Upgrading synchronization group to 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: https://support.f5.com/kb/en-us/solutions/public/11000/800/sol11868. Workaround: After upgrading an existing sync group to dnssec, manually run fipssync and f5mku. |
ID 325318 | If log level is set to info, the system logs in the zrd log RR add/delete changes. Audit logging for ZoneRunner. The system does not log which user performed the change, or any changes other than add/delete of RR. Workaround: |
ID 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. This occurs when specifying a DNS64 prefix. The system uses only the first 96 bits. 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. |
ID 361650 | Starting with 11.0.0, it takes minimum of 15 seconds to a maximum of 60 seconds for BIG-IP GTM to save any configuration change, This occurs regardless of whether a configuration change is made in the Configuration utility or by using tmsh. This can have a 15-to-60-second delay when attempting to reload the GTM configuration immediately after a change operation. Workaround: To speed up this process, you can run the following command in tmsh: save sys config partitions all gtm-only. No equivalent of this command exists in the Configuration utility. |
ID 363134 | [Link Controller] Links get auto-discovered when global Auto-Discovery is disabled and Link Discovery is on. This occurs when disabling Auto-Discovery in Link Controller. Links get auto-discovered. Workaround: Disabling Link Discovery is the only way to truly disable this option. |
ID 363142 | [Link Controller] Global Auto-Discovery can be disabled while there is a link with the bigip_link monitor. This occurs when using the bigip_link monitor. Global Auto-Discovery stays disabled. Workaround: Do not disable global Auto-Discovery while having a link with bigip_link monitor. |
ID 367459 | The BIG-IP Configuration utility might incorrectly allow you to assign certain health monitors to pools and server objects that are configured with a wildcard service port. This occurs when using a wildcard service port. The BIG-IP system fails to pass traffic due to the configuration failing to load. GTM sync group members may fail to answer wide IP requests. For more information, see SOL12400: The BIG-IP Configuration utility may incorrectly enable you to assign certain health monitors to pools and server objects that are configured with a wildcard service port, available here: http://support.f5.com/kb/en-us/solutions/public/12000/400/sol12400.html. Workaround: There is no workaround for this issue. However, you can avoid this issue by assigning the pool health monitor before assigning a member-specific monitor to each pool member. The pool monitor assignment configuration validates and prevents the system from assigning an inappropriate health monitor to a wildcard destination service. |
ID 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 and LTM are enabled, Autoconf Delay is very low, there are GTM autoconf'd pool members from LTM virtuals and subsequently a UCS is loaded. GTM config loaded from the UCS can be overwritten and Pool Members can be lost from it. Workaround: bigstart stop gtmd during UCS load, or set the autoconf delay to be much higher than the time required to load the UCS. |
ID 385229 | In GTM iRules IP::addr incorrectly always returns FALSE when comparing addresses with different masks. Using IP::addr GTM iRules. IP::addr incorrectly returns FALSE. Workaround: To work around this, ensure the addresses have the same mask when using IP::addr to compare addresses. |
ID 401620 | In previous releases, monitored BIG-IP virtual servers with addresses that overlap non-floating self IP addresses used to be marked up when the gateway_icmp monitor was used, but other, port-specific protocol monitors would fail. This was a false positive, as it is not possible to monitor virtual servers that overlap these addresses from the same box. In this release, gateway_icmp monitor marks a virtual server that overlaps an IPv6 self IP as down, but it marks a virtual server that overlaps an IPv4 self IP as up. The latter is still an issue. BIG-IP virtual servers with addresses that overlap non-floating self IP addresses. In this release, gateway_icmp monitor marks a virtual server that overlaps an IPv6 self IP as down, but it marks a virtual server that overlaps an IPv4 self IP as up. The latter is still an issue. Workaround: To work around this issue, use the bigip monitor for monitoring BIG-IP virtual servers with IP addresses that overlap non-floating self IP addresses. Do not use any other GTM monitors for monitoring those virtual servers. |
ID 408504 | The output of 'tmsh show gtm iquery' shows 'Configuration Time' FOR SELF with an unexpected value of '12/31/69 16:00:00,' although the output shows the PEER 'Configuration Time' with expected values. This occurs when GTM systems are configured for address translation, but the self IP addresses are not configured correctly: for example, server ( Address: 1.1.1.1, Translation: 10.20.0.1). Because this configuration specifies only 10.20.0.1 as the self IP address, the command does not show the expected 'Configuration Time' value because there is no way the system can determine that 1.1.1.1 is the system configured with the 10.20.0.1 self IP address. Running the command 'tmsh show gtm iquery' shows the value of 'Configuration Time' FOR SELF as '12/31/69 16:00:00'. Although the value might be unexpected, the command is working as designed. Workaround: The correct configuration is to set both 1.1.1.1 and 10.20.0.1 as self IP addresses. After correctly setting the self IP addresses, the command shows 'Configuration Time' for servers with IP translation enabled, as expected. As an alternative to configuring the self IP addresses, if you remove translation from the GTM server objects, the BIG-IP system shows 'Configuration Time' with the expected values. |
ID 411515 | The editing of builtin objects is not compatible with incremental sync. 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. Incremental sync does not work because the system cannot sync read-only/builtin objects. 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. |
ID 421139 | GTM not probing all accessible links, marking some in other data centers as down when they are up. 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. Incorrect traffic re-direction, status reporting and synced GTM systems reporting different object statuses. Workaround: Create a new GTM data center that contains the unprobed link and the GTM system that is up. |
ID 421139 | GTM not probing all accessible links, marking some in other data centers as down when they are up. 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. Incorrect traffic re-direction, status reporting and synced GTM systems reporting different object statuses. Workaround: Create a new GTM data center that contains the unprobed link and the GTM system that is up. |
ID 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. 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. 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. 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. |
ID 437025 | "While processing very large configs, the mcpd process does not respond to queries from the big3d process. This causes big3d to retry queries too often and re-use timer IDs incorrectly. This incorrect use of timer IDs results in a SIGABRT error." A large configuration file. For example, larger than 10MB. big3d core errors Workaround: |
ID 438081 | If there are many zones (e.g. 1800) a stats request for all zone stats will produce a reply message too large to be sent in one attempt. zxfrd will stall on a second attempt to send and subsequent stats requests/responses will be blocked. Config with many dns-express zones. Attempt access through the web interface (however, tmsh works). Web interface appears to hang waiting for zxfrd to reply. Workaround: Only view zone stats through tmsh. Otherwise, if stats are hung, perform a 'bigstart restart zxfrd'. |
ID 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 HTTPs monitor connecting to a webserver that doesn't support RFC 4507/RFC 5077 GTM Object is incorrectly marked down. 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 http://support.f5.com/kb/en-us/solutions/public/15000/000/sol15053.html. |
ID 442135 | If you disable, then enable synchronization within 10 seconds, synchronization becomes disabled for all systems except one in a sync group. In a box of a sync group, The synchronization of the device group will be accidentally disabled. Workaround: After disabling synchronization on a system in a sync group, if you want to add it back, do so within 5 seconds or wait 15 seconds. For more information, see SOL15467: The BIG-IP GTM Synchronization option may stay in the disabled state after being re-enabled, available here https://support.f5.com/kb/en-us/solutions/public/15000/400/sol15467.html. |
ID 442226 | Link Controller will create a data center, but fails to create a GTM server for itself. Any LTM virtual servers configured will not show up as members in the Wide IP configuration. Always Users must manually create and maintain the GTM server Workaround: "Use tmsh to create a GTM server: Standalone: create gtm server <self host name> datacenter Default_DC addresses add { 10.20.0.1 { device-name <self host name> } } virtual-server-discovery enabled product single-bigip Redundant: create gtm server <self host name> datacenter Default_DC addresses add { 10.20.0.1 { device-name <self host name> } 10.20.0.2 { device-name <peer host name>} } virtual-server-discovery enabled product redundant-bigip" |
ID 442980 | With max_addresses_returned greater than 1, multiple addresses are returned, but only the pool member associated with the first address gets stats increased. Set max_addresses_returned greater than 1 Pool stats do not show the update when pool members are selected as alternate addresses. Workaround: |
ID 442980 | With max_addresses_returned greater than 1, multiple addresses are returned, but only the pool member associated with the first address gets stats increased. Set max_addresses_returned greater than 1 Pool stats do not show the update when pool members are selected as alternate addresses. Workaround: |
ID 442980 | With max_addresses_returned greater than 1, multiple addresses are returned, but only the pool member associated with the first address gets stats increased. Set max_addresses_returned greater than 1 Pool stats do not show the update when pool members are selected as alternate addresses. Workaround: |
ID 442980 | With max_addresses_returned greater than 1, multiple addresses are returned, but only the pool member associated with the first address gets stats increased. Set max_addresses_returned greater than 1 Pool stats do not show the update when pool members are selected as alternate addresses. Workaround: |
ID 446526 | When a UDP virtual server without datagram-LB mode enabled runs an iRule which suspends itself, AND the traffic that virtual server is handling is destined for the DNS cache, subsequent responses attempting to execute an iRule will crash TMM because the first response is suspended. Those subsequent responses should be queued before attempting to execute the iRule. UDP virtual server without DG-LB mode enabled running DNS cache. TMM crash. Workaround: Enable datagram LB mode on the UDP profile. |
ID 446820 | TMM may crash while running DNSSEC due to a poorly formatted log call. This occurs when running DNSSEC with tmm.verbose enabled. TMM restarts. Workaround: None. |
ID 446820 | TMM may crash while running DNSSEC due to a poorly formatted log call. This occurs when running DNSSEC with tmm.verbose enabled. TMM restarts. Workaround: None. |
ID 448327 | Aborted connections with suspended DNS iRule may leak memory. libldns memory tag in umem grows indefinitely eventually leading to failover. DNS_RESPONSE/DNS_REQUEST with iRule command which suspends and gets the connection aborted (e.g. RESOLV::lookup) because it exceeded the expire timeout for an iRule. Memory leak (libldns variable in tmm memory_usage_stat) Workaround: Avoid iRule command(s) which suspend in a DNS_REQUEST or DNS_RESPONSE iRule event. |
ID 452439 | There is a bug caused by race condition in the library used by the AFM Sweep/flood feature. When the Sweep/flood feature is enabled, if one TMM process has multiple threads, one thread may attempt to access the memory released by another thread at some time. In this situation, TMM may crash due to access an invalid memory segment. "(1) AFM sweep/flood enabled (2) A single TMM process has multiple threads. (3) race condition occurs" TMM crash, site at risk Workaround: Disable thread or disable sweep/flood |
ID 452889 | "GTM might return data from disabled pools for requests and server update stats. For example. under Global Traffic :: Servers : Statistics, you might see the following: 3) Throughput (bits/sec) In. 4) Throughput (bits/sec) Out. 5) Throughput (packets/sec) In. 6) Throughput (packets/sec) Out." This occurs when you enable the Global GTM setting for Monitor Disabled Objects under GUI: System :: System :: Configuration :: Global Traffic :: General : Monitor Disabled Objects. The alive connections show updates for throughput stats, although no new connections are directed to the disabled servers. This is correct functionality. Workaround: None. |
ID 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. 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. 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. 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. |
ID 456942 | When using the DNS:name iRule to modify the RR owner name of a DNS message, TMM may crash if the new owner name passed from the iRule is not a valid domain name or the BIG-IP is processing high volume of traffic and under memory pressure. "When using iRule to modify the RR owner name of a DNS message, and one of the following conditions satisfies: (a) The new domain name passed in from iRule is an invalid domain name. (b) BIG-IP is short of memory and memory allocation failure happens when creating a new RDF." TMM may crash, site is at risk. Workaround: Use a valid domain name in the iRule. |
ID 456942 | When using the DNS:name iRule to modify the RR owner name of a DNS message, TMM may crash if the new owner name passed from the iRule is not a valid domain name or the BIG-IP is processing high volume of traffic and under memory pressure. "When using iRule to modify the RR owner name of a DNS message, and one of the following conditions satisfies: (a) The new domain name passed in from iRule is an invalid domain name. (b) BIG-IP is short of memory and memory allocation failure happens when creating a new RDF." TMM may crash, site is at risk. Workaround: Use a valid domain name in the iRule. |
ID 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 and Splunk format log. DNS logging does not log Splunk format to HSL. Workaround: |
ID 468503 | rpm -qa geoip-data will report a different version than what is installed via geoip_update_data. Workaround: |
ID 471467 | gtmparse segfaults when loading wideip.conf with duplicate virtual server names, or whose names differ only by spaces. wideip.conf contains duplicate virtual server name definitions, or the virtual server names are unique only because of leading or trailing spaces. gtmparse segfaults during a wideip.conf load, causing GTM configuration load to fail. 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. |
ID 472075 | DNS-Express, specifically, the zxfrd process, does not support route domains. DNS-Express Nameserver with Route Domains. When configured with a nameserver containing a non-zero route domain, zxfrd ignores the setting when attempting to connect, always using rd0. Route domains cannot be used to zone transfer to the BIG-IP system. Workaround: |
ID 474215 | The periods and colons in GTM VS names were converted to underscores ("_") after upgrading to v11. upgrading from v10.X to v11.X Production monitoring when customer's production GTMs are upgraded Workaround: |
ID 475074 | "When monitoring a very large number of virtuals, GTM can mark objects down. The log shows: alert gtmd[xxxx]: xxxxxxxx:x: Monitor instance /Common/bigip xx.xx.xx.xx:80 UP --> DOWN from /Common/xxxx (no reply from big3d: timed out)" GTM monitors a very large number of virtuals with maximum synchronous monitor requests set very high. Load balancing can be disrupted because the status of the virtual server is being marked unavailable. Workaround: Set your gtm.global-settings.metrics.max-synchronous-monitor-requests to a value which does not overwhelm the big3d on the other box. |
ID 475109 | "If dns profile with ""Unhandled Query Actions"" set to ""Reject"", dns queries could return successfully every other query and REFUSED every other query too. If dns profile with ""Unhandled Query Actions"" set to ""Allow"", dns queries might return differently for wideip and its alias" "1. Wideip contains some UP and some DOWN pools. 2. Return2DNS LB method configured as failback for pools." DNS queries might get REFUSED even though there are other pools available. Workaround: Modify the pools to use 'none' as the Fallback Load Balancing Method |
ID 475246 | There may be cases where the Instances tab on a GTM monitor fails to list virtual servers which use the monitor. In the case where there are multiple monitors applied to a server, which are inherited by a virtual server. The user cannot rely on the instances tab to provide information about what a monitor is applied to. Workaround: |
ID 476599 | TMM panic when executing DNS_REQUEST event. The TMM panics when the following events have occurred: -DNS_RESPONSE event has been suspended. - DNS_REQUEST event is executed. TMM panic, followed by failover. Workaround: |
ID 476683 | iRules that cause the DNS_RESPONSE event to suspend will not be resumed. DNS_RESPONSE event with command that causes it to be suspended. DNS_RESPONSE event does not complete execution. Workaround: Do not use iRule commands in DNS_RESPONSE event that result in suspension. |
ID 477240 | An iQuery connection attempts to renegotiate SSL keys every 24 hours. Once every 24-hours after an iQuery connection is established. The response to this by big3d is to close the connection. All virtual servers go red. Workaround: |
ID 479603 | Neither DNS-Express nor DNSSEC supports configuration for a DNS Zone with the root name '.'. This occurs in DNS-Express nor DNSSEC. Cannot create a DNS Zone named '.'. Workaround: |
ID 480795 | [GTM] Move address from one HA redundant LTM to another could cause bigip monitor failure. 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. 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. Workaround: Delete the moved address and add it back, or delete the redundant server and re-create it. |
ID 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. This occurs when creating a GTM object using an incorrect name. Cannot rename GTM server object after creation. 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. |
ID 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" "1.There is FIPS card in the BIGIP 2.We need to retrieve the key from the FIPS card" SSL can not locate the key from the FIPS card, and SSL will not function properly. Workaround: |
ID 491801 | "When attempting to create this GTM iRule when DNS_REQUEST { LB::status up } you'll get this error in the logs: ""01070151:3: Rule [/Common/irule_test] error: /Common/irule_test:2: error: [invalid option ""up"" must be: vs pool mbr][up]""" Creating GTM iRules Can't use this specific iRule command syntax. Workaround: |
ID 496775 | [GTM] [big3d] Unable to mark LTM virtual server up if there is another virtual server with same ltm_name for bigip monitor. "LTM (running BIG-IP software older than v11.2.X) with a virtual server: /Common/http_vip with destination /Common/192.168.10.34:80. GTM (running BIG-IP software newer than v11.5.0) with this LTM as a BIG-IP Server. Two virtual servers on LTM: One with the original LTM virtual server address, and the other with the translated address: 1. name ltm_http_vip :: destination 192.168.10.34:80 :: monitor /Common/bigip. 2. name ltm_http_trans_vip :: destination 10.10.10.34:80 :: translation-address 192.168.10.34:80 :: monitor /Common/bigip." Both virtual servers are marked up for a brief interval. After a few minutes, one of them is marked down. Workaround: You can use either of the following workarounds: -- Use a monitor other than bigip. -- Replace /shared/bin/big3d on the LTM system with a copy of a version v11.2.1 big3d. |
ID 497104 | Dec 8 14:31:10 slot1/pm1-n1syd err tmm10[31888]: hash grow: malloc failed low memory condition probably due to memory leak or high memory usage ltm log flooded Workaround: "Modify dnscacheresolver.loglevel to critical or emerg should stop the log spewing. tmsh modify sys db dnscacheresolver.loglevel value critical" |
ID 499719 | 'General database error retrieving information' error in GUI. This occurs when using the GUI to view Statistics for DNS zones. Not able to view Statistics from GUI for DNS zones. Workaround: Use tmsh to view Statistics for DNS zones. |
ID 506423 | Silent failure on unsuccessful creation of resource record. "Create a resource record which will not be successful and for which NAMED does not return an error. For example: Adding DS record via Zone Runner when sub domain delegation is not configured" Record does not get added with no errors returned by ZR. It's unintuitive without any failure messages even though the creation is senseless. Workaround: |
ID 511865 | GTM external monitor is not correctly synced in GTM sync group without device group. 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. 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/bad_external_monitor.sh) 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.' } Workaround: Configure both GTM systems in the same GTM sync group and the same device group. |
ID 514731 | Using the GUI when adding an IPv4 address translation, GTM fails to change GTM server that has IPv4 'Address Translation' enabled. This occurs when using the GUI to add an IPv4 translated address that alphabetically or numerically precedes an existing IPv4 translated address. For example, there is an Address: 192.168.10.12 and Translation: 10.26.10.12, and you add IP address 11.12.10.12. GTM server property cannot be updated. When updating GTM server properties, the system posts errors such as the following: 01020037:3: The requested GTM IP (192.168.10.11 /Common/LTM64) already exists. Workaround: Use tmsh to make these types of changes. |
ID 516055 | [GTM] Continuous Autoconfig scheduling write of wideip.conf happens when two LTM systems have two virtual servers configured with same IP:port. 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. 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: 192.168.10.112 Workaround: |
ID 517582 | Not able to delete a region even though it is not referenced by any record. After attempt to delete a region which is referenced by a record. Hard to manage topology regions. Workaround: Restart mcpd. |
Contacting F5 Networks
Phone: | (206) 272-6888 |
Fax: | (206) 272-6802 |
Web: | http://support.f5.com |
Email: | support@f5.com |
For additional information, please visit http://www.f5.com.
Additional resources
You can find additional support resources and technical documentation through a variety of sources.
- The F5 Networks Technical Support web site: http://www.f5.com/support/
- The AskF5 web site: http://support.f5.com/kb/en-us.html
- The F5 DevCentral web site: http://devcentral.f5.com/
- AskF5 TechNews
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
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 technews-subscribe@lists.f5.com from the email address you are using to subscribe. Unsubscribe by sending a blank email to technews-unsubscribe@lists.f5.com.