BIG-IP GTM and BIG-IP Link Controller 11.6.0

Release Notes : BIG-IP GTM and BIG-IP Link Controller 11.6.0

Applies To:

Show Versions

BIG-IP GTM

11.6.0

BIG-IP Link Controller

11.6.0

Original Publication Date: 07/20/2015 Updated Date: 04/18/2019

Summary:

This release note documents the version 11.6.0 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.

Supported platforms

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, 7200v, 7250v	D110
BIG-IP 12250v (requires 11.6.0 HF2)	D111
BIG-IP 10350N (requires 11.6.0 HF2)	D112
BIG-IP 10000s, 10050s, 10200v, 10250v	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 on the platform or provisioned guest. For vCMP support, 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.6.0 Documentation page.

New in 11.6.0

DNS flood attacks

This release includes DNS Rapid-Response, a performance improvement which can help the BIG-IP system respond to DNS queries faster for zones it is authoritative for and drop the rest.

Response Policy Zones

This release includes Response Policy Zones (RPZ), a firewall mechanism for use by DNS recursive resolvers to allow customized handling of the resolution of domain names. There are vendors that offer RPZ subscriptions, or ZoneRunner is available on the BIG-IP system to create a custom RPZ. When configuring the BIG-IP system to use an RPZ as a DNS firewall, the BIG-IP system filters DNS queries for domains that are known to be malicious and returns custom responses that direct those queries away from the malicious domain.

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 Active-Standby Systems and BIG-IP Systems: Upgrading Active-Active Systems, and we strongly recommend that you reference these documents 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 (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

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-11.2.0.2446.0.iso volume HD1.3

Post-installation tasks

After the installation finishes, you must complete the following steps before the system can pass traffic.

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.)

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 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.6.0

ID Number	Description
ID 225443	"Gtmparse will now successfully load a configuration that contains GTM SIP monitors that include the following properties: ""headers"" and ""filter neg"". Please note that if a single box in a GTM sync group is upgraded to this hotfix version and the ""headers"" or ""filter neg"" gtm sip monitor options are used, all of the boxes in the sync group must be upgraded to this version as well in order for the config to sync successfully between boxes in a sync group."
ID 352101	"Starting with this release, ZoneRunner will attempt to set SOA Serial numbers to the format YYYYMMDDnn Where YYYY = 4 digit year MM = 2 digit month (1-12) DD = 2 digit day (1-31) nn = an increment starting at 1 and increasing to 99. When a zonerunner zone is created, the serial number will be set to 2014021001 (Assuming a creation date of Feb 10th, 2014) When a record is added, if the date is still 2/10/2014, the serial number will be 2014021002 If a record is added on a subsequent day, the date will be changed to match that date, and the nn set to 1. If an existing zone has a serial number that is not in that format, ZoneRunner will attempt to set the serial number to YYYYMMDDnn, keeping in mind that the serial number must always increment."
ID 354161	DNS Express expires zones according to the expire value contained in the zone SOA record.
ID 364302	MCPD validation will throw an exception when deleting a DNSSEC key being used by one or more DNSSEC zones. A DNSSEC key is only allowed to be deleted from the BIGIP when it is not used by any DNSSEC zones.
ID 420440	Multi-line TXT records are no longer truncated.
ID 426477	Setting the timeout now works as expected.
ID 437398	When datagram-load-balance mode is enabled on the UDP profile, the client's max udp payload size is "remembered" for the responses. If the BIGIP alters the response (e.g. DNSSEC signing) and increases its size beyond the max, before sending the response to the client, the response will be properly truncated (per the RFC).
ID 438216	The BIG-IP GTM Cache Local DNS Servers global variable (cache-ldns-servers) is no longer erroneously disabled when persistence is enabled for a wide IP.
ID 439854	An additional attempt is made to match virtual servers by addr:port, even if there is an LTM Name that does not match.
ID 440205	The software now attempts to match the name of the LTM 11.x virtual server with a virtual server on a 10.x BIG-IP system, so the virtual servers are not marked down.
ID 440284	The LTM big3d now correctly identifies and monitors 10.2.4 or earlier LTM virtual servers.
ID 440466	A DNS nameserver is not allowed to be deleted from the BIG-IP system if it is used by a DNS zone as a transfer client. MCPD validation error message will appear when trying to delete a nameserver from the BIGIP if it's used as a transfer client of one or more DNS zones.
ID 440577	"A new DB variable is introduced: zxfrd.dependency.named. By default, the value is true. It means zxfrd depends on named. Modify the value to be false will remove the dependency."
ID 441048	The DNS Express Zone Resource Record counts now display accurate numbers when an AXFR answer is returned for an IXFR query.
ID 442133	Disabling Synchronize on one GTM no longer disables Sync on all GTMs in the sync group.
ID 442980	All pool members returned would get statistics increased.
ID 445333	The .pid file is now removed if the sync of the server.crt file times out. This was a non-critical issue since the file would be deleted at the next synch.
ID 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.
ID 447061	If the listener address changes route domains, the source address will also automatically change to the same route domain
ID 448327	Prevent memory leak when iRule suspends or aborts an DNS command.
ID 448846	A crash bug related to HSM and memory exhaustion has been fixed.
ID 448914	Object name field now has a correct input validation and escapes javascript.
ID 449903	Resolved intermittent issue under heavy DNS cache traffic for a timing issue that could cause a crash.
ID 449845	DNS filter now formally enters framework.
ID 450101	Option code 0x0008 to the client-subnet of the EDNS0 record is now recognized.
ID 446820	TMM no longer crashes due to a poorly formatted log call.
ID 452232	iRule no longer uses stale qname.
ID 456942	After the fix, if the domain name in the iRule is invalid or memory allocation failure happens when modifying the RR owner name using the DNS:name iRule, TMM will not crash.
ID 457221	Now a "." is returned instead of an empty string, when using "DNS::question name" iRule to get the owner name of the question RR if the owner name is root.
ID 458597	Now there is no memory leak when transfer a zone to zxfrd.
ID 467986	TMM no longer cores when running the command 'tmsh show ltm dns cache records key cache myCache' on a cache with stored DNS key records.

Behavior changes in 11.6.0

There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.

Known issues

ID Number	Description
ID 222220	Distributed application statistics shows only requests passed to its first wide IP. The system does not include statistics for requests passed to other wide-IP-members of the distributed application. Workaround:
ID 225759	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 at AskF5 (http://support.f5.com). Workaround:
ID 325318	"If log level is set to info, zrd will log RR add/Delete changes. However it does not: Log what user performed the change Log other changes besides add/del of RR" N/A Logging does not work for adds/deletes. Workaround:
ID 341722	Global Traffic Manager uses BIND 9.7.3. This version of BIND can log a complicated message about not being able to load managed keys from a master file. If you have not configured Global Traffic Manager for DNSSEC Lookaside Validation (DLV), you might receive this message. System logs a benign message similar to the following: managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found Workaround: None. The message is cosmetic and you can ignore it. This is a known issue in BIND.
ID 358268	The TMUI currently allows the DNS64 Prefix to be up to 128 bits (a full IPv6 address), but actually, a valid prefix is only the first 96 bits. Thus, the last 32 bits (last 2 hex tuples) should be all zeroes (e.g., 64:ff9b:0:0:0:0:0:0). Workaround:
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, regardless of whether it is made in the Configuration utility or in tmsh. The only way to speed up this process is to run the following command in tmsh: save sys config partitions all gtm-only No equivalent of this command exists in the Configuration utility." Workaround:
ID 363134	Links get auto-discovered when global Auto-Discovery is disabled and Link Discovery is on. Disabling Link Discovery is the only way to truly disable this option. Workaround:
ID 363142	[Link Controller] global Auto-Discovery can be disabled while having a link with bigip_link monitor. Do not disable global Auto-Discovery while having a link with bigip_link monitor. Workaround:
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. For more information, see SOL12400 at http://support.f5.com/kb/en-us/solutions/public/12000/400/sol12400.html. 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. Workaround: Make sure to specify an Alias Port on a monitor when it needs to probe a specific service port on wildcard virtuals or pool members.
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 381540	TMM restarts with a SIGTERM if zxfrd logging is set to debug and there is heavy load. This occurs with a GSLB + DNSX configuration, no pool associated with the listener, and BIND disabled in the DNS profile. If the unhandled query action is left at the default 'allow', then tmm restarts under load. It seems to occur at approximately at the 720,000-730,000 DNS qps level. TMM does not process traffic during the restart period. Workaround: If the unhandled query action is changed to 'drop', that resolves the issue.
ID 381541	TMM restarts under heavy load. With a GSLB + DNSX configuration, no pool associated with the listener, and BIND disabled in the DNS profile, if the unhandled query action is left at the default 'allow', then tmm restarts under load. It seems to be at roughly the same 720,000-730,000 DNS qps level as above. TMM will not process traffic during restart. Workaround: If the unhandled query action is changed to 'drop' that resolves the issue.
ID 385229	In GTM iRules for 10.2.x, IP::addr will incorrectly always return FALSE when comparing addresses with different masks. To work around this, ensure that when using IP::addr to compare addresses, they have the same mask. Workaround:
ID 393090	When changing the syncer script to use ssh instead of iqsh a permission denied message is generated for gtm. Workaround: The workaround is to not use ssh in the syncer script.
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. 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. 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. 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 will need to copy the builtin object into a new object. Workaround:
ID 415976	A full load across a GTM sync group may occur on the creation of a DNSSEC key under certain conditions. Workaround: Each device in a GTM sync group has a local ID viewable by running 'list sys db gtm.peerinfolocalid' from tmsh. One device will have a local ID of 0. This issue will not occur if DNSSEC keys are created from this device.
ID 418128	LB::status does not always return a value. This occurs when the following conditions are met: -- A pool is disabled or has all members disabled. -- That pool has never triggered an LB_SELECTED event after a reboot. -- The pool is specified to be used in a rule event prior to LB_SELECTED. LB::status returns a null value instead of 'session_disabled' or 'down' when used in the LB_SELECTED event. Workaround: None.
ID 421139	GTM not probing all accessible links, marking some in other DCs as down when they're up. Assume you have two GTMs (1 & 2) in two sDCs, each with a different link, but both GTMs can access both links. If on GTM1 Big3d goes down, GTM2 will flag the link associated with GTM1 as down instead of trying to probe it. Incorrect traffic re-direction, status reporting and synced GTMs reporting different object statuses. Workaround: Create a new GTM DC which contains the un-probed link and the GTM which is up.
ID 425108	If you create or modify a gtm link in tmsh to include a monitor and attempt to list the available selections by using tab completion, only monitors of type bigip-link or gateway-icmp are listed. Always 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: The user must know the name of the monitor and can type it manually
ID 434737	Initial, and unset, values for the zone's serial numbers (primary and external) are '18446744073709551615'. This occurs on the External Serial and Primary Serial numbers. This number represents an unset value. Workaround: None. This value can be safely ignored when not using zone transfer signing. When using zone transfer signing, these values will be reset the first time a service-oriented architecture (SOA) record from the primary passes through the BIG-IP system.
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, then synchronization of all the boxes except one in a sync group will be disabled. "In a box of a sync group, a. Disabling TMUI > System > Configuration > Global Traffic > General > Synchronization b. Wait 10 seconds and then enable it on same GTM. c. Now the box where you've made the change will be enabled, but the synchronization of the peer units will be disabled. Note: 5 seconds is too few and 15 seconds is too many. At 10 seconds can predictably trigger this behavior." The synchronization of the device group will be accidentally disabled. Workaround: After disabling synchronization one box in a sync group, if you want to add it back, do it 1) within 5 seconds or 2) wait 15 seconds
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 442876	Running qkview or the command 'tmsh -q show gtm datacenter detail' does not work correctly for configuration in which an LTM server objects contains virtual servers with dependencies. This occurs as a result of LTM server objects hosting virtual servers configured with a dependency list. For example, having every virtual server dependent on every other virtual server for the virtual server to be up and green (in other words, for VS1 to be up VS2 must be up, and for VS2 to be up VS3 must be up, and so on. The mcpd process consumes all CPU and causes overdog to failover the GTM system. Workaround:
ID 452443	DNS cache resolver or validating resolver does not function properly and fails to resolve DNS requests. BIG-IP is using non-default cmp hashes configured on its egress VLANs. It is difficult to both use non-default cmp hashes on system VLANs and use a DNS cache resolver on the same BIG-IP. Workaround: Configure a separate VLAN for the cache resolver's use that uses the default cmp hash. Set the system's default route to direct resolver traffic to this VLAN. This VLAN can be placed in a new route domain, if other features require route domain zero's default route pointing elsewhere.
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 463097	Large amount of data maintained in DNS Express zones. "When DNS Express zones are updated, you may see messages similar to: notice tmm[25454]: 01010029:5: Clock advanced by 121 ticks in the /var/log/ltm log." 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 vs names or names only differentiated by spaces. wideip.conf contains duplicate vs name definitions or the vs names are only unique because of leading or trailing spaces gtmparse will segfault during a wideip.conf load, causing gtm configuration load to fail. Workaround: Change vs definitions so that there are no duplicate named vs's, note that leading or trailing spaces will not count towards a unique vs name.
ID 472075	DNS-Express, i.e. zxfrd, does not support route domains. When configured with a nameserver containing a non-zero route domain, zxfrd ignores this rd when attempting to connect, always using rd0. Workaround:
ID 472081	The child monitor does not inherit the ignore-down-response options set by the parent monitor. "1. Create a parent monitor with ignore-down-response enabled 2. Create a child monitor default from the previous parent monitor" The child monitor does not inherit ignore-down-response options set by the parent monitor Workaround: Enable the option on the child monitor.
ID 473577	GTMd does not receive and process updates about new GTM WideIP Alias items. After creating a GTM WideIP Alias item, any subsequent changes to only the WideIP Alias will not be received by the GTM daemon, and thus will not be synchronized to other GTM devices in the sync group. GTMd does not receive updated information about changes to WideIP Alias configuration items. Workaround: Make other changes after making wideip alias changes
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:

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.

Subscriptions

Product Usage

Trials

Registration Keys

Downloads