Original Publication Date: 04/22/2016
Summary:
This release note documents the version 11.5.4 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:
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 10150s-NEBS, 10350v (AC), 10350v-NEBS (requires 12.0.0 HF1), 10350v-FIPS (requires 11.5.4 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:
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.
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.)
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.)
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.
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.
The BIG-IP Configuration Utility supports these browsers and versions:
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.
For a comprehensive list of documentation that is relevant to this release, refer to the BIG-IP GTM / VE 11.5.4 Documentation page.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Before you begin:
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. |
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
Your upgrade process differs depending on the version of software you are currently running.
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.
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.
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.
ID Number | Description |
---|---|
437025 | Very large configs will no longer cause big3d to be Aborted. |
469033 | Reduced big3d memory footprint. |
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. |
510164 | DNS Express zone RR type-count statistics are correctly set after restarting zxfrd. |
510888 | snmp_link monitor is now listed as available when creating link objects. |
514731 | Using the GUI when adding an IPv4 address translation, GTM now successfully changes GTM server that has IPv4 'Address Translation' enabled. |
517582 | Can now 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. |
527024 | Queries for an unsigned child zone of a DNSSEC zone on a BIG-IP are now sent to the backend nameserver. DNSSEC-OK flag is observed when processing the response and attaching and/or responding to DNSSEC resource records. |
527027 | Queries for an unsigned child zone of a DNSSEC zone on a BIG-IP are now sent to the backend nameserver. DNSSEC-OK flag is observed when processing the response and attaching and/or responding to DNSSEC resource records. |
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. |
547815 | Freed a temporary data structure leaked by a premature return in DNSSEC-on-miss patch. |
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 |
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. |
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. |
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. |
ID 437025 | Very large configs will no longer cause big3d to be Aborted. |
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
There are no Global Traffic Manager/Link Controller-specific behavior changes specified for this release.
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. |
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: https://support.f5.com/kb/en-us/solutions/public/11000/800/sol11868. 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 you enter 64:ff9b::1234:1234 and provide 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. |
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 http://support.f5.com/kb/en-us/solutions/public/15000/000/sol15053.html. |
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. |
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/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.' } 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. |
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. |
569472 | tmm cores with sigsegv within lb_why_pmbr_str. tmm cores. "1. Disable a GTM pool or pool member; 2. pool-member-selection is enabled for load-balancing-decision-log-verbosity" Workaround: Disable pool-member-selection for load-balancing-decision-log-verbosity. |
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.
You can find additional support resources and technical documentation through a variety of sources.
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.
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.