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

Applies To:

Show Versions Show Versions

BIG-IP GTM

  • 11.5.0

BIG-IP Link Controller

  • 11.5.0
Release Notes
Original Publication Date: 09/16/2015 Updated Date: 04/18/2019

Summary:

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

Contents:

Supported platforms

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

Platform name Platform ID
BIG-IP 800 (LTM only) C114
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, BIG-IP 5200v

BIG-IP 5050 (requires 11.4.1 HF3)

C109
BIG-IP 7000s, BIG-IP 7200v

BIG-IP 7050 (requires 11.4.1 HF3)

D110
BIG-IP 10000s, BIG-IP 10200v D113
BIG-IP 10050 (requires 11.4.1 HF3) D112
VIPRION B2100 Blade A109
VIPRION B2150 Blade A113
VIPRION B2250 Blade A112
VIPRION C2200 Chassis D114
VIPRION C2400 Chassis F100
VIPRION B4100, B4100N Blade A100, A105
VIPRION B4200, B4200N Blade A107, A111
VIPRION B4300, B4340N Blade A108, A110
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 and for Policy Enforcement Module (PEM), Carrier-Grade NAT (CGNAT), and the BIG-IP 800 platform, the following list applies for all memory levels:

  • vCMP supported platforms
    • VIPRION B2100, B2150, B2250, B4200, B4300, B4340N
    • BIG-IP 5200v, 7200v, 10200v
  • PEM and CGNAT supported platforms
    • VIPRION B2150, B2250, B4300, B4340N
    • BIG-IP 5200v, 7200v, 10200v
    • BIG-IP Virtual Edition (VE) (Not including Amazon Web Service Virtual Edition)
    • PEM and CGNAT may be provisioned on the VIPRION B4200, but it is not recommended for production, only for evaluation. PEM may be provisioned on the VIPRION B2100, but it is not recommended for production, only for evaluation. Use the B4300 or B4340N instead.
  • BIG-IP 800 platform support
    • The BIG-IP 800 platform supports Local Traffic Manager (LTM) only, and no other modules.

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.

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.
  • Note that Global Traffic Manager (GTM) and Link Controller (LC) do not count toward the module-combination limit.

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.
  • Note that GTM and LC do not count toward the module-combination limit.
  • 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.

VIPRION and vCMP caching and deduplication requirements

Application Acceleration Manager (AAM) supports the following functionality when configuring vCMP and VIPRION platforms.

  • AAM does not support disk-based caching functionality on vCMP platforms. AAM requires memory-based caching when configuring it to run on vCMP platforms.
  • AAM supports disk-based caching functionality on VIPRION chassis or blades.
  • AAM does not support deduplication functionality on vCMP platforms, or VIPRION chassis or blades.

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 and 9.x
  • Mozilla Firefox 15.0.x
  • Google Chrome 21.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.0 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.
You can learn more about these new software bundles from your F5 Networks Sales Representative.

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

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.

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

Installation tips

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

Upgrading from earlier versions

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

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

Upgrading from version 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.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.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. The system does not include statistics for requests passed to other wide-IP-members of the distributed application. Workaround: None.
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: None.
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. It is cosmetic and you can ignore it. This is a known issue in BIND. Workaround: None.
ID 343030 "The named process might log the following error in daemon.log: ""Oct 22 09:44:24 local/localhost err named[8832]: 22-Oct-2010 09:44:24.278 general: error: managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found."" Although it reported the error, the daemon is up and running, so you can safely ignore the error." Workaround: None.
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: None.
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. 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 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 If a pool is disabled or has all members disabled and has never had LB_SELECTED event after a reboot, and the pool is specified to be used in a rule an even prior to LB_SELECTED, LB_SELECTED will return a null value instead of "session_disabled" or "down" when used in the LB_SELECTED event. If a pool is disabled or has all members disabled and has never had LB_SELECTED event after a reboot, and the pool is specified to be used in a rule an even prior to LB_SELECTED, LB_SELECTED will return a null value instead of "session_disabled" or "down" when used in the LB_SELECTED event. LB::status does not always return a value Workaround: None.
ID 423930 LTM virtuals with a "." (dot) or ";" (semi-colon) in the name that are also in a non-Zero Route domain are marked down. Workaround: "This workaround involves changing the GTM config. To make this customers config work properly, the GTM has to be configured with 1 server stanza for each route domain on the ltm that has virtual servers. So for instance, if the LTM is configured with the following self ips (3 self ips in default RD, RD1, and RD2) net self 10.5.76.239 { address 10.5.76.239/24 allow-service all traffic-group traffic-group-local-only vlan vlan-576 } net self 10.10.11.39%2 { address 10.10.11.39%2/24 allow-service { default } traffic-group traffic-group-local-only vlan vlan-3273 } net self 10.10.10.39%1 { address 10.10.10.39%1/24 allow-service { default } traffic-group traffic-group-local-only vlan vlan-3270 } and virtuals in each RD: ltm virtual vs.rd0.dottest { destination 10.5.76.39:http ip-protocol tcp mask 255.255.255.255 pool p1 profiles { tcp { } } vlans-disabled } ltm virtual vs.rd1.dottest { destination 10.10.10.39%1:http ip-protocol tcp mask 255.255.255.255 pool p1 profiles { tcp { } } vlans-disabled } ltm virtual vs.rd2.dottest { destination 10.10.11.39%2:http ip-protocol tcp mask 255.255.255.255 pool p2 profiles { tcp { } } vlans-disabled } Then the GTM has to be configured as gtm server /Common/B3600-R18-S39-RD0.lab.ss.f5net.com { addresses { 10.5.76.239 { device-name B3600-R18-S39.lab.ss.f5net.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } gtm server /Common/B3600-R18-S39-RD1.lab.ss.f5net.com { addresses { 10.10.10.39 { device-name B3600-R18-S39.lab.ss.f5net.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } gtm server /Common/B3600-R18-S39-RD2.lab.ss.f5net.com { addresses { 10.10.11.39 { device-name B3600-R18-S39.lab.ss.f5net.com } } datacenter /Common/DC1 monitor /Common/bigip virtual-server-discovery enabled } This creates 3 servers, 1 for each RD. Each server will then only discover and probe *ONLY* the VSes in the route domain. NOTE: remove the ""expose-route-domains yes"" option from the server stanza. If that is left ""on"", then each server will list ALL the VSes on the LTM, creating duplicates. Furthermore, the VSes in a given route domain that does not match the route domain of the server will be marked down. IE: on server 10.5.76.239, in route domain 0, all the VSes in RD1 and RD2 will be red. on server 10.10.10.39, in route domain 1, all the VSes in RD0 and RD2 will be red. on server 10.10.11.39, in route domain 2, all the VSes in RD0 and RD1 will be red"
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 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: "1. Write an external script monitor similar to the following: #!/bin/sh # GTM HTTPS TLS Session Tickets Workaround # Created on 12/5/2013 # For case 1-349097476 # v.0.0.1 # # # these arguments supplied automatically for all external pingers: # $1 = IP (nnn.nnn.nnn.nnn notation or hostname) # $2 = port (decimal, host byte order) # $3 and higher = additional arguments # # In this script, $3 is the directory to GET # $4 is the regular expression to match # pidfile=""/var/run/https_tls_sessionticket_workaround.$1..$2.pid"" if [ -f $pidfile ] then kill -9 `cat $pidfile` > /dev/null 2>&1 fi echo ""$$"" > $pidfile node_ip=`echo $1 | sed 's/::ffff://'` curl -k https://$1/$3 2> /dev/null | grep -E -i $4 > /dev/null status=$? if [ $status -eq 0 ] then echo ""up"" fi rm -f $pidfile 2. Import this Script (TMUI=>System=>File Management=>Import) 3. Create a GTM HTTPS Monitor of type 'External' that references this script 4. Include the directory ""salt"" and the regex ""Salty!"" on the 'Arguments' line if using the Apple VS in the repro This will be passed to cURL in the form of ""curl -k https://$1/$3 2> /dev/null | grep -E -i $4 > /dev/null"" Where $1 is the IP, $3 is the directory, and $4 is the regex 5. Remove GTM HTTPS monitor and assign a custom GTM External monitor to the Generic Host"
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 430200 Changing an explicit link on either a GTM server or GTM virtual server does not immediately apply to traffic. Always If the user needs to direct server or virtual server traffic out a particular link by changing the explicit link settings, the traffic will not take effect immediately. Workaround: bigstart restart gtmd
ID 423317 Normally when a GTM virtual server points to an LTM virtual server that is local to the LC/GTM box, it will display the link that it is assigned by LC/GTM. When a user reloads the config file, virtual servers will lose their association with links. GTM or LC and LTM is provisioned, a GTM virtual server is pointed at an LTM virtual server on the same box, and a user runs tmsh load sys config. The user is unable to see the link associated with the LTM virtual server. Workaround: From the shell prompt on the BIG-IP: bigstart restart gtmd
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 439854 "If there is an LTM VS with a dot ('.') in the name that is not in the same route domain as the self ip that the GTM uses to connect to the LTM, the VS will be marked down. This is because the ltm-name field in the GTM config includes the folder name: /Common/vs.name.route.domain and the LTM has been rolled back to a non folder version, so the ltm-name no longer matches. Furthermore, since it is not in the same route domain, a simple addr/port lookup fails and the VS monitor request times out." Workaround: "Prior to rolling the LTM back to 10.x, edit the config on the GTM and remove ""/Common/"" from the ltm-name fields of the monitor VSes."
ID 440205 "If there is an LTM VS with a dot ('.') in the name that is not in the same route domain as the self ip that the GTM uses to connect to the LTM, the VS will be marked down. This is because the ltm-name field in the GTM config includes the folder name: /Common/vs.name.route.domain and the LTM has been rolled back to a non folder version, so the ltm-name no longer matches. Furthermore, since it is not in the same route domain, a simple addr/port lookup fails and the VS monitor request times out." Workaround: "Prior to rolling the LTM back to 10.x, edit the config on the GTM and remove ""/Common/"" from the ltm-name fields of the monitor VSes."
ID 430200 Changing an explicit link on either a GTM server or GTM virtual server does not immediately apply to traffic. Always If the user needs to direct server or virtual server traffic out a particular link by changing the explicit link settings, the traffic will not take effect immediately. Workaround: bigstart restart gtmd

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.

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.

Legal notices