Release Notes : BIG-IP 11.5.2 LTM and TMOS Release Notes

Applies To:

Show Versions Show Versions

BIG-IP LTM

  • 11.5.2
Release Notes
Original Publication Date: 03/18/2018 Updated Date: 04/18/2019

Summary:

This release note documents the version 11.5.2 release of BIG-IP Local Traffic Manager and TMOS. You can apply the software upgrade to systems running software versions 10.1.0 (or later) or 11.x.

Contents:

Platform support

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, 5050s, 5200v, 5250v C109
BIG-IP 7000s, 7050s, 7200v, 7250v D110
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. 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 B2100, B2150, B2250, B4300, B4340N
    • BIG-IP 5x00v(s), 7x00v(s), 10x00v(s)
    • BIG-IP Virtual Edition (VE) (Not including Amazon Web Service Virtual Edition) (3 GB, 10 GB production and combination lab models)
    • 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. 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 LTM / VE 11.5.2 Documentation page.

New in 11.5.2

There are no new features specific to Local Traffic Manager.

New in 11.5.1

There are no new features specific to Local Traffic Manager.

New in 11.5.0

Security

ECC and DSA support for multiple client cert/key assignment in SSL client profiles

The BIG-IP system now includes support for Elliptical Curve Cryptography (ECC) and Digital Signature Algorithm (DSA) certificates in addition to the current RSA server certificate support for the client SSL profile. This is in support of new CA offerings where RSA and ECC and DSA server certificates are now being offered. Configuration options in the client SSL profile enable assignment of multiple certificate/keys pairs.

AES-GCM support for TLS version 1.2 for RSA and ECC Ciphers

The BIG-IP system now includes support for Advanced Encryption Standard-Galois Counter Mode (AES-GCM) on RSA and Elliptic Curve Cryptography (ECC) cipher suites for Transport Layer Security (TLS) version 1.2 protocol implementations. This level of support brings the BIG-IP system into compliance with IETF RFCs 5288 and 5289.

STARTTLS support for SMTP traffic

Using the new SMTPS profile type, you can activate support for the industry-standard STARTTLS extension to the SMTP protocol. When you create an SMTPS profile, you instruct the BIG-IP system to either allow, disallow, or require STARTTLS activation for SMTP traffic. The STARTTLS extension effectively upgrades a plain-text connection to an encrypted connection on the same port, instead of using a separate port for encrypted communication.

Enable/ Disable SSL Forward Proxy based Data Group Entries

There is a new iRule command to conditionally turn-off SSL Forward proxy. There is a new iRule on-box to support the command.

iControl Support for PKCS#12 Encrypted Password Container Format

This release supports PKCS#12 via iControl. This is a password container format that contains both public and private certificate pairs. This container is fully encrypted.

Improved PKCS#11 Interface Performance

This release contains performance enhancement to PKCS#11 Integration.  

SafeNet Luna SA HSM integration with BIG-IP system

SafeNet Luna SA is an external HSM that is now available for use with BIG-IP systems. Because it is a network-based appliance, rather than an internal card-based solution, you can use the SafeNet Luna SA solution with the majority of BIG-IP appliances that run 11.5.0, including the BIG-IP Virtual Editions (VE).

Enhanced security for environments with stateless network traffic

VLANs on the BIG-IP system now include an optional configuration setting that causes the system to load balance traffic, using a round robin algorithm, across TMM instances. When enabled, this feature ensures that the system distributes packets evenly across TMM instances. By load balancing packets in this way, the system can prevent events such as certain types of DDoS attacks designed to send all packets to a subset of TMM instances as a way to overload the system.

BIG-IP 7200v HSM and SSL

This release features support for the new BIG-IP 7200v-FIPS Hardware Security Module (HSM) and Turbo SSL models within the BIG-IP 7000 series appliances. The 7200v-FIPS HSM model includes a FIPS 140-2 Level 2 certified internal HSM card that offloads SSL/TLS processing with industry leading bulk crypto throughput and protection of private keys. The 7200v-SSL model delivers the highest SSL performance in its class enabling organizations to maximize SSL offloading from overburdened servers and provide in depth protection for web applications. For more information, see Platform Guide: 7000 Series and the BIG-IP System HARDWARE DATASHEET.

VIPRION 2200

This release provides support for the new VIPRION 2200 platform, a two-blade chassis that supports B2000 Series blades. You must install BIG-IP version 11.5.0 or greater on all blades used in this chassis. For more information, see Platform Guide: VIPRION 2200.

Application Fluency

TCP Enhancements

This release includes several user-configurable TCP enhancements to optimize traffic for mobile users, including multi-path TCP (MPTCP) support, additional congestion control algorithms (Woodside, Illinois, Hamilton), and rate pacing per TCP connection to prevent bursty packet transmission. Two pre-configured TCP mobile optimized profiles target service providers and enterprise environments.

Proxy Mode for HTTP profiles

This release introduces a new Proxy Mode setting for HTTP profiles. In previous releases, when the BIG-IP system functioned as a forward proxy or transparent proxy server, and the system detected malformed or unknown HTTP traffic, the default behavior was to deny the traffic and drop the connection. With the Proxy Mode feature, you can configure the BIG-IP system to manage responses from multiple servers, allow and deny connection requests from browser traffic, and forward invalid HTTP traffic to a specific server instead of dropping the connections. This feature is particularly useful for service providers who require more flexibility in the way that the BIG-IP system manages invalid or unknown HTTP traffic.

SOCKS Profile

You can now use the BIG-IP Local Traffic Manager SOCKS profile to configure the BIG-IP system to handle proxy requests and function as a gateway. By configuring browser traffic to use the proxy, you can control whether to allow or deny a requested connection.

BER/DER encoding and decoding

This release provides BER/DER encoding/decoding iRule primitives for building traffic management solutions for protocols such as LDAP and SNMP.

Microsoft SQL Server Proxy

There is now a profile for MSSQL DB Environments that provides native parsing of TDS protocol, proxies basic authentication, routes connections based on SQL command or user. Layer on additional traffic management functions such as Priority pool activation, MS SQL Monitor, Client Side SSL, and OneConnect.

FIX Protocol Profile

The BIG-IP system provides a FIX profile for Financial Information eXchange (FIX) tag substitution and load balancing based on tags, for example, SenderCompID. When a client's tags and an institution's tags are not equivalent, tag substitution can be formed. Because the BIG-IP system natively parses and validates the FIX protocol, the BIG-IP system can provide context-aware routing of connections. If a FIX message passes a syntax and checksum verification, the BIG-IP system allows transmission, triggers the FIX_MESSAGE iRule event, and optionally logs the message. If a FIX message is invalid, the BIG-IP system logs the error, and either disallows transmission or drops the connection, as configured by the profile.

ePVA support UDP Transport

ePVA now supports offload of UDP traffic when using FastL4 Profile.

Pre-Defined groupings for Analytics

In this release, Administrators can create groups of IP addresses; both IPv4 and IPv6 addresses are supported in a grouping. The subnet groupings are global per device and are not configurable on a per application basis to avoid subnet name conflicts. Subnet groupings cannot be used together with geo locations; a user can view either subnets or geography.

Infrastructure

iControl REST

This release introduces a REST interface to iControl to remotely execute TMSH. iControl REST APIs are available for all BIG-IP product modules. TMSH versioning  was added to provide script compatibility between versions of BIG-IP.

Network Virtualization Tunnels

This release introduces Layer 3 gateway functionality and support for the VXLAN (Unicast), NVGRE, and Transparent Ethernet Bridging tunnel types used in deploying virtualized networks.  

IPsec Tunnel Interface

This new tunnel interface framework enables an IPsec tunnel to be used like any BIG-IP VLAN. Using this feature gives you more flexibility in associating IPsec with other objects in the BIG-IP system, such as static routes and virtual servers.

HA group failover for traffic groups

Prior to this release, the HA group feature of the BIG-IP system calculated a single HA health score for per device, and if the score fell below a configured threshold, the system initiated the failover of all traffic groups on the device. With this release, you can configure a separate, unique HA group for each traffic group instance on a device, causing the BIG-IP software to calculate a separate health score for each traffic group instance on a device. The result is that the system can initiate failover for a specific traffic group according to the needs of the application traffic associated with that traffic group. For example, if you create traffic-group-2 containing the virtual IP address 192.168.20.10, and you create an HA group based on trunk health and assign it to the instance of traffic-group-2 on device Bigip_A, then that instance of traffic-group-2, if active for Bigip_A, fails over to another device in the device group whenever the number of links falls below the specified threshold.

New utility for DSC configuration

For BIG-IP users who need to expediently set up device service clustering (DSC) on an existing system, this release includes a separate Run Config Sync/HA Utility wizard, available within the BIG-IP Configuration utility on the About tab of the navigation pane. This wizard is similar to the Setup utility but focuses on DSC-related tasks only, such as setting up device trust and device groups, as well as configuring config sync, failover, and connection mirroring.

Appliance mode for vCMP guests

On a vCMP system, you can now enable or disable Appliance mode for each guest individually, with no need to include Appliance mode in the BIG-IP system license. Enabling appliance mode for a guest adds an additional layer of security by ensuring that administrators for the guest use the BIG-IP Configuration utility and the Traffic Management Shell (tmsh) only, with no access to the root account and the Bash shell.

Software update availability check

This release provides the ability to check the F5 Networks downloads server for software updates for your system. By default, the system automatically checks the downloads server weekly. When there are no updates for your server, the system indicates that, and when there are, you can click a link to go to the downloads server to retrieve the most recent release/hotfix, EUD, EPSEC, and geo location version. You can find Update Check on the Software Management submenu.

DAG Round Robin disaggregation

The new DAG Round Robin feature for VLANs prevents stateless traffic from overloading a few TMM instances, instead load balancing the traffic among TMMs evenly rather than using a static hash. Stateless traffic in this case includes non-IP Layer 2 traffic, ICMP, some UDP protocols, and others. DAG Round Robin is particularly useful for firewall and Domain Name System (DNS) traffic, and can help prevent certain types of DDoS attacks, such as an ICMP DDoS attack that can overload the system by sending the same packets repeatedly to a specific subset of TMMs.

ZebOS Updates

This release provides an update to ZebOS 7.10.2, as well as additional OSPFv3 enhancements (OSPFv3 NSSA support, OSPFv3 Multiple Address Family support (RFC 5838), BFD support for OSPFv3)

CGNAT

CGNAT :: PPTP ALG Profile

This release provides a point-to-point tunneling protocol (PPTP) profile that enables you to configure the BIG-IP system to support a secure virtual private network (VPN) tunnel that forwards PPTP control and data connections. You can create a secure VPN tunnel by configuring a PPTP Profile, and then assigning the PPTP profile to a virtual server.

CGNAT :: BIG-IP Deterministic NAT utility

This release provides improvements to the BIG-IP Deterministic NAT utility (dnatutil), which can now interpret logs from version 11.4 and later. The dnatutil provides reverse or forward map possible end-points of the subscriber. The dnatutil is now packaged to install and run on CentOS or Debian based Linux systems using archived logs and is not tied to a specific version or platform of BIG-IP, allowing you to store and process logs from any supported DNAT log destination, including LTM, Remote Syslog, and Splunk.

CGNAT :: 6rd Support

The 6rd (rapid deployment) feature is a solution to the IPv6 address transition. It provides a stateless protocol mechanism for tunneling IPv6 traffic from the IPv6 Internet over a service provider's (SP's) IPv4 network to the customer's IPv6 networks.

PCP

This release of BIG-IP software supports the Port Control Protocol (PCP). Client-side devices (such as BitTorrent and Xbox) can use PCP to control Network Address Translation (NAT) mappings for themselves. See RFC 6887 for an exact specification of PCP. A PCP client can request an address mapping (such as 192.168.25.10 to 172.14.2.34) for itself or on behalf of another client machine, and PCP servers on NAT and Carrier-Grade NAT (CGNAT) devices support that mapping. The PCP client can then advertise its public-side address to fellow clients from the same vendor. The BIG-IP system is a CGNAT device that supports PCP mappings.

IPFIX for CGNAT

This release of BIG-IP software supports IPFIX and NetFlow V9 logging. IPFIX is a set of IETF standards. This version of BIG-IP software supports logging of CGNAT translation events and AFM events over the IPFIX protocol. This implementation conforms to the IPFIX protocol specified in RFC 5101, and the information model described in RFC 5102.

Documentation

BIG-IP Systems: Upgrade

This release introduces the BIG-IP Systems: Upgrading 11.x Software guide, which provides information for upgrading from earlier BIG-IP 11.x software to the current software version. This guide supplements the existing upgrade documentation, which describes upgrading from BIG-IP 10.x software to the current 11.x software version.BIG-IP Systems: Upgrading Active-Standby Systems and the BIG-IP Systems: Upgrading Active-Active Systems documents.

Good, Better, Best

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 the following guides, 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.6.0 to volume 3 of the main hard drive.

tmsh install sys software image BIGIP-11.6.0.0.0.401.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 the following guides, 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.

Upgrading to 4th element versions from versions earlier than 11.5.0

You cannot directly update from pre-11.5.0 versions (e.g., v11.4.x, v11.2.x, etc.) to any 4th element version (e.g., v12.1.3.1, v13.1.0.1, etc.). Direct upgrade to 4th element versions is supported only from v11.5.0 and later. For pre-11.5.0 versions, you must first upgrade to v11.5.0 or later. The recommended upgrade path is from v11.4.1 to v12.1.3, and then to v12.1.3.1. 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.

Upgrading earlier configurations

When you upgrade from an earlier versions of the software, you might need to know about or take care of these configuration-specific issues.

ID Number Description
ID 223704 When you import a single configuration file (SCF file) that contain VLANs of the same name that exist in different administrative partitions, the operation fails with a unknown operation error. To work around this issue, before installing an SCF file, run the tmsh load sys config default command. This returns the system to the default configuration, so subsequent configuration import operations should succeed as expected.
ID 366172 A pre-v11.x configuration that was created with the bigpipe cli ip addr option set to name may cause configuration load failure on upgrade due to resolved names saved to the bigp.conf file rather than IP addresses. The workaround is to change the cli setting to 'cli ip addr number', save the config on the pre-v11.x unit, and then run the upgrade.
ID 370964 When upgrading a 10.x standard active/standby pair, the recommendation is to start with the device with the numerically highest management IP address. There is a change in behavior in 11.1.0 that automatically selects the system with the highest management IP address as the active member of the device group. Depending on your configuration, an upgrade could result in lost traffic.
ID 378430 "When upgrading to version 11.x, with a WAM policy containing no nodes, the upgrade fails with the following error message: Tmsh load failed: 01071419:3: Published policy (/Common/empty_policy) must have at least one node. Unexpected Error: Loading configuration process failed. There are two options for working around this problem: 1. Before upgrading, add a new node to the empty policy with the default settings. Publish the policy. Then upgrade. 2. Before upgrading, remove the empty policy from any applications and delete the policy. You may create a copy of the policy before deleting, as long as you do not publish the copied policy. Then upgrade."
ID 384569 "If an object is in a partition with the default route domain set, and that object refers to an object with an IP address in /Common, a config rolled forward from a previous release might not load. - When using the default route domain for a partition, all objects with addresses should be in that partition. To work around this issue, move objects into /Common or edit the config file and for all conflicting objects in common, append %0 to the name/address. For example, if a pool in partition_1 references a member in route-domain 0: ... shell write partition Common node 10.10.20.1 { addr 10.10.20.1 } ... shell write partition partition_1 pool rd0-pool1 { members 10.10.20.1:any {} } ... change it to: ... shell write partition Common node 10.10.20.1%0 { addr 10.10.20.1 } ... shell write partition partition_1 pool rd0-pool1 { members 10.10.20.1%0:any {} } ..."
ID 394873 The upgrade process does not update Tcl scripts (such as iRules) in the configuration. This might cause issues when iRule syntax changes between releases. After upgrading, you might need to modify iRules to reflect any changes in iRule syntax.
ID 398067 As of version 11.0 a check is performed to ensure a failover unicast address actually exists. In configurations using the management port for failover, the management IP and unicast failover IP must be identical for failover to function properly. They must also be identical before upgrading. Releases preceding and including 11.3.0 do not automatically modify the unicast failover IP when the management IP is changed or vice-versa. This can cause failures when loading the config after an upgrade. This is an example error: 0107146f:3: Self-device unicast source address cannot reference the non-existent Self IP (a failover IP); Create it in the /Common folder first. Before upgrading, ensure that the management IP and unicast failover IP are identical.
ID 399013 On 10.x-to-11.x upgrade, the UCS restore lowers the cache size by 25% for all web-acceleration profiles.
ID 399510 "On BIG-IP Virtual Edition systems running software prior to 11.3.0 with statically configured management port IP addresses only, disable the DHCP service with the command ""tmsh modify sys global-setting mgmt-dhcp disabled"" prior to upgrading to this release of BIG-IP software. Disabling the DHCP service prior to upgrading will preserve the static IP address configuration as part of the installation. Statically configured management port IP addresses on BIG-IP hardware platforms are not required to have this configuration change prior to upgrading."
ID 401367 Version 11.x added validation around the use of CACHE:: commands on virtual servers with RAM cache enabled. The result is that upgrading from version 10.x to 11.x fails under certain configuration conditions, for example, if the configuration contains a CACHE_RESPONSE event in an iRule, and there is not an associated Web Acceleration profile applied to that virtual server. To work around the upgrade failure, locate and remove the applicable iRules and virtual servers in the configuration, and try loading the configuration again.
ID 401828 "Problem: The below configurations are invalid for a SIP VS a)tcp virtual with a udp profile+sip profile b) udp virtual with a tcp profile+sip profile Result: If such a configuration exists in previous versions, it will load in 11.3 but may cause a core. Solution: Customer must fix their configuration manually - a) A SIP tcp virtual must have TCP as one of its profile type. b) A SIP udp virtual must have UDP as one of its profile type."
ID 402528 There is now more stringent validation on protocol profile combinations. You cannot configure UDP, TCP, and SCTP protocol profiles for handling the same client-side or server-size traffic. In addition, the following profiles are mutually exclusive: SIP, RTSP, HTTP, Diameter, RADIUS, FTP, and DNS. If one of these profiles is assigned to a virtual server, you cannot assign another one. In the past, the BIG-IP system did not prevent such invalid combinations; now it does. If you have previous configurations containing this invalid combination of profiles, you must correct the configuration before the upgrade can succeed. When you upgrade from pre-11.3.x versions, if you see such an error message during configuration load, fix those invalid combinations and try the upgrade again.
ID 403592 Platforms with less than 6.5 GB memory cannot be upgraded to version 11.3.0 if three or more modules are provisioned. Note that upgrades from version 10.0.x display only an "upgrade failed" message as a software status. All other versions show a clear error message, guiding the users to SOL13988. Before upgrading, make sure you have only one or two modules provisioned if the BIG-IP system has less than 6.5 GB of memory.
ID 403667 In this release, improved validation does not allow users to upgrade or configure VLANs with names greater than 64 characters. This mitigates system instability found when this validation was not present. During upgrade from 10.x to 11.x, this new validation code prevents VLANs with names longer than 64 characters from passing validation. The problem is complicated by the fact that the BIG-IP system prefixes partition_path to vlan_name. That means that a VLAN named vlan_site6 in the Common partition is actually named /Common/vlan_site6. If you have VLANs with names longer than 64 characters, upgrade fails. To work around this, change the VLAN names before upgrading. This involves changing the VLAN name as well as any configuration objects that refer to that VLAN.

Fixes in 11.5.2

The contents of 11.5.1 HF1 through 11.5.1 HF6 (inclusive) are merged into 11.5.2.

ID Number Description
ID 356658 The system no longer logs alert-level log when remote authenticated users that do not have local account login. The notice-level error is written to /var/log/secure, as expected.
ID 400945 Errors reported when vdisk volume is corrupted/unmountable have been clarified.
ID 416292 Ensured that the active CMI connection is destroyed when mcpd is shutting down.
ID 417068 FIPS key labels longer than 32 characters now get truncated to 32 characters. Those keys with the same first 32 characters are truncated, and the system attaches an underscore and number to a total of 32 characters; for example fipssamplekeylabelof32characte_1, fipssamplekeylabelof32characte_2, and so on. BIG-IP uses the FIPS handles when querying the FIPS cards for keys, so the fact that the FIPS key labels are different from the BIG-IP key names does not matter and does not affect traffic.
ID 419664 Performing a mibwalk of SNMP-sysIfxStat now returns expected stats.
ID 424143 The SNMP configuration is now being saved to the correct file.
ID 426328 Updating an iRule that uses sideband connections no longer causes TMM to core.
ID 427357 The icmp-echo property is now set correctly for virtual addresses with network prefixes.
ID 427832 The timestamp for the bounded lifetime of the syncookie tables of secrets is now maintained correctly. As a result, software syncookies are resolved consistently.
ID 428072 If an iRule refers to a pool by leaf name (without the full path), the virtual server status now reflects the pool's status.
ID 432720 The BIG-IP will not send GARPs for a Virtual Address when the ARP has been disabled for that virtual address.
ID 434400 The connection is terminated and tmm core no longer occurs.
ID 434730 Automatic incremental synchronization succeeds even after a large number of synchronization operations in rapid succession.
ID 437627 Improved handling of a fragmented packet that could cause a crash if using a fastL4 profile.
ID 437773 All LACP trunk members remain present after rebooting primary blade.
ID 437875 "This spurious error message may have previously been displayed when the local user database feature is configured: 01071704:3: Not running command (/usr/libexec/localdb_mysql_restore.sh) because the request came from an untrusted connection. This error message has always been harmless, but now it no longer is displayed."
ID 438877 The SASP monitor ignores up to 5 consecutive unexpected send weight messages and keep looking for registration reply response from GWM. If it does not get the reply in 5 attempts then the monitor shall restart.
ID 439363 When the local traffic policy name that is auto-generated from multiple HTTP Class profile names is longer than the maximum supported length of 255 characters, the system now truncates the name, so that config load and upgrade occur successfully.
ID 441985 The key/cert/chain/passphrase (outside ckc) now matches the RSA pair inside ckc.
ID 442020 Router information is now preserved correctly by proxy ARP/NDP code for VLAN groups.
ID 442191 The policy condition now converts properly from an HTTP class to an LTM policy and the ultimate behavior is identical to that of the previous release.
ID 442336 TMM no longer crashes when there is a FastL4 virtual server, syncookie is enabled, PVA is accelerated, and a configured SERVER_CONNECTED rule fails.
ID 442391 Duplicate address detection and unsolicited neighbor advertisement now work as expected.
ID 442618 Improved memory handling in TMM prevents some TMM crashes in low-memory situations.
ID 442993 Only the default managment-route is used to configure the gateway, and if unconfigured no gateway.
ID 444178 The policy will properly replace specified HTTP headers.
ID 445911 tmm fast forwarded flows are no longer offloaded to ePVA, which is correct behavior.
ID 447080 VLAN tagged/untagged configuration change occurs immediately, and no longer requires tmm restart.
ID 447874 HTTP pipeline request no longer causes TCP window stay at 0 when HTTP pipeline requests are sent, and those requests use the GET method.
ID 448476 Updated media code to recognize XFP media in PB100 blades.
ID 448533 The endpoint is chosen based on the client's source port. This leads to better port selection behavior.
ID 448787 Connection tracking is now correctly disabled in non-default route domains.
ID 449891 Fallback source persistence record will be used and the second ssl request will be load balanced to the same pool member that the first one went to.
ID 449896 Deterministic NAT (DNAT) does not pick a colliding port for the second connection, so connections complete successfully.
ID 449989 Can now save UCS when using iControl REST.
ID 451035 Configuring BIG-IP with hundreds of FIPS keys no longer causes TMM to reset.
ID 451319 The system now honors Content-Length header when server responds with 4xx response with body for CONNECT request.
ID 451534 TMM SIGSEGV and crash no longer occurs with SSL forward proxy in PassThrough Mode.
ID 452293 Monitors now work on the Standby devices in an HA configuration.
ID 452315 Connection rate limit configured on Virtual with no default Pool works
ID 452454 Forward RST packet for IP forwarding Virtual with fastL4 profile with loose initialization configured and an idle timeout that is less than the server idle timeout.
ID 452482 Cookie persistence records are ignored when the connection limit of the persisted pool member has been reached. This results in incoming connections to be offloaded to another pool member (if available).
ID 452643 "A Members lb_value is updated upon transitioning from disabled to enabled states when using one of the following load balancing methods: - Least Connections - Fastest - Least Sessions"
ID 452689 Constructing such as IPIP, GRE tunnels using the IPsec tunnel interface now passes traffic as expected.
ID 453171 The system now correctly handles a large number of cookies when using Application Policy Manager (APM).
ID 454475 The padding values used in the TLS 1.0 or greater handshake are now validated, and invalid values cause an alert to be sent.
ID 454954 Packets dropped using DIAMETER::drop within DIAMETER_INGRESS event will no longer be retransmitted.
ID 455376 Parked Diameter response messages are no longer dropped, nor are the requests retransmitted.
ID 456461 The TMM no longer core dumps when a vlan-group is configured after an sflow receiver.
ID 456467 This release fixes the intermittent/infrequent case where the CPU usage (from the top cmd) of restjavad exceeds 20% for 15 seconds.
ID 457934 SSL Persistence Profile now operates correctly, and does not cause high CPU usage.
ID 458480 TCP Segmentation Offload (TSO) no longer causes the Traffic Management Microkernel (TMM) to restart during high memory usage.
ID 458957 TMM no longer leaks memory on repeated plugin client initialization messages.
ID 459096 Setting Allow All to Allow Default now works without error.
ID 459929 Policy rules are now evaluated in the expected order.
ID 460020 If there are multiple set cookie rewrites to an HTTP response header, tmm no longer cores due to referencing incorrect locations into the buffer.
ID 460178 oamd shutdown function has been updated and does not crash attempting double delete.
ID 460730 Increased MCP's throughput by limiting the amount of data sent in a given chunk.
ID 460945 Memory no longer leaks when changing a policy that is in use by a virtual server.
ID 461350 Fix the standby box memory keeps growing when the connection mirroring and re-transmission are turned on.
ID 461578 This release provides improved handling of large objects in the session database.
ID 462351 Stats for policies can now be reset from the Statistics :: Module Statistics : Local Traffic :: Policies page without error.
ID 462025 The BIG-IP MySQL and MSSQL monitors now work as expected.
ID 463470 The Active Translation Mappings now count only translation mappings that are actively in use.
ID 463652 Client SSL profile retains its own Certificate/Key/Chain entries, when they differ from the parent profile.
ID 463715 syscalld's timeout mechanism no longer emits an OPERATION_TIMEOUT message, unless the message appropriately reflects the condition of the system.
ID 464132 Allows serverside SSL to be disabled by iRule or CPM policy.
ID 464148 The deterministic NAT (DNAT) utility (dnatutil) now reports correct reverse mappings for platforms with Intel Hyper-Threading Technology (HT) Technology split plane (htsplit) CPUs, which includes VIPRION and BIG-IP series 4000, 7000, 8000, and 10000 platforms.
ID 464499 A client-ssl profile configured on a partition other than /Common now retains its cert-key-chain setting.
ID 464683 Upgrade from 11.2.1 to 11.5.0 and later now works correctly.
ID 465052 Check to make sure all required arguments are present in an HTTP::cookie command prior to attempting to use them.
ID 465133 SIP-ALG will now keep track of the second INVITE and sequence number and recognize the 200OK
ID 465607 The system now provides checks to mitigate the race condition on close of FastHTTP to avoid the core.
ID 465803 OpenSSL is updated to fix CVE-2014-0221 and CVE-2014-0195.
ID 466281 A value stored in the session DB from an iRule on the parent VS can be accessed from the internal virtual server, and vice-versa.
ID 467022 The platform capabilities file which was causing this issue has been modified to allow the system to go active normally.
ID 467646 IDE DMA timeouts no longer result in become unresponsive on VIPRION B4100/B4100N (A100), B4200/B4200N (A107) blades and on Virtual Edition (VE) configurations deployed with IDE storage drivers (Xen, Hyper-V).
ID 467706 Forward and reverse mapping are now agreement for VIPRION C4800/C4800N (S100, S101).
ID 467868 Previously, mcpd might leak memory when returning an error message that contained the reason for a monitor failure. The message now reports the reason without leaking memory.
ID 468175 The system now works correctly, without stopping traffic going through an IPsec tunnel from BIG-IP systems to Cisco systems.
ID 468388 Connection flows do not leak and TMM does not core when service provider DAG is configured and/or under-provisioned LSN pools are configured on the BIG-IP systems.
ID 468514 Ensures that only one sync for a given commit transaction is sent to the remote peer.
ID 468517 This MCPD error message should no longer occur at the secondary blades: err mcpd[6528]: 010717b5:3: HA group (HA) cannot be removed. It is used by traffic group (/Common/traffic-group-1 )
ID 468837 SNAT translation traffic group inheritance now syncs across devices using incremental sync.
ID 469139 Modify virtual stats detail page to display values for max PVA assist, Current PVA assist and total PVA assist from the virtual server stats table and the pva struct.
ID 469739 The ConfigSync operation completes successfully if HA pair has dissimilar cert-key-chain sub-object names within an SSL profile.
ID 470191 FastL4 component now validates existence of connection peer upon reception of TCP FIN.
ID 471644 'Total' is removed from Throughput(bits) and Throughput(pkts) charts (both in GUI and tmsh)
ID 471821 Compression.strategy "SIZE" would cause software to do the compression.
ID 472148 The Nitrox driver was updated to properly handle highly fragmented SSL records.
ID 472157 The browser now succeeds uploading large files.
ID 472571 Multiple client SSL profiles attached to a virtual server will no longer cause memory to be leaked.
ID 472944 SMTP commands received after STARTTLS will be correctly buffered by SMTPS profile until the SMTP server is ready to receive them.
ID 473105 FastL4 connections are now handles correctly with pva-acceleration set to guaranteed, and are no longer reset.
ID 473200 Manually editing the system configuration and renaming a virtual server with an empty pool no longer causes an unexpected error when reloading the configuration.
ID 474069 If the IVS connection is closed while ICAP is processing an iRule that completes asynchronously, and if on resumption of processing the ICAP response an abort occurs, the closing is not processed after the abort, and no crash occurs.
ID 474226 LB_FAILED event is correctly triggered when persistence pool member is not available or offline.
ID 474584 The igbvf driver no longer leaks xfrags when a partial jumbo frame is received.
ID 474771 In this release, the system includes the PVA statistics when calculating the BIG-IP system global throughput statistics values.
ID 475791 Removed ramcache race condition, so that connection teardown messages are processed in the correct order.
ID 476564 The system now sends RST in guaranteed mode for an ePVA flow when the packet is received in software.
ID 476567 The system now updates accelerated status after the flow has been successfully inserted into the ePVA, so the correct state is reported.
ID 476886 In this release, if BIG-IP system receives the complete ICAP response from the ICAP server before it has completed sending the ICAP request, and a OneConnect profile is on the IVS, the TCP connection to the ICAP server is terminated and that connection is not reused.
ID 477111 The main routing table now has a single entry for the management network.
ID 477232 Only the translation address persists when the persistence mode is address.
ID 477375 SASP monitor no longer cores when configured in push mode.
ID 477394 Passive FTP using FTP range iRule no longer causes out-of-ports reset.
ID 477859 ZebOS config now loads correctly when the password begins with a number.
ID 478195 FIPS exported keys can now be correctly installed on other FIPS platforms that belong to the same FIPS security domain.
ID 479171 tmm no longer attempts to transmit DSACKs after reassembly queue has been purged, so no tmm crash occurs.
ID 480113 FIPS exported keys can now be successfully installed in FIPS cards without causing config-sync failure.
ID 480509 HTTP bodies containing a Content-Type header of 'application/javascript' or 'text/javascript' will be recorded under the 'Javascript' compression statistic.
ID 480686 Internal vlangroup loop no longer occurs when the Translucent/Transparent vlangroup setting exists with a duplicate IP address.
ID 480699 Increased the maximum statemirror.queuelen db variable limits. If necessary, the statemirror.queuelen can now be increased beyond 256 MB up to 1 GB. Note that increasing the statemirror.queuelen increases memory requirements to approximately twice the queuelen multiplied by the number of tmms, and also increases the time required to detect an error in the mirroring connection. The statemirror.queuelen should be kept as low as possible to prevent repeated failure.
ID 480888 A response from the server is no longer truncated in some situations when the serverssl profile is combined with the use of the HTTP::collect iRule command.
ID 481082 The auto update settings no longer reset during a sync operation.
ID 481410 Automated Phone Home update check time is randomized to prevent intermittent problem when all machines would access the service at once.
ID 481647 OSPF daemon no longer asserts when receiving a Link Status (LS) Update Packet with an LSA header whose length is greater than 255 bytes.
ID 481648 The ipaddrTable's ipAdEntIfIndex value now matches the ifTable's ifIndex value for the same interface.
ID 481880 SASP monitor no longer core dumps during a state change in push mode.
ID 483157 The BIG-IP system no longer uses 0 (zero) as the TCP source port for server-side flows, so TCP ports are not reused too quickly.
ID 483328 SSL virtual servers now successfully negotiate SSL handshake, so the device no longer logs the following message: crit tmm[14270]: 01260000:2: Profile name-of-profile: could not load key/certificate.
ID 484453 Reduced the log level for registering with the LOP (lights out processor) to the debug level.
ID 485189 TMM now verifies that a persistence cookie was successfully found before extracting it from HTTP responses.
ID 485833 Ensure all user directory file descriptors are closed.
ID 486137 Activation function has been modified to eliminate dependency on the MCPD.
ID 486712 Improved the statistics for updating the number of PVA connections when using fastL4.
ID 487554 In this release, reuse of TCP source ports is sequential, which eliminates the issue of TCP source ports being used too quickly on the server side.
ID 487696 Disable channel splitting/division when number of TMMs is odd as while physical platforms guarantee even counts, VCMP (for one) allows configurations which result in an odd number of TMMs, which violates the channel splitting assumptions."
ID 488180 An issue has been resolved which could cause mcpd to continuously restart after a chassis blade replacement.
ID 490480 UCS load now completes successfully if the saved configuration includes FIPS keys with names containing dot ( . ).
ID 490577 An issue has been corrected which could result in the TMM process crashing and leaving a core during process shutdown.
ID 490817 Clear codec alert after propagation so SSL filter doesn't keep reporting alerts indefinitely.
ID 491030 The Nitrox crypto accelerator will no longer hang with certain SSL records.
ID 494029 Console messages about a missing ebtables command no longer appear during BIG-IP system startup.
ID 492367 CVE 2014-8500
ID 494078 Automated Phone Home update check contains strengthened certificate validation, including hostname verification.
ID 494280 Drop the new flow/tunnel and allow it to clean up.
ID 497579 An issue has been corrected which can prevent a vCMP guest from processing SSL and compression traffic.
ID 503237 CVE-2015-0235

Fixes in 11.5.1

ID Number Description
ID 439054 Running 'qkview' from the Primary blade on a chassis based system with more than one blade installed now produces Secondary blades files.
ID 447267 Erroneous "Unsupported power supply" messages have been stopped by a new method of verifying PSU model numbers.
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 446901 The UI now appropriately handles the value range for the Message Cache Size field.
ID 448846 A crash bug related to HSM and memory exhaustion has been fixed.
ID 446402 Deterministic NAT state information will be logged from one TMM when configuration changes.
ID 448299 The emulated IDE storage driver has been replaced with PV (para-virtualized) SCSI storage driver. PV SCSI driver gracefully handles disk I/O timeouts and recovers from them.
ID 449330 Extract NAT information from previous version base on static file.
ID 449402 The correct ha-group failover type is now correctly associated with the traffic-group.
ID 449769 L4 mirrored connections are no longer aborted on the first failover to a Big-IP.
ID 449852 A statsd memory leak related to vCMP has been fixed.
ID 450156 Prevent install failure by always using target installation to get kernel version information.
ID 442034 SSL persistence allows clientside to complete before closing.
ID 450174 A reference counting problem related to CMP flows on a chassis has been corrected.
ID 450839 The 11000 and 11050 platforms now boot correctly with updated hotfixes. You can check the associated hotfix notes to ensure the fix is incorporated.
ID 450665 "If an unexpected connflow is matched, that connflow is abandoned with an error message similar to: Clientside flow (10.10.10.211:34827 -> 10.10.20.7:34827) found, but is not of PPTP GRE proxy type. Creating new flow. Then a new, correct connflow is created and used."

Fixes in 11.5.0

ID Number Description
ID 223684 Toggling between Advanced/Basic mode now correctly shows and hides RADIUS and Diameter profile settings.
ID 242715 We now flush L2 forwarding tables on failover for vlans in vlangroups.
ID 248216 The SOAP monitor now allows configuring the SOAPAction HTTP header. This allows specifying the intent of a SOAP request in the form of a URI, as documented at [1]. The default value is the empty string (the header is still sent, but with no content).
ID 273195 "A new command has been created to enable or disable logging. The attribute is applied to the node or pool_member and is not saved to the configuration nor does it sync. Logging is continuous, and the file(s) are rotated and compressed regularly. The logs are stored in /var/log/monitors, while the old logs (such as bigdlog and monitor debug) remains consistent in behavior and location. To configure: TMSH ----------------------------------------------------- tmsh modify ltm node <name> logging enabled tmsh list ltm node <name> tmsh modify ltm pool <name> members modify { <name> { logging enabled } } tmsh list ltm pool <name> GUI ----------------------------------------------------- nodes >> node >> Logging pool >> members >> member >> Logging iControl ----------------------------------------------------- bigip.LocalLB.NodeAddressV2.set_monitor_logging_state(nodes=['/Common/172.27.92.215'], states=['STATE_ENABLED']) bigip.LocalLB.NodeAddressV2.get_monitor_logging_state(nodes=['/Common/172.27.92.215']) bigip.LocalLB.Pool.set_member_monitor_logging_state(pool_names=['/Common/p1'], members=[[{'address':'1.1.1.1', 'port':'80'}]], states=['STATE_ENABLED']) bigip.LocalLB.Pool.get_member_monitor_logging_state(pool_names=['/Common/p1'])"
ID 352848 HTTP::payload command now includes the proper data, and no additional data.
ID 353101 The system now handles the NULL, and SQL monitors do not hang. No workaround is necessary.
ID 353853 Retries have been added for the floating cluster member management address set request until it succeeds, or the primary switches.
ID 357536 HTTP::respond, HTTP::close and HTTP::disable now will work within an early server response. HTTP::collect and HTTP::retry still are non-functional.
ID 362984 When running the command 'tmsh modify sys global-settings mgmt-dhcp enabled', the system now posts the message 01071662:3: DHCP is not supported on this platform
ID 364814 Improvements in strict ipv6 compatibility and standards compliance.
ID 365472 IPv6 traffic from the Linux kernel will now use the correct source address as the routing decision in the kernel been disabled and only TMM does the routing.
ID 370561 In tmsh, setting /ltm/profile/one-connect/<one connect profile>/share-pools to enabled from the default of disabled allows sharing of node pools among virtual servers with the specified OneConnect profile.
ID 370941 Subject Alternative Name now accepts email address, URI, IP addresses including DNS names as valid input.
ID 372597 The merged process no longer takes most of the CPU.
ID 383767 SSL handshake referencing SSL certificate/key pairs on the Thales HSM no longer fail, and now operates correctly.
ID 384111 The iRule 'nexthop' command now updates only 'nexthop' for the connection, and no longer overwrites the selected remote node's address.
ID 385612 The HTTP::host iRule command has been improved so that 'HTTP::host www.example.com' will set the host header to www.example.com
ID 385615 The HTTP::query iRule command has been improved so that 'HTTP::query example_query=value' will set the query in the uri to 'example_query=value'
ID 389180 "Prior to 11.5, one could not configure the DSCP bits in the IP header. To configure the new attribute: TMSH: ----- tmsh create ltm monitor http ht1 ip-dscp <value> GUI: ---- monitors >> monitor >> IP DSCP iControl: --------- New monitor parameter 'type', 'STYPE_DSCP'. Can be used with: LocalLB.Monitor.set_template_string_property LocalLB.Monitor.get_template_string_property"
ID 389325 "This release adds four BigDB variables to control the behavior of the HTTP filter when it encounters invalid HTTP traffic. These new options are disabled by default. Important: The last three of these should be used only in a transparent proxy configuration. No checking is done once the HTTP filter switches to pass-through mode, and arbitrary traffic could proceed down the now open tunnel. Tmm.HTTP.passthru.truncated_redirect - For invalid HTTP redirects with missing trailing carriage returns, forwards the redirects to the client instead of dropping them. Tmm.HTTP.passthru.invalid_header - For traffic with invalid HTTP headers, passes through the traffic instead of dropping it. Tmm.HTTP.passthru.unknown_method - Treats unknown HTTP extension methods as 'invalid.' You can combine this method with the previous flag to cause unknown HTTP extension methods to be passed through. Tmm.HTTP.passthru.pipeline - Upon receipt of pipelined data, the HTTP filter switches to pass-through mode. This is useful when HTTP non-compliant traffic breaks the request-response idiom, for example, by sending binary data after a GET, and expecting that the data is sent to the server before that server responds to the earlier GET request."
ID 391165 The last sync type field now differentiates properly between incremental and full load synchronizations.
ID 392368 Enterprise Manager now supports statistics collection for managed BIG-IP pool members that have the any port designated.
ID 396489 Policies can set an internal virtual server and enable adaptation, and adaptation now occurs correctly.
ID 396915 The error message will still be displayed when the malformed packet is sent, but it will no longer crash the utility.
ID 400007 MCP validation has been added to prevent user from modifying the netmask. Kernel does not lose the IPv6 self IP address.
ID 402412 FastL4 no longer switches to idle timeout before data is received, so the 5-second tcp handshake timeout holds until the first data arrives, at which time it switches to idle timeout.
ID 403569 Can now create an internal virtual server in a different partition than the wildcard virtual.
ID 403758 BFD protocol configured for IS-IS over IPv6 addresses is able to establish a session with its neighbors.
ID 404134 In this release, modifications to the base profile will sync to peers.
ID 405053 Reduced error rate reading LOP CPLD sensors.
ID 406159 "In addition to reporting to the UIs which monitor produced the down result, it also reports what and when the last error encountered by the monitor as well as time since the last state change. TMSH ----------------------------------------------------- tmsh show ltm monitor <monitor type> <monitor name> GUI ----------------------------------------------------- pool >> pool members >> member >> Availability nodes >> node >> Availability"
ID 408761 Faulted message no longer occurs when a PSU is removed or the power cable is removed.
ID 408950 VIPRION P8 chassis firmware update now completes successfully when using serial port redirection.
ID 408950 VIPRION P8 chassis firmware update now completes successfully when using serial port redirection.
ID 409219 IPv6 packet reassembly now succeeds.
ID 410285 Optimizations made to tmsh significantly reduce the time required to save a huge configuration.
ID 411886 Replacement operations on the allow-service field of self IP addresses now function properly.
ID 412642 When the configuration of the floating management is handled internally, wipe out all other mgmt ip addresses and reprogram the floating ip as primary.
ID 413236 We now successfully resume SSL sessions with SSL profile names >=32 bytes.
ID 413354 Some excessively quick port reuse conditions are now fixed.
ID 414245 TMSH 'edit /ltm virtual' command now populates editor with appropriate content.
ID 414967 dnatutil will now properly warn when doing reverse lookup on address outside of one-to-one mapping range.
ID 415072 The spurious Latched Event log entry that indicates a power system fault no longer occurs.
ID 415714 DNS Cache now correctly truncates responses (for non-EDNS0 queries) to 512 bytes.
ID 415823 This race condition no longer exists. The BIG-IP will always use an encrypted connection from a the configsync-ip.
ID 415991 Active FTP works when there is no route back to the client.
ID 415995 Asymmetric profiles (one side UDP and the other TCP) were not working if the server-side profile was UDP. This has been corrected.
ID 416693 Beginning with software version 11.4.1, the ACPI _SDD operation fails silently, which is the correct behavior. The original diagnostic that produced the message was incorrect, and has been corrected with new, correct diagnostics.
ID 416803 The connection service now ignores excessive concurrent connection requests to the same address.
ID 416991 DEFAULT cipher string in SSL profiles will not include any SSLv3 cipher suites.
ID 417357 dnatutil can now use Syslog, Splunk log, and LTM logged deterministic NAT configurations for reverse mapping.
ID 417956 BIG-IP CGNAT will now translate the internet host IPv4 address into an IPv6 address using the IPv6 prefix from the virtual server.
ID 418495 Validation login on the BIG-IP system now handles files with names matching the pattern: *.sw[pno]. Unrecognized files with names not matching this pattern still require the workaround of removing and retrying the upgrade operation.
ID 418552 Erroneous sensor fault log messages no longer occur on system boot.
ID 418781 The TMM has been fixed to delay linking child route-domains until all the RD's are loaded.
ID 419036 HTTP iApps now correctly configures Slow Ramp Time when it is set to a non-default value in advanced configuration mode. Affected iApps are f5.http, f5.bea_weblogic, f5.microsoft_iis, f5.microsoft_sharepoint_2010, f5.oracle_as_10g, f5.oracle_ebs, f5.peoplesoft_9, f5.sap_enterprise_portal, and f5.sap_erp.
ID 419082 Voltage out of range warnings are no longer logged inappropriately for DC power supplies in BIG-IP 2400 chassis.
ID 419297 CGNAT now works correctly when total of the addresses in the virtual server source prefix and the translation prefix is greater than 8 million.
ID 419730 A defect in the handling of FTP traffic that led to TMM panics has been corrected.
ID 419969 BIG-IP no longer uses different source IP addresses for the Passive FTP data and control connections for virtual servers with an FTP profile and SNAT pool configured. Specific members of a snatpool can also now be selected in an iRule.
ID 420131 "Fixed a TMM core that could occur while processing certain connection teardown scenarios for virtual servers with a DNS profile. The following log message could indicate that this was encountered: 'Assertion 'valid pcb' failed'."
ID 420157 The system now checks for a NULL destination when creating a sideband connection variable in an iRule, and TMM no longer cores.
ID 420188 This release corrects the issue in which mcpd failed to synchronize a device group and logged the message indicating that the sync for the device group was already in progress to a different device. In this release, the system does not block a load when another load is already in progress.
ID 420200 More types of DNS messages are now passed through the BIG-IP system, so that, for example, the DNS_UPDATE response (which is a valid header-only DNS message) is correctly passed through without processing.
ID 420283 When a VXLAN tunnel is created, the two db variables are enabled automatically.
ID 420330 Fixed an issue on TMM SSL traffic handling to avoid crashing when TMM memory is exhausted.
ID 420475 Static routes created via tmsh or the web UI are now correctly propagated to ZebOS.
ID 420498 If a query that does not have the RD bit set is answered by a virtual server with transparent cache enabled, a subsequent query for the same query name with RD bit set will get a correct answer.
ID 420573 FIPS exported (.exp) keys containing colons in the keyname can now be successfully imported into the FIPS card using tmsh.
ID 420585 An occasional TMM crash when using a DNS cache resolver or validating resolver has been corrected.
ID 420723 In this version of software, the cluster synchronized configuration files have version control, so that a new blade or guest slot's configuration cannot overwrite the higher version of any existing configuration on any potential cluster primary member.
ID 420789 The standby system no longer crashes in a configuration containing a forwarding virtual server with a wildcard IP address and port, with connection mirroring enabled.
ID 420941 A potential TMM crash in low-resource situations with persistence cookies no longer occurs.
ID 421066 Syncs previously would fail if another sync was already in progress; this has been fixed.
ID 421117 Handling SSL traffic with a SAML Access profile on a BIG-IP 2000-series or 4000-series platform no longer causes TMM to core.
ID 421124 Role change is now updated in EM/BIG-IP system SSO setup
ID 421145 Systems with many hundreds of active server-side flows on the affected thread no longer result in port exhaustion.
ID 421171 SNMP OID now shows the correct treadstone variant for FIPS and SSL.
ID 421181 An issue is now fixed where newly created subfolders may fail to sync after an upgrade.
ID 421270 "Made the parameter (shutdown-timeout) configurable Default value is 5 seconds tmsh list ltm profile mblb all-properties"
ID 421289 Properly warn users when an invalid ceiling is configured in a parent rate class.
ID 421349 Using Enterprise Manager to manage HA pairs with FIPS no longer causes key handle mismatches.
ID 421528 ICMP messages are no longer reassembled when going through vlan group and original fragmentation is preserved.
ID 421567 The UI.logaccess DB variables used to control role-based access to the System Logs in the GUI now persist after reboot.
ID 421571 HTTP::respond with a zero-length body now works correctly with SPDY.
ID 421614 Handling of qnames in DNS requests has been made more robust.
ID 421648 Documentation now contains correct values for the 'Machine Info' agent.
ID 421670 Observe that TMM does not crash when plugins are in use and traffic exercises them.
ID 421721 With this fix, we ensure that SDN license is required in order to use VXLAN.
ID 421868 Firewall policy objects are now manageable through XConfig interface.
ID 421882 ospf6d no longer crashes while attempting to remove redistributed routes during failover.
ID 421886 MCPD will no longer crash when completing a file_sync operation. Steps were taken to ensure that the references to deleted information were removed.
ID 422082 tmrouted will no longer core
ID 422105 Transparent DNS Cache no longer inserts a truncated response into the cache.
ID 422330 A flaw has been fixed that would cause tmm to crash with compression enable under a particular corner case involving an aborted or dying flow.
ID 422359 The TMM no longer crashes when stalled SPDY streams are aborted.
ID 422471 alertd was missing requisite configuration and error map files. Those mappings are now populated and the traps should work.
ID 422630 Use the default port suggested by the RFC for VXLAN profile.
ID 422731 The management IP address now persists across reboots when configured via front panel LCD.
ID 422808 The connection to a down port specific virtual server is no longer answered by the next less specific port.
ID 422897 FTP will work in case of port translation is needed.
ID 423067 DSLite hairpinned connections now allow traffic to flow through.
ID 423115 mcpd no longer cores when virtual servers in a traffic group have non-floating ip address.
ID 423215 DH-anon (ADH) key exchange is now supported in NATIVE cipher suites instead of COMPAT.
ID 423306 CGNAT in deterministic mode translation will no longer fail and use the backup pool.
ID 423487 tmsh will no longer display an incorrect warning when validating an iRule that uses the recv command.
ID 423818 ICMP packet now gets reassembled only when 'reassemble-fragments' is enabled.
ID 423834 tmsh list with the one-line option now displays on one line for all objects as expected.
ID 423876 HTTP iApps now correctly configure Priority Group Activation (PGA) when it is selected. Affected iApps are f5.http, f5.bea_weblogic, f5.microsoft_iis, f5.microsoft_sharepoint_2010, f5.oracle_as_10g, f5.oracle_ebs, f5.peoplesoft_9, f5.sap_enterprise_portal, and f5.sap_erp.
ID 424031 An issue was fixed where CGNAT in Deterministic NAT translations were not using all the translation addresses and ports configured.
ID 424035 Allow pool member and node ratios greater than 100. With this fix, ratio values between 1 and 65535 are supported.
ID 424060 SPDY no longer causes a core in certain low-memory situations.
ID 424173 Network device configuration no longer cause some of the directories under /sys/class/net to become unreadable.
ID 424248 Virtual servers with the same ip address and port but different vlan assignment now successfully bind to tmm and process traffic as expected.
ID 424322 Re-designated an empty SFP port as capable of all media the MAC knows how to support until a PHY is installed. Trunks may now contain empty SFP ports on 2x00/4x00 platforms.
ID 424345 An issue has been resolved with the command 'tmsh load sys config verify' where the system may reboot into vCMP mode if the configuration being verified has a different vCMP provisioning level than the current running configuration.
ID 424379 Configuring BIG-IP with many FIPS keys no longer causes TMM to constantly reset.
ID 424561 Virtual server configured with preserve_port_strict now functions correctly with CMP.
ID 424728 BGP address-family IPv6 configuration is correctly saved.
ID 424822 OSPFv3 now retains non-default metric/metric-types for redistributed protocols when a unit transitions from active to standby.
ID 424842 UI escapes the ampersand sign in the certificate fields to prevent improper interpretation of symbol.
ID 424901 Introduced improvements in strict ipv6 compatibility and standards compliance.
ID 424972 All requested hardware devices are now assigned to the vCMP guest.
ID 425028 The BIG-IP configuration will have correct failover traffic group assignment for the "/", "/Common" and other non-default system folders.
ID 425033 Validation will now prevent LSN pools with overlapping prefixes from being configured.
ID 425182 Improvements have been made to the way the system handles memory pressure, so the system does not slow down or become unstable.
ID 425250 TMM no longer crashes when using iRule parking commands with Datagram Load Balancing. This version silently drops any datagrams received after the first response datagram is egressed to the client.
ID 425333 Fixed an issue on ProxySSL with Stratos and VE platform during SSL renegotiation.
ID 425382 Improvements in strict ipv6 compatibility and standards compliance.
ID 425495 Private tmsh aliases no longer cause sync failures.
ID 425525 The system now correctly performs a slow-start when serving from cache, which results in correct buffering and traffic handling.
ID 425580 By setting the confg.allow.rfc3927 database variable to 'enable,' addresses in the 169.254.0.0/16 range can be configured on a BIG-IP.
ID 425589 Improvements in strict ipv6 compatibility and standards compliance
ID 425594 Added an option (generic-alert) to client-ssl/sever-ssl profile, when generic-alert is set to TRUE, the BIG-IP system keeps the current implementation and sends all fatal-level Alert message with 'handshake failure.' Otherwise, the system sends the correct Alert message. The default is set to TRUE.
ID 425597 If (NATIVE+COMPAT) has overlap, SSL will now use NATIVE, not COMPAT.
ID 425670 You are now able to delete a wide IP in the LC web interface.
ID 425878 Loading a configuration with vcmp guests no longer causes incorrect guest settings.
ID 425953 The commit ID is now synchronized to secondary blades of a chassis; a sync will not be required if a different blade becomes primary.
ID 425974 HTTP::respond and HTTP::redirect respect the max_requests limit, closing the connection to the server when it is reached.
ID 426197 The maximum number of entries in the session cache is now configurable via the BigDB variable tmm.ssl.cachesize. Note that after changing this variable the TMMs must be restarted for the new value to take effect. The per-profile limit is now per TMM so if the limit is set to 32K entries, each TMM will be allowed to have 32K entries.
ID 426332 Rules and objects now appear correctly in the new partition.
ID 426341 BIND has been updated to address CVE-2013-4854.
ID 426373 OSPFv3 external (type 5) LSAs originated by TMOS contain a route tag only when a route tag is configured.
ID 426508 default-information originate' in OSPFv3 now correctly detects the additional and deletion of a default route.
ID 426570 tmm no longer leaks 'source address' memory.
ID 426625 The system no longer returns an error when a user tries to update a Data Group of type 'string' or 'integer' that have records containing a String but not a Value.
ID 426704 vCMP guest no longer gets stuck in waiting-install when all resources are in use.
ID 426802 Improvements in strict ipv6 compatibility and standards compliance
ID 426992 When more than one self IP is configured, those self IPs now correctly listen on default ports.
ID 427002 If a self-ip has the 'default' list included in the allow-services, then the system will validate all the other entries against the 'default' list. The tmm is now protected from an incorrect configuration with duplicated entries.
ID 427026 tmm no longer crashes with an assertion failure when duplicated flow_remove is called in software when error was encountered during traffic process.
ID 427071 Resolved issue preventing GUI from displaying traffic selector list.
ID 427077 "An option has been added to the TMSH config installation command that can be used to reset keys and certs associated with the trust domain. The option name is 'reset-trust' and it can be specified on the command line when manually loading a UCS file in TMOS. This command can be used to mitigate the problem of a UCS file not loading because of missing or incorrectly formed trust certs or device keys. To regenerate the trust-related certs and keys while loading an affected UCS, run the following command: tmsh load sys ucs <UCS File> reset-trust. Important: running this command on a device that is part of a trust domain requires the device to rejoin that trust domain."
ID 427085 BIG-IP sets the correct protocol version in Alert message when it receives a ClientHello with an unsupported protocol version.
ID 427092 The BIG-IP system now sends a fatal-level Alert message when it receives unsupported_certificate type. This is correct behavior.
ID 427107 deterministic NAT LTM logged configuration snippets will no longer truncate needed information when LSN Pool name is longer than 20 characters.
ID 427112 For SSLv3, A no_certificate alert message is now sent in response to a certification request if no appropriate certificate is available.
ID 427118 BIG-IP now sends correct TLS alert messages in handshake failure modes.
ID 427201 The http-set-cookie action in an ltm policy now correctly uses the domain and path parameters when generating a Set-Cookie header. It is no longer possible to use the http-set-cookie actions without supplying a value.
ID 427239 The default node monitor now syncs even when full-load-on-sync is false on the failover device group.
ID 427342 If you filter by the Status column under Local Traffic > DNS Express Zones > DNS Express Zone List, the page now correctly renders without error.
ID 427357 The icmp-echo property is now set correctly for virtual addresses with network prefixes.
ID 427423 "HTTP now recognizes that 'generic' iRule commands can be executed on both the request and response. Instead of failing when the http_data structure ownership status is mismatched, HTTP will execute the iRule command. The remaining 'non-generic' HTTP commands that will still fail are: HTTP::version HTTP::collect HTTP::release HTTP::redirect HTTP::respond HTTP::retry HTTP::close HTTP::header insert_modssl_fields The commands that must be invoked in a request are: HTTP::method HTTP::uri HTTP::path HTTP::query The commands that must be invoked in a response are: HTTP::status HTTP::is_redirect This means that HTTP commands can now be executed in many more events. (Those raised by other filters.)"
ID 427448 The memory leak no longer occurs in the MCPd process, so that the previously memory exhaustion no longer occurs.
ID 427475 CGNAT: TMM no longer cores when running low on translation addresses and ports.
ID 427607 The fix is to modify the polling behavior in the quickassist driver to allow more efficient handling of hardware compression requests.
ID 427687 policy action 'server-ssl disable' now works correctly.
ID 427736 Occasional possibility of a TMM crash during sFlow sampling of HTTP traffic no longer occurs.
ID 427791 During rekey, there will not be leftover invalid security associations for IPsec tunnel between BIGIP and Fortigate firewall and traffic won't be stale for a prolonged period of time.
ID 427840 HSL log entries for deterministic NAT now contains unix-time, which can be use by dnatutil without timezone conversion.
ID 427886 You can now set a rule on a virtual server using iControl/REST.
ID 427928 "If the default LTM Policy, '_sys_CEC_video_policy', was modified using the GUI, the changes were not persisted (saved to /config/bigip.conf) and will be lost if 'load sys config' is executed or during an upgrade. If modification was done with TMSH, the changes were persisted. It is a good practice to clone the default configurations and make modifications on the clone as well as assign the cloned configuration to the virtual server instead of the default configuration. TMSH can be used to force persistence. For example a TMSH command to 'modify ltm policy _sys_CEC_video_policy strategy first-match' (or any modification even if it doesn't change the configuration value) followed by 'save sys config' causes the setting to be saved in bigip.conf."
ID 427952 Memory during load operations is properly re-claimed.
ID 427956 The system now properly reclaims the memory during load operations.
ID 428066 IPv6 router advertisement now works in vlan group.
ID 428153 TMUI -- Gateway Failsafe now properly rendered in IE
ID 428161 It is now possible to add a non-CA device to a trust domain.
ID 428405 Fixed a slow memory leak with client and server ssl profiles in mcpd.
ID 428494 A loss of high configuration data after loading bigip_base.conf has been largely corrected. Some scenarios still exist, however.
ID 428631 DWR now uses rewrite attributes configured in the Diameter profile (for example, origin-host-to-client, origin-host-to-server, origin-realm-to-server, and origin-realm-to-server).
ID 428642 A tmm crash bug has been resolved.
ID 428706 False positive messages warning of 100% CPU use have been corrected.
ID 428735 A TACACS+ system auth and file descriptors leak has been corrected.
ID 428750 changing LSN Pool translation-port-range for LSN Pool of deterministic mode will correctly trigger logging of deterministic NAT state information
ID 428884 Modified MBLB proxy to correctly detect irule running state.
ID 428895 The return value of the iRule 'active_members' command now matches the length of the list returned by the 'active_members -list' command, whether or not priority groups with minimum active members is configured on the pool.
ID 429114 Monitors now send traffic using the correct source address for the egress interface and do not falsely mark available pool members as down.
ID 429122 Even when there is corruption, istatsd will no longer use an excessive amount of CPU.
ID 429124 "This release adds support for accelerating connections that do not always use autolasthop but instead use a lasthop pool with a single member. The process now allows accelerating traffic from vlangroup members as long as those members are vlans."
ID 429393 11.4 now handles L7 policies created in 10.x that are stored in partitions that refer to pools with no partition.
ID 429396 HTTP Class profiles from previous versions may have url formats that are now invalid. If these profiles have urls that do not start with a http:// or / https://. Loading a configuration with such profiles now provides a descriptive error message and omits the profile.
ID 429429 Disabling plugins programmatically is now supported, and TMM memory use does not increase with traffic that would otherwise involve those plugins.
ID 429699 For translucent vlan groups, allow standby stratos in ha pair to use local vlan FDB entry for bridging the traffic between two interfaces on a child vlan in the given vlan group.
ID 429770 The pool now goes unavailable and comes back available.
ID 429827 recv command now checks timeout after check data received so good data received just before timeout is not discarded.
ID 429832 vCMP guest tmms will no longer report errors about missing external interfaces on trunks passed in from the hypervisor.
ID 429952 tmm no longer loops with plugin errors.
ID 429960 When a lookup fails is aborted, report that the lookup failed, instead of assuming a lookup always succeeds.
ID 429975 "OCSP Responder Timeout value has been made configurable to meet the required timeout values at site. #tmsh modify sys httpd ssl-ocsp-responder-timeout 500 Also as an other alternative you could try the following # tmsh modify sys httpd ssl-include ' SSLOCSPResponderTimeout 500'"
ID 430090 In OSPFv3, the standby unit no longer advertises the default route when 'default-information originate' is configured.
ID 430104 iControl fixed to not report error when done from localhost.
ID 430108 Connection limits are now managed correctly on the standby device so that connection limits are not exceeded erroneously.
ID 430114 The lsndb delete command has been updated to work correctly on chassis based systems.
ID 430728 Resolved an issue that would cause TMM to crash if a TCP iRule is suspended with an error while the peer sends a packet.
ID 430768 The system now detects changes in a parent profile (the one specified in 'defaults-from') and runs validation to ensure the new inherited values are acceptable on the child profile.
ID 430905 Policy sync now works with more than two devices.
ID 431141 This race window had been fixed properly and customer need to install recent patch.
ID 431251 IPSEC GUI now supports phase1 encrypt alg aes192 or aes256
ID 431305 Fixed TMM crash that could occur in rare instances of iSession use.
ID 431503 TMM no longer crashes on neighbor messages during the initial tunnel config load process.
ID 431618 Fixed a relatively rare coring condition where the SIP filter would access memory that was already freed.
ID 431635 SIP connections with MBLB+OneConnect are no longer being terminated upon failure to send/connect to the client.
ID 431667 Fixed the show cm device-group option that would intermittently specify incorrect options.
ID 431990 The TCL 'table' command now works correctly with SPDY.
ID 432208 The websecurity profile must be attached to a Virtual Server before you can attach an LTM policy that controls ASM. If you attach and detach LTM policies controlling ASM in the GUI that attach/detach will be done automatically for you. If you remove the policy with TMSH, the websecurity profile will remain attached. In the next release, the GUI will detect an existing websecurity profile and not attempt to add it again to avoid the validation error.
ID 432285 Configurations from releases prior to 11.3.0 which have routes named by their IP address will now load on upgrade.
ID 432492 The BIG-IP system transmits IPv6 BFD for single-hop sessions with a hop limit value of 255.
ID 432567 You can now set up sync between devices in two different time zones.
ID 432723 External Datagroup: TMM no longer cores on rapid creation/deletion cycle.
ID 432735 The RST of the two ALG clients no longer happens.
ID 432826 Passive LACP trunks now work upon reboot.
ID 432939 A memory leak in the SASP monitor has been corrected.
ID 433460 Client browser activity no longer causes serverside connection abort. Previously, this could result in pool members being marked down.
ID 433567 INVITEs with c= headers only in the media portion of the SDP message body correctly setup media flows.
ID 434397 Resets do not continue to occur if there is still capacity in low priority pool member.
ID 434515 The system no longer returns a truncated response when both ASM Policy and DOS Profile are assigned to the virtual server.
ID 434533 vCMP guests will now be upgraded into the same vCMP state as the currently running system.
ID 434907 Call from clientA is hairpinned by the BIGIP, a reinvite is sent from clientB, the media flows are properly setted up.
ID 435217 Single hyper-thread VCMP guest's are now manageable under maximum data-plane utilization.
ID 435296 A reset of statistics for a TCP virtual server will no longer cause the counters for the number of open connections, close_wait, fin_wait, time_wait or accepts to remain high.
ID 435407 ssl persistence no longer corrupts application data
ID 435598 The condition which could cause memory corruption in tmm related to the http-set-cookie action in an ltm policy has been fixed.
ID 435855 When a packet is cloned, the original packet flags were preserved. If the original packet was locked, then this flag was propagated to the cloned packet. The fix is to clear this flag in the cloned packet when it is created.
ID 435879 Improvements in strict ipv6 compatibility and standards compliance
ID 435959 The system now correctly handles packets output on members of vlangroups where the packets are cached replies for the same vlan on which the request arrived.
ID 435993 Establishment of CMP-redirected flows no longer erroneously expires/replaces NOEXPIRE flows, so this probably no longer occurs.
ID 436634 tmm won't crash if profile changes and then virtual is deleted.
ID 437006 The tmm now correctly processes large URIs when evaluating conditions of type http-uri in an ltm policy.
ID 437739 TMOS now monitors all tmms for looping/locked on a Centaur/Victoria2 BIGIP.
ID 437866 In this release, the system correctly decrements active jobs counter when this error is detected. CPU no longer runs high, and jobs are assigned to the correct compression queue.
ID 438081 Bug fixed in zxfrd to continue large response processing.
ID 438149 The innocuous message 'interface module id schema mismatch (3 != 0)' will longer be created in /var/log/ltm
ID 438222 The system now will correctly identify the changed configuration components during the modify operation on a built-in policy. The system will save and load correctly now after these modifications.
ID 438622 SFP insertion and removal events are detected automatically on BIG-IP 800 appliances.
ID 438685 Support SHA256/SHA384 sign/verify hash
ID 439048 TCP connections no longer stall when tcpdump is started on the BIG-IP system and tcp segmentation offload is enabled.
ID 439364 Extraneous DNAT log entries are no longer being generated.
ID 440877 Stateless virtual server now properly processes fragmented packets in this case.

Behavior changes in 11.5.2

ID Number Description
ID 487552 You are now allowed to provision any number of combinations of modules on platforms with 5.5 GiB of memory or more so long as there are resources available. Previously, 3 or more modules were not allowed to be provisioned on platforms with 6 GiB or less. Note that Application Acceleration Manager (AAM) cannot be provisioned with any other module; AAM can only be provisioned standalone.

Behavior changes in 11.5.1

ID Number Description
Selective control of ICMP Echo responses You can now configure the BIG-IP system to selectively enable or disable ICMP Echo responses for a virtual address based on the virtual server state that you configure for advertising a route to that virtual address. For example, if you configure the system to advertise a route to the virtual address when any virtual server for that virtual address is available, the BIG-IP system sends a response for an ICMP Echo request only if one or more virtual severs associated with the virtual address is in an Up or Unknown state.
325234 ZebOS is able to obfuscate all password values for BGP, OSPFv2, and IS-IS protocols when displaying or storing configuration via IMI shell commands 'show running-config' or 'write' respectively. Password obfuscation feature can be turned on by enabling 'service password-encryption' in IMI shell config-mode. This feature can be turned off via config-mode command 'no service password-encryption'. However it is important to note that password values that have been encoded will remain encoded even after disabling password-encryption service. Only those passwords configured after disabling this service will appear in clear text as long as password-encryption service continues to remain disabled.

Behavior changes in 11.5.0

ID Number Description
ID 247958 This is a behavior change that affects SSL profile configuration on both clientssl and serverssl. The certificates configured in 'Trusted CA certificates' are not included in the certificate chain that the BIG-IP system sends to the other end, if the SSL profile is configured to request/require a remote certificate. You can configure the certificates in the 'Chain' field instead of 'Trusted CA Certificates' field to include those certificates in this case.
ID 284369 LTM monitor passwords and secrets phrases are now encrypted in the configuration file.
ID 291315

The following sys db variables are no longer supported:

- platform.blade.main1.temperature.threshold

- platform.blade.main2.temperature.threshold

- platform.blade.main.internal.temperature.threshold

- platform.blade.mezz.dag.temperature.threshold

- platform.blade.mezz.hsb.temperature.threshold

- platform.blade.mezz.internal.temperature.threshold

- platform.chassis.temperature.threshold

- platform.chassis1.temperature.threshold

- platform.chassis2.temperature.threshold

If you try to get the value, the system returns a message similar to the following: 01020036:3: The requested BIGdb variable (platform.chassis.temperature.threshold) was not found.

ID 416991 DEFAULT cipher string in SSL profiles will not include any SSLv3 cipher suites.
ID 427154 In software versions earlier than 11.5.0, a device group could be configured so that changes to it were automatically synced to all devices in the group. By design, this synchronization defaulted to not perform a save on the sync target. The /cm trust-domain 'save-on-auto-sync' attribute governed the behavior. Setting the attribute to true instructed the system to perform a save operation on the sync target. Beginning in version 11.5.0, this option is no longer configured as part of the trust-domain, but is part of the configuration of a device group.
ID 427579 HA-Group score no longer includes active-bonus in data returned from command 'tmsh show sys ha-group'. Active bonus is only relevant for the active device of a traffic group.
ID 449402 In 11.5.0, ha-group failover settings are configured per traffic-group. In previous 11.x releases, ha-group settings were per device. When upgrading to 11.5.0, existing HA Group setting might need to be associated with traffic-groups manually. Without setting the traffic-group failover method, the ha-group score and failover cannot function. You can set the ha-group reference manually in the GUI or via tmsh.

Known issues

ID Number Description
ID 221946 01070950:3: Cluster Member IP address 10.0.0.1 is not on the same network as the Cluster (10.0.0.10). This occurs when specifying the cluster management IP address without a netmask. The configured network topology must have enough addresses for the cluster management and member addresses to be configured within the same subnet. Workaround: Always specify the netmask when specifying the cluster management IP address if you plan ever to use cluster member addresses. That way, the address always gets set correctly, and you can configure the cluster member addresses on the same network.
ID 221956 Beginning with version 10.0.0, the system reports module memory mixed in with memory used by all processes. This occurs beginning with version 10.0.0. The system reports module memory mixed in with memory used by all processes. Workaround: To determine actual memory usage, you must use standard Linux commands, such as ps, top, and other similar commands.
ID 221963 When you are logged on to a cluster management address, and you or another user subsequently promotes one of the secondary blades to the primary, you and the other user might need to log on again. This occurs when using cluster management and promoting secondary blades to the primary. You and other users might need to log on again. Workaround: None.
ID 221973 BIG-IP system ignores a pool member's response and marks the pool member down after the configured timeout. This issue occurs when all of the following conditions are met: -- An ECV health monitor such as TCP, HTTP has been assigned to a pool or pool member (Note: HTTPS ECV monitors are implemented differently than HTTP and TCP monitors and are not affected by this issue.) -- A pool member responds after the assigned health monitor has sent three probes to it. The pool member will not be available to serve the clients' requests. For example, if the HTTP monitor is configured with an interval of 5 seconds and a timeout of 31 seconds, and the BIG-IP system receives the pool member's response after the third HTTP monitor probe has been sent, the BIG-IP system ignores the pool member's response and mark the pool member down after the timeout of 31 seconds. Workaround: To work around this issue, you can set the monitor interval to a value greater than the affected pool member's response time under the expected production load. For more information, see SOL9104: The BIG-IP system may ignore a pool member's response to health monitor probes, available here: https://support.f5.com/kb/en-us/solutions/public/9000/100/sol9104.html.
ID 222005 "On boot, the following message might be seen. It is innocuous and can be ignored: err ti_usb_3410_5052.c: ti_interrupt_callback - DATA ERROR, port 0, data 0x6C" This occurs on boot. The system posts the message: err ti_usb_3410_5052.c: ti_interrupt_callback - DATA ERROR, port 0, data 0x6C Workaround: None, but the message is innocuous and can be ignored.
ID 222034 If HTTP::respond is called in LB_FAILED with large headers and/or body, the response might be truncated. The Content-Length header value is correct; it is the content itself that is truncated. This issue occurs when all of the following conditions are met: -- TCP Slow Start is enabled in the TCP profile. -- HTTP::respond is used in the LB_FAILED event to return a large response. -- No other TCP data has been sent to the client. The response sent by the BIG-IP system will be truncated. For example, with slow-start enabled, and no data sent to the client yet, the response will be truncated after two packets. Workaround: To work around this issue, disable TCP Slow Start in the TCP profile, or modify the iRule. For example, instead of directly using HTTP::Respond inside of an LB_FAILED event, perform a 302 Redirect to another URI, which can then be handled by an unaffected event. For more information, see SOL9456: Using the HTTP::respond iRule command in the LB_FAILED event may result in truncated responses, available here: http://support.f5.com/kb/en-us/solutions/public/9000/400/sol9456.html.
ID 222184 When the license expires, if you are on the License Summary page on a partition other than Common, the system automatically returns you to the Common partition, but does not activate the Reactivate button. This occurs if you are on the License Summary page on a partition other than Common The system automatically returns you to the Common partition, but does not activate the Reactivate button. Workaround: The workaround is to select a different partition and then reselect the Common partition. This should reset the Reactivate button to an active state.
ID 222221 The BIG-IP system may fail to complete an SSL handshake. This issue occurs when all of the following conditions are met: -- The affected virtual server is processing the client SSL connection with an iRule. -- The iRule uses the TCP::close command in the CLIENTSSL_HANDSHAKE event. The TCP::close command can be used in the CLIENTSSL_HANDSHAKE event to close the client connection. For example, the iRule closes the client connection if the hostname requested by the client does not match the common name in the SSL cert. As a result of this issue, you may encounter the following symptoms: -- The client SSL connection stalls until the TCP connection is timed out by the BIG-IP system. -- The client SSL connection fails at the Change Cipher Spec Protocol during the SSL handshake. Workaround: To work around this issue, you can insert a delay with the after command for the TCP::close command. Impact of workaround: Depending on the type and volume of the connections, the after command may introduce noticeable latency. F5 recommends that you test any such changes in an appropriate environment. For more information, see SOL14037: The BIG-IP system may fail to complete an SSL handshake , available here: http://support.f5.com/kb/en-us/solutions/public/14000/000/sol14037.html
ID 222287 On multi-core platforms running in CMP mode, rates configured in a rate class are internally divided between the active TMM instances. This occurs on multi-core platforms running in CMP mode. As a result, each flow is restricted to bandwidth equal to the configured rate divided by the number of active TMM instances. Workaround: In order to achieve the actual rate set on the rate class, the system must be processing at least one flow on each active TMM instance. For more information, see SOL10858: Rate classes on CMP systems are divided among active TMM instances, available here: http://support.f5.com/kb/en-us/solutions/public/10000/800/sol10858.
ID 222344 If a route learned via any dynamic routing protocol exactly matches a management static route, traffic from the Linux host will follow the dynamic route. NOTE: Regarding affected modules, the problem affects any module provisioned in TMOS as the root cause is in the core functionality shared by all modules. Dynamic routes might override static management routes. Workaround: There is no workaround.
ID 223031 If you run the tcpdump utility from a B4100 blade on a VIPRION chassis containing a mix of B4100 and B4200 blades, the process does not show packets from the B4200 blades. This happens on a VIPRION chassis with a mix of B4100 and B4200 blades. tcpdump does not report packets from the B4200 blades. Workaround: To work around this issue, run the tcpdump operation from the B4200 blade.
ID 223412 When configuring a ConfigSync peer IP address, the IP address must reside in the default route domain. The default route domain has an implicit value of zero (0). For example: 192.168.20.100%10. "Checking configuration on local system and peer system... Peer's IP address: 192.168.20.100%10 Caught SOAP exception: Error calling getaddrinfo for 192.168.20.100%10 (Temporary failure in name resolution) Error: There is a problem accessing the peer system. BIGpipe parsing error: 01110034:3: The configuration for running config-sync is incorrect. On BIG-IP 11.x, the system returns an error message that appears similar to the following example: err mcpd[5766]: 01071430:3: Cannot create CMI listener socket on address 192.168.20.100%10, port 6699, Cannot assign requested address" ConfigSync operations will fail if you configure a peer address that contains an explicit route domain ID. Workaround: The workaround is to not use route domains for ConfigSync operations. For more information, see SOL12089: ConfigSync operations fail when you configure a ConfigSync peer address with an explicit route domain ID, available here: http://support.f5.com/kb/en-us/solutions/public/12000/000/sol12089.html.
ID 223421 If a disk is removed from an array, the serial number of the disk persists in the system until the drive is manually removed. This occurs on multi-disk systems. The serial number of the disk persists even after the disk is removed from the array. Workaround: There is no workaround for this issue. The serial number of the disk persists in the system until the drive is manually removed.
ID 223426 If you apply to a virtual server a TCP profile with the MD5 signature setting enabled, the virtual server incorrectly accepts connections regardless of whether the peer presents the MD5 option. This affects both client-side and server-side connections. Note that the problem does not affect TCP connections established from the BIG-IP host (for example, BGP connections). Enabling the TCP option for MD5 signatures does not cause TCP connections without MD5 signatures to be rejected or ignored. However, when the MD5 signature setting is enabled, and an MD5 signature is present, the MD5 signature is validated. The MD5-configured virtual server incorrectly accepts connections regardless of whether the peer presents the MD5 option. Workaround: None. For more information, see SOL12241: A virtual server with the MD5 signature setting enabled in its TCP profile does not reject or ignore non-MD5 optioned connections, available here: http://support.f5.com/kb/en-us/solutions/public/12000/200/sol12241.html.
ID 223542 You cannot simply change the speed of an existing interface in a trunk. This occurs when you change the speed of an existing interface in a trunk. You cannot change the speed. Workaround: You must either delete all the interfaces and add them back at the new speed, or delete the trunk and recreate it.
ID 223634 The Traffic Management Shell (tmsh) may not display dynamic Address Resolution Protocol (ARP) entries as expected. In BIG-IP 11.x, the show net arp Traffic Management Shell (tmsh) command displays dynamic ARP entries for all route domains. Additionally, you can display dynamic ARP entries for specific route domains by using the show arp any %<route domain id> command; however, you cannot specify the default route domain 0. In BIG-IP 10.x, the show net arp Traffic Management Shell (tmsh) command displays ARP entries for only the default domain. This issue occurs when you have a BIG-IP system with more than one route domain configured, and you view dynamic ARP entries using tmsh. ARP entries appear to be missing for route domains other than the default (BIG-IP 10.x). The system is unable to display only those dynamic ARP entries specific to the default route domain 0 (BIG-IP 11.x). Workaround: If you are in the tmsh utility (in 10.x or 11.x), you can run the bigpipe utility to view dynamic Address Resolution Protocol (ARP) entries for a different route domain. To do so, run the command run until bigpipe arp <args...> at the tmsh command line. For more information, see SOL12623: The Traffic Management Shell may not display dynamic ARP entries as expected, available here: http://support.f5.com/kb/en-us/solutions/public/12000/600/sol12623.html.
ID 223651 An SSH File Transfer Protocol (SFTP) client might emit an error message containing 'Received message too long' when the user is unprivileged and may not use SFTP. This occurs when using a user with insufficient privileges uses SFTP. 'Received message too long' posted for SFTP client when the user is unprivileged. This is a known issue with SSH. For more information, see 2.9 - sftp/scp fails at connection, but ssh is OK, available here: http://www.openssh.com/faq.html#2.9. Workaround: The user must be authorized to use SFTP/SCP.
ID 223796 When an SFP is not inserted in a VIPRION interface socket, the interface status should show 'MS' (missing); instead, the interface status might show 'DN' (down). This occurs on a VIPRION chassis where there is no SFP in the interface socket. The interface status might show 'DN' (down). Workaround: None.
ID 223830 It is possible that with increased throughput, SNMP stats might report lower TMM CPU usage values than top. This occurs when using SNMP stats. SNMP stats might report lower TMM CPU usage values than top. Workaround: None. Overall host CPU usage is being reported correctly all the time. This is a cosmetic issue only.
ID 223885 If you apply a hash persistence profile to a FastL4 virtual server, the virtual server stops processing traffic. Note: The hash persist profile was extended in 10.0.0 with new options, but is no longer supported in combination with FastL4 virtual servers. In addition, when the hash persistence profile is initially applied and during each subsequent configuration load, the BIG-IP system logs messages to the /var/log/tmm file: notice hudfilter_init: 'HASH' is not a bottom-level filter. ... mcp error: 1031000 in mcpmsg_to_database. This occurs when using hash persistence profile with FastL4 virtual servers. FastL4 virtual servers stop processing traffic after a hash persistence profile is applied. Workaround: The workaround is to use universal persist instead. You can also use the TCP or UDP profile instead of FastL4. If a hash persistence profile was applied to a FastL4 virtual server, you can restore traffic by deleting and recreating the virtual server. For more information, see SOL12078: FastL4 virtual servers stop processing traffic after a hash persistence profile is applied, available here: https://support.f5.com/kb/en-us/solutions/public/12000/000/sol12078.html.
ID 223954 The system does not include the .tmshrc file in a ConfigSync operation. This occurs in config sync operations. That means that each unit in a high availability configuration might have a different set of remote users. Workaround: To work around this, you can manually sync the files by using a utility to copy the file from one system to the others.
ID 224073 Pinging the floating self-ip from the command line of the same system results in a no response to the ping. This no-response reply does not indicate that the floating self-ip is not working and is not responding to normal ping operations. This occurs when the floating self-IP tries to ping from the BIG-IP system command line This results in a no response to the ping. Workaround: To work around this, issue the ping from another host in the network.
ID 224142 There is a pause negotiation mismatch in a trunk containing a mix of fiber and copper. To work around this issue, do not mix fiber and copper in the same trunk. This occurs in a trunk containing a mix of fiber and copper. A pause negotiation mismatch occurs. Workaround: To work around this issue, do not mix fiber and copper in the same trunk.
ID 224195 The system does not prevent you from deleting a self IP address that an EtherIP tunnel uses, or from creating an EtherIP tunnel using nonexistent IP addresses. But the resulting tunnel remains inoperable. This occurs when deleting a self IP address that an EtherIP tunnel uses, or creating an EtherIP tunnel using nonexistent IP addresses. Doing so results in an inoperable tunnel. Workaround: To ensure that an EtherIP tunnel operates as expected, do not delete any of the self IP addresses that are associated with VLAN "wan" and specified in the EtherIP tunnel object.
ID 224294 SASP monitor validates timeout and interval although these values are not used by the monitor. This occurs when using SASP monitor timeout and interval. This causes certain SASP monitor configurations not to load. Workaround: None.
ID 224372 When you are connected using the serial console to a multi-drive platform, you might see messages similar to the following: warning kernel: RAID1 conf printout and warning kernel: disk 0, wo:0, o:1, dev:dm-14. The messages are also logged in /var/log/kern.log file. This occurs when you are directly connected by serial console of a multi-drive system. These messages appear during the time a drive is rebuilding. Note that the messages appear only when you are directly connected by serial console. They do not appear when you are logged in using SSH. Workaround: This messages are benign, and you can safely ignore them.
ID 224402 When you specify a custom configsync user (that is, an account other than admin), if you have specified a maximum number of password failures, the configsync account is subject to the password lockout after the specified number of failures. This occurs for configsync users when maximum password failure is set. The configsync account is subject to the password lockout after the specified number of failures. Workaround: To work around this issue, use the admin account as the ConfigSync user, or reset the non-standard account that is locked out.
ID 224406 The dashboard cannot handle numbers that exceed 32 bits. If a statistic goes above that number, dashboard values will be incorrect. This occurs dashboard and numbers that exceed 32 bits. When this occurs, there will be incorrect dashboard values. Workaround: There is no workaround.
ID 224520 The bcm56xxd service's small form-factor pluggable (SFP) plug_check mechanism (for example, bs_i2c_sfp_plug_check()) looks for module-detect signal changes every five seconds, and can miss a pluggable media type swap (that is, a swap from fiber SFP to copper SFP or SFP+) because the check does not look at pluggable media type changes. This occurs when changing pluggable media. This can result in link failures, due to internal media settings that are still associated with a previously populated pluggable module. Workaround: None.
ID 224665 The Proxy Exclusion List setting is not aware of administrative partitions. As of BIG-IP 10.1.0, VLAN group objects reside in administrative partitions. This means that you can create a VLAN group in an administrative partition, and then give users the authority to view and manage the object in only that partition. Proxy exclusion is a VLAN group setting, so the partition restrictions should be in effect. However, the system does not prevent you from adding proxy exclusion for a VLAN group in another partition. Doing so may result in issues for the VLAN group. Using VLAN groups and proxy exclusion. Results in issues for the VLAN group Workaround: None. For more information, see SOL12711: The Proxy Exclusion List setting is not aware of administrative partitions , available here: http://support.f5.com/kb/en-us/solutions/public/12000/700/sol12711.html.
ID 224680 When you use the Wireshark program to view a packet from an EtherIP tunnel, the Wireshark program displays the EtherIP version as 0 rather than 3, as it should. This occurs because Wireshark evaluates the version based on the bottom four bits rather than the top. The Linux EtherIP implementation follows the same format used by coding developer David Kushi, which is correct according to RFC 3378 - EtherIP: Tunneling Ethernet Frames in IP Datagrams. This occurs when using Wireshark program to view a packet from an EtherIP tunnel. Wireshark displays the EtherIP version as 0 rather than 3, as it should Workaround: None. This is believed to be a Wireshark issue.
ID 224881 On AOM-equipped platforms, changing the management IP via the front-panel LCD multiple times might result in fields on the LCD being displayed with a value of 0.0.0.0. Repeatedly changing management IP using front-panel. Fields on the LCD are displayed with a value of 0.0.0.0. Workaround: The correct values will be displayed after a system restart.
ID 225358 Both units probe both gateway fail-safe pools regardless of their unit IDs. This occurs in HA configurations. Members of a redundant configuration continue to probe both gateway fail-safe pools. Workaround: None.
ID 225431 Disabling the LCD System Menu does not persist across restarts. This is for diagnostic purposes. This occurs when you disabled the LCD display and restart the system. The LCD display setting is not saved. Workaround: To prevent access or configuration changes from the LCD Systems Menu, you can re-enable and then disable the LCD System Menu after each system restart. For more information, see SOL11363: Disabling the LCD System Menu does not persist across restarts, available here: http://support.f5.com/kb/en-us/solutions/public/11000/300/sol11363.html.
ID 225588 Error conditions such as unreachable IP addresses, and unavailable TACACS+/RADIUS services, are not logged to /var/log/ltm for the TACACS+ RADIUS audit forwarding accounting feature. This occurs when you configure the feature using a non-existent IP or a good IP that is not running TACACS+ or RADIUS, and run some tmsh commands. Entries are logged in /var/log/audit, and no error messages are logged in /var/log/ltm. Workaround: None.
ID 225851 tmsh cannot remove missing array members. When an array member is physically removed from a system, the serial number remains, listed as a 'missing' disk. This occurs when an array member is missing. The serial number remains. Workaround: To remove this serial number, you can use the GUI, or you can run the 'array' command, as follows: 'array --erase <serial number>'. You can also use the GUI to remove those disk serial numbers in the System :: Disk Management. The missing array member is shown, just as it was previously, but only the serial number is listed. Remove that from the array just as you would with any installed array disk, and the system removes that serial number.
ID 226113 "ACPI: Unable to locate RSDP ACPI Error: A valid RSDP was not found (20090903/tbxfroot-219)" Limited to 6900, 8900, 8950, 11050, and PB200 platforms. These messages are benign and indicate that an ACPI capable kernel is booted on a system without ACPI support. Workaround:
ID 226892 With packet filter enabled with a default action of discard/reject, you might encounter the following symptoms: -- Packet captures show that the BIG-IP system is receiving return traffic for one or more connections, but failing to forward those packets. -- Some connections may fail. DNS traffic, or traffic with IP fragments, are more likely to fail due to how TMM handles connections. -- If logging is enabled for the affected packet filter rule, many entries similar to the following example are logged to the /var/log/pktfilter file: 'local/tmm notice tmm[4835]: 01250004:5: test_pf_rule (56687): reject on external, len: 98 [IPv4 84 192.168.1.1 -- 192.168.1.2 ICMP 0:0]' "After configuring packet filters, you may notice that the BIG-IP system is incorrectly dropping the return packets of certain connections. This issue occurs when all of the following conditions are met: -- The BIG-IP platform and software version support Clustered Microprocessing (CMP). -- CMP is enabled globally. -- CMP is enabled for the specific traffic-handling object. -- Packet filtering is enabled with the Filter established connections option disabled (this is the default setting)." The BIG-IP system incorrectly drops return packets, which may cause your applications to fail or work intermittently. Workaround: To work around this issue, you can either define additional packet filter rules that explicitly allow return traffic, or disable CMP for the affected traffic-handling object. If the object does not allow CMP to be disabled (for example a SNAT), you can first replace it with a virtual server. For more information, see SOL12831: Using packet filters in conjunction with CMP may cause intermittent drops on return traffic, available here" http://support.f5.com/kb/en-us/solutions/public/12000/800/sol12831.html.
ID 226964 Node marked down by a monitor that is waiting for a manual resume mistakenly displays Enabled state when it is actually down. After a health monitor configured for manual resume has marked a node down, the Configuration utility incorrectly reports the node as Enabled instead of Forced Offline. After a health monitor configured for manual resume has marked a node down, the Configuration utility incorrectly reports the node as Enabled instead of Forced Offline. This issue only affects nodes. The issue does not affect pools or pool members. Node remains disabled, but the GUI reports Enabled. Workaround: You can work around this issue by clicking the Enabled (All traffic allowed) option and clicking Update. For more information, see SOL11828: After a health monitor configured for manual resume has marked a node as down, the Configuration utility incorrectly reports that the node is still enabled, available here: http://support.f5.com/kb/en-us/solutions/public/11000/800/sol11828.html.
ID 227272 If you replace a tri-speed copper small form-factor pluggable (SFP) module with a fiber SFP, you may have to reinsert the fiber SFP module a second time before it accurately reports link status. This occurs when replacing copper SFPs with fiber SFPs The link does not work. You might see the following messages: 'Failed to recover link status' and 'temporarily removed from linkscan.' Workaround: To work around this, remove and reseat the fiber SFP module.
ID 227281 When a full-proxy HTTP virtual with ramcache, fallback, and deferred accept configured executes reject command in CLIENT_ACCEPTED event, TMM restarts. This occurs when the virtual server is configured with all of the following elements: - HTTP profile configured with Cache Setting and a fallback host. - iRule that uses the CLIENT_ACCEPTED iRule event, along with a reject statement. - The TCP profile Deferred Accept setting is enabled. If a virtual server that is configured with the previous settings receives a connection that triggers the reject iRule statement, the TMM process may restart and temporarily fail to process traffic. Workaround: To work around this, remove the fallback host statement in the HTTP profile that is used by the virtual server.
ID 227319 Ramcache configurations that approach the limit of total memory allowed for use by ramcache might cause caching to be disabled for one or more virtual servers. The Cache Setting feature (referred to as RAM Cache in BIG-IP versions prior to 11.0.0) does not take the Clustered Multiprocessing (CMP) feature into account when calculating memory consumption. When the Cache Setting feature is configured for a virtual server on a CMP-enabled platform, the amount of memory allocated for the Cache Setting feature in the HTTP profile is provisioned for each instance of the Traffic Management Microkernel (TMM). Workaround: There is no workaround for this issue.
ID 227362 When you are using Fast L4 profiles and the PVA Acceleration is active, the system cannot perform the mimic functionality requested. This occurs when using Fast L4 profiles, PVA Acceleration, and Mimic for IP ToS to Client or IP ToS to Server. The system cannot perform the mimic functionality. Workaround: Set the PVA Acceleration setting to None if you also specify the Mimic setting for IP ToS to Client or IP ToS to Server.
ID 227369 Generating a SIGINT or SIGQUIT on the serial console during login causes all services to halt and restart. Further, SIGQUIT may cause chmand and get caught in a loop of failed restarts, requiring a host reboot. This occurs when at any point while the password prompt is displayed, there is a signal generated, for example: -- For SIGINT, press Ctrl-C. -- For SIGQUIT, press Ctrl-4, Ctrl-\, or (in some cases) SysReq. All services halt and restart. Further, SIGQUIT may cause chmand and get caught in a loop of failed restarts, requiring a host reboot. Workaround: None. But the problem no longer occurs after the first successful login from the console.
ID 246726 A virtual address is defined as the IP address with which you associate one or more virtual servers. A virtual server is represented by an IP address and a service. The BIG-IP system continues to process traffic for virtual servers after disabling the related virtual address. When a virtual address is disabled in LTM, TMM still processes traffic for the VIPs on that virtual address. For example, if you define virtual servers of 10.10.10.2:80, and 10.10.10.2:443 on the BIG-IP system, then 10.10.10.2 is the virtual address. If you disable the virtual address of 10.10.10.2, the BIG-IP system continues to process traffic for the virtual servers. Traffic is still processed. Workaround: Disable virtual servers instead. For more information, see SOL8940: The BIG-IP system processes traffic for virtual servers after disabling the virtual address, available here: https://support.f5.com/kb/en-us/solutions/public/8000/900/sol8940.html
ID 246825 You might encounter unexpected behavior when you click Clear Statistics (on the Module Statistics screens) or Clear Performance Data (on Performance statistics screens) in any view. This occurs on statistics screens and detail views where there is a Clear button. The operation clears data for all historical statistics, not just the data for the specific view you have open. Workaround: None.
ID 246871 When you are on the license summary general properties screen and you refresh the browser after you reactivate a license, the system prompts you to log on again. This occurs after reactivating a license on the license summary general properties screen, and then refreshing the browser. the system prompts you to log on again Workaround: None.
ID 246962 The system counts route domain health check traffic as part of IPv6 traffic statistic totals. If your configuration has a monitor on a pool in a routing domain, you will see an increase in IPv6 traffic. If you remove the monitor from the pool, the IPv6 statistics freeze (assuming there is no actual IPv6 traffic). If occurs with configurations that have a monitor on a pool in a routing domain. With this configuration, you will see an increase in IPv6 traffic. If you remove the monitor from the pool, the IPv6 statistics freeze (assuming there is no actual IPv6 traffic). Workaround: None.
ID 246983 A display issue in the browser-based Configuration utility makes it appear as if users can modify user settings that they should not be able to access. For example, a user logs on using an account assigned a non-administrator role. When that user changes the password and clicks Update, the screen temporarily redisplays with available settings for file, partition, and shell access. This might occur in some Internet Explorer or Firefox browsers after changing a password. Although the user can manipulate the controls, and select different settings, the system does not accept the change. Workaround: None, however this is a browser issue. Internet Explorer and Firefox might allow user to see contents of change-select controls after the form has been submitted. The controls are disabled, even though it might appear that they are functional.
ID 247011 Unlike in SSL profiles, the system does not validate keys and certificates used for SIP and HTTPS monitors. That means that you can specify non-matching or invalid keys and certificates. There is no checking on the command line or in the browser-based Configuration utility to make sure keys and certificates are valid and usable. This occurs with validation for SSL keys and certificates used for HTTPS and SIP monitors. You can specify non-matching or invalid keys and certificates. Workaround: None. You must ensure the validity of the keys and certificates used.
ID 247012 If you use a SIP or HTTPS monitor on a server that requires authentication using a certificate signed by a certificate authority (CA), the monitor must use certificates signed by a CA that the server recognizes. Do not configure a monitor using certificates signed by an Intermediate CA because the monitor does not send such certificates to the server. This occurs when using non-CA-signed certificates on SIP or HTTPS monitors that communicate with servers that require CA-signed certificates. Authentication fails. Workaround: Use CA-signed certificates.
ID 247094 If you have state mirroring enabled, when you upgrade one unit of a redundant system, the system posts messages until all systems are running the same version of the software. tmm tmm[1917]: 01340001:3: HA Connection with peer 10.60.10.3:1028 established. This occurs when upgrading redundant system configurations and the versions are not yet the same. The system posts messages until the software versions are the same. Workaround: There is no workaround for this condition. All units in a redundant system must be running the same version of the software.
ID 247099 After an import default operation, the prompt is set to reboot, but the operation does not instigate the reboot operation on the primary blade, although it does on the secondary blade. This is intentional behavior: the operation causes a reboot on secondary blades, but the primary blade does not reboot automatically in this case. To activate the imported configuration, reboot the primary blade. Workaround:
ID 247122 When a system timeout occurs, the system grays out the screen behind the timeout alert box. Although you can access the browser window scroll bars to view the contents of the grayed-out screen, none of the options are active. Workaround:
ID 247135 Linux represents long VLAN names using the first 13 characters and an appended ~1. If you use the Linux system command ifconfig to retrieve the interface configuration of a VLAN with a name longer than 9 characters, the operation truncates the name to 8 or 9 characters. Workaround: To work around this issue, use the ip addr show command to retrieve the VLAN using the IP address.
ID 247200 When a user configured for one role is logged on to the browser-based Configuration utility, and you change that user's role to another type, also using the Configuration utility, the system logs off that user. This occurs when changing the user role while that user is logged on. When that user logs back on, the system writes to the catalina.out file error messages such as com.f5.mcp.io.McpIOException: java.io.EOFException: Error while reading message at. Workaround: None, however, these messages are benign, and you can safely ignore them.
ID 247216 The help frame crops the right edge of some of the formula definitions on the Performance statistics screen. This occurs when viewing formula definitions on the Performance statistics screen. The right side of the text is cropped, and there is no horizontal scroll bar. Workaround: Click the Launch button to view the full text.
ID 247241 Occasionally, when you create an installation repository on a USB thumb drive from the BIG-IP system, the operation fails while copying the repository files to the thumb drive. (The failure might also occur when reading or writing any large file to the thumb drive from the BIG-IP system.) When the failure occurs, the system reboots and writes a log entry similar to the following in the /var/log/ltm file: -- Dec 10 11:13:12 local/8900 notice overdog[2401]: 01140108:5: Overdog scheduling exceeded 1/2 timeout of 5 seconds (measured:8060 ms) Workaround: Create the installation repository on a USB thumb drive using a Linux workstation, as documented in the BIG-IP Systems: Getting Started Guide. In any case, do not perform the operation on a BIG-IP system that is actively in production to prevent the potential failure from affecting live traffic.
ID 247300 "You should not use the SSL::respond method with a CLIENTSSL_CLIENTCERT iRule event with a COMPAT mode cipher, as it can result in a handshake failure." "This occurs when you use the SSL::respond method with a CLIENTSSL_CLIENTCERT iRule event with a COMPAT mode cipher." This results in a handshake failure. Workaround: None.
ID 247310 There is an extremely rare chance that, if the high-availability mirroring connection fails and recovers, the result might be a new persistence record and an expired record using the same key to send their respective messages. For example, if a record comes in that would have matched an old one on the active system, it is possible that the old record's expiration action might arrive after the new record's update action. If the key matching the old record expires, the standby system incorrectly deletes the corresponding new record. This occurs when high-availability mirroring connection fails and recovers in the time between checking persistence entries. When this occurs, there might be a new persistence record and an expired record using the same key to send their respective messages. If the key matching the old record expires, the standby system incorrectly deletes the corresponding new record. Workaround: None, but the possibility of encountering the issue is very rare.
ID 247709 "When you change the idle timeout in System :: Preferences, the system must restart the httpd process. This results in a set of error messages similar to the following example: err httpd[6246]: [error] [client 127.0.0.1] Invalid method in request OPTIONS * HTTP/1.0 err httpd[6320]: [error] (9)Bad file descriptor: apr_socket_accept: (client socket) warning httpd[3064]: [warn] RSA server certificate CommonName (CN) `dhcp-137' does NOT match server name!? warning fcgi-[6376]: [warn] FastCGI: server ""/usr/local/www/mcpq/mcpq"" started (pid 6377) err httpd[6379]: [error] [client 127.0.0.1] Invalid method in request OPTIONS * HTTP/1.0 warning httpd[3064]: [warn] long lost child came home! (pid 6239) These messages occur primarily as a result of the process restart, and you can safely ignore them." Workaround:
ID 247727 When you create a new profile or edit an existing profile using the all-properties option of the tmsh utility, unless you remove some options, the properties might produce unexpected behavior. This occurs when creating or editing profiles using the all-properties option. All properties become custom; that is, profile properties no longer inherit parent settings. Workaround: Use the tmsh utility create and modify commands operations. When you do so, the system preserves the profile's properties inheritance.
ID 247894 The iRule substr function cannot use a string with a number in it as a terminating string. This occurs when using iRules. The iRule converts that string to integer and incorrectly uses it as a substring length. Workaround: None.
ID 248489 If the user configuration set (UCS) file you roll forward at installation time contains a problem, subsequent system load operations can fail. If this happens, the remote users and administrators cannot log on to the system. This occurs when rolling forward the UCS fails. Remote users and administrators cannot log on to the system. Workaround: To work around the situation, log on to the system as the root user or as the admin local user.
ID 248932 "During a system reboot, the BIG-IP system may report error messages to the console that appear similar to the following example: INIT: Sending processes the KILL signal ..................................sshd(pam_audit)[4559]: user=root(root) tty=/dev/pts/1 host=172.27.251.100 attempts=1 start=""Tue Aug 5 17:25:09 2008"" end=""Tue Aug 5 17:27:54 2008"". sshd(pam_audit)[4559]: 01070417:0: AUDIT - user root - RAW: sshd(pam_audit): user=root(root) tty=/dev/pts/1 host=172.27.251.100 attempts=1 start=""Tue Aug 5 17:25:09 2008"" end=""Tue Aug 5 17:27:54 2008"". ..........Restarting system. LinuxBIOS-2.0.0.OBJ-0215-03 REV. A build 897 OBJ-0215-03 REV. starting..." These messages occur when the system shuts down logging to the syslog-ng file before all users who are logged on have logged off. The system posts sshd(pam_audit) messages. Workaround: You can safely ignore the sshd(pam_audit) messages. These messages are an indication that the syslog-ng process may have been terminated prior to sshd during system shutdown. By the time the ssh sessions were stopped, the PAM module was unable to log the message to a system log file. Should this error occur, when the system comes back up, you can use the boot marker in the audit files to confirm that the system logged out the remaining users.
ID 249083 An address wildcard virtual server has to be deleted and recreated when changed from IPv6 to IPv4. Without the intervening deletion, neither IPv6 nor IPv4 traffic matches the virtual. It works as expected when changing from IPv4 to IPv6 (formerly CR 98831). This occurs with address wildcard virtual server and changing from IPv6 to IPv4 (but not when changing from IPv4 to IPv6). Without the intervening deletion, neither IPv6 nor IPv4 traffic matches the virtual. Workaround: To transfer from IPv6 to IPv4, delete the address wildcard virtual server and recreate it.
ID 284910 The BIG-IP system may continue to generate server-side TCP connections to pool members after the associated virtual server configuration is deleted. To improve connection speeds for Performance HTTP virtual servers, the BIG-IP system primes connections to the pool members. When a client makes a connection to the virtual server, if an existing server-side flow to the pool member is idle, the BIG-IP LTM system marks the connection as non-idle and sends the client request over it. This issue occurs when all of the following conditions are met: -- The configuration contains a Performance HTTP virtual server that references the base FastHTTP profile. -- The Performance HTTP virtual server processes at least one connection before being deleted. -- The Performance HTTP virtual server configuration is removed. As a result of this issue, you may encounter the following symptoms: -- Packet traces show the BIG-IP system connecting to pool members from its non-floating self IP address. -- The BIG-IP connection table includes an entry showing the recurring connections. In the following example, the any6.any connection table entry represents the client-side IP address, and 10.11.16.221 is the BIG-IP self IP address: 'any6.any any6.any 10.11.16.221:44321 10.11.16.253:80 tcp 9 (tmm: 0)' Workaround: To work around this, you can delete the pool and restart TMM. For more information, see SOL13850: The BIG-IP system may continue to create server-side TCP connections to pool members after the associated virtual server configuration is deleted , available here http://support.f5.com/kb/en-us/solutions/public/13000/800/sol13850.html.
ID 291327 Configuring a virtual server for multicast communications inside a route domain does not work. This occurs when configuring a virtual server for multicast communications inside a route domain. The resulting configuration does not work. Do not configure a virtual server for multicast communications inside a route domain. Workaround: None, but this appears to be a rare condition.
ID 291541 If there are static Address Resolution Protocol (ARP) entries targeted to the management network in either the existing configuration or in the configuration being installed or used in a ConfigSync operation, the configuration may fail to load. This occurs when performing a config sync or loading a configuration containing static ARP entries targeted to the management network. When this occurs, the configuration may fail to load. An error message is logged to the /var/log/ltm file similar to the following example: '01070712:3: Caught configuration exception (0), Netlink reply from kernel has error: -101 - routing.cpp, line 883' Workaround: "To work around the issue, first delete any static ARP entries targeted at the management network and then complete the configuration load or ConfigSync operation. Procedure for BIG IP v11.x: ----- 1.) Log in to the Traffic Management Shell (tmsh) by entering the following command: tmsh 2.) Display the list of static ARP entries configured on the BIG-IP system by typing the following command: show net arp all 3.) Identify the offending static ARP entry. 4.) Remove the offending entry by typing the following command, where <Name> is the name of the address being deleted: delete net arp <Name> For example: delete net arp /Common/192.168.1.1 5.) Save the change by typing the following command: save /sys config Procedure for BIG IP v10.x: ----- 1.) Log in to the BIG-IP command line as the root user. 2.) Display the list of static ARP entries configured on the BIG-IP system by typing the following command: bigpipe arp static list 3.) Identify the offending static ARP entry. 4.) Remove the offending entry by typing the following command: bigpipe arp <IP address> delete 5.) Save the change by typing the following command: bigpipe save all"
ID 291584 When backslash is used to escape quote in external data group, the backslash is duplicated when the data group is saved. Backslash is used to escape quote. More backslash is inserted to the data group and eventually leads to config load error. Workaround: Delete the extra backslash.
ID 291689 When you use the Weighted Least Connections (Node) load balancing method, you must set a connection limit for each node prior to adding the pool member to the pool. This occurs with Weighted Least Connections (Node) and connection limits. If you fail to specify the connection limit for the node prior to adding the pool members, the system presents a configuration validation error. Workaround: "In this release, you must use the following process to accomplish this: 1. Create a pool that uses the Weighted Least Connections (Node) load balancing method. 2. Explicitly create the node entries for the pool members on the Local Traffic Nodes Node List (create) screen. 3. For each node, specify a value other than 0 (zero) in the Connection Limit box. 4. Return to the pool configuration screen by clicking its link in the Local Traffic Pools Pool List. 5. Select the Members tab and add the pool members to the pool, using the same IP addresses as the nodes that you configured in the earlier step."
ID 291704 If you replace a copper (Cu) small form-factor pluggable (SFP) with a fiber SFP, the link might remain down, even when connected to an active peer. This occurs when you replace a copper SFP with a fiber SFP. When this occurs, the link might remain down. Workaround: The workaround is to issue a bigstart restart bcm56xxd command. From the command line, 'bigstart restart bcm56xxd'.
ID 291719 When the Configuration utility restarts, system writes benign messages to catalina.out. This occurs when the Configuration utility restarts The system writes messages to catalina.out: 'log4j:ERROR A 'org.apache.log4j.ConsoleAppender' object is not assignable to a 'org.apache.log4j.Appender' variable,' 'log4j:ERROR The class 'org.apache.log4j.Appender' was loaded by log4j:ERROR,' '[org.apache.catalina.loader.StandardClassLoader@1359c1b] whereas object of type,' and 'log4j:ERROR'org.apache.log4j.ConsoleAppender' was loaded by [WebappClassLoader.' Workaround: None, but these messages are benign, and you can safely ignore them.
ID 291723 At system startup, you might see messages about unrecognized md component devices. This occurs because datastor volumes are not intended to be combined into a redundant array. The disk management subsystem unintentionally tries to join them into an array, but fails. The system posts messages similar to the following: -- mdadm: Unrecognised md component device - /dev/mapper/vg--db--sda-mdm.app.wom.dat.datastor -- mdadm: Unrecognised md component device - /dev/mapper/vg--db--sdb-mdm.app.wom.dat.datastor Workaround: None, but no adverse result occurs, and you can safely ignore these messages.
ID 291742 In the ltm.log file, you might see mcpd warning messages similar to the following:" warning mcpd[3002]: 01070156:4: Could not remove file /config/bigip/auth/pam.d/tmm_ldap. Please remove this file manually." When you navigate to the specified directory, you do not find the files. These messages are incorrect, and you can safely ignore them. Workaround:
ID 291756 On a multi-drive system, when you remove a drive, LED status might not reflect status correctly. This occurs when removing a drive on multi-drive systems. If the LED is flashing when you remove a drive from the unit, the LED status does not turn green (as it should) when disk replication begins. If the LED is not flashing, the LED turns green immediately in the transition to replicating a drive. Workaround: None, but this is a cosmetic issue only, and has no effect on functionality.
ID 291761 When you complete a new installation, the Firefox browser may not recognize the SSL certificate. This occurs only on a new installation when using the Firefox browser. When this occurs, the Configuration utility posts the message 'Please wait while this BIG-IP device reboots, shutting down device.' This spins forever and never returns. This behavior is Firefox-browser specific, so when the certificate is no longer viewed as valid, the Firefox browser ignores subsequent HTTP requests. Workaround: None, but the issue happens only when doing a fresh install using the Firefox browser. A configuration you roll forward includes the device certificates, so this is not an issue. The Microsoft Internet Explorer browser posts an accept-certificate dialog box when you restart the system.
ID 291768 If you create VLANs in an administrative partition other than Common, but do not create a route domain in that partition, then the VLANs you create in that partition are automatically assigned to route domain 0. If you later change the default route domain of that partition, the VLAN stays in its existing route domain, unless the VLAN has a self IP address or virtual IP address assigned to it. In that case, the VLAN moves to the new default route domain. This is an issue with VLANs and default route domains in administrative partitions. Newly created VLANs might stay in the existing route domain, unless the VLAN has a self IP address or virtual IP address assigned to it. In that case, the VLAN moves to the new default route domain. Workaround: Make sure to create a route domain in any administrative partition where you create VLANs.
ID 291777 The software does not support running small form-factor pluggable (SFP)+ on SFP ports on VIPRION systems that contain B4100 blades, even if the ports are running at 1 GB. Although the system does not prevent you from doing so, and you might find such a configuration functional, we do not support nor recommend running in this configuration. This occurs when using SFP+ on SFP ports on B4100 blades on VIPRION systems. Configurations of this type intermittently lose link aggregation and produce errors. Workaround: None. This is not a supported configuration.
ID 291782 Running tmsh load sys config operation (on versions 11.0.0 and 11.1.0), or b load (on version 9.4.x and 10.x), fails when pool members are configured with port numbers 63, 66, 172, 211, 564, and 629. In version 11.2.0 and later, although the tmsh load operation completes for such configurations, the command "tmsh list ltm pool members" fails. This occurs when pool members are configured with port numbers 63, 66, 172, 211, 564, and 629. Load operations may fail or may fail to be listed. Workaround: The workaround is to use numbers other than these for pool member port configuration. If you want to use those ports, you can disable the utility from converting service names by running the command "tmsh modify sys db bigpipe.displayservicenames value false" (on version 11.x), or "bigpipe db bigpipe.displayservicenames false" (on version 10.x). For more information, see SOL12365: The configuration may fail to load when a pool member contains certain service numbers, available here: http://support.f5.com/kb/en-us/solutions/public/12000/300/sol12365.html.
ID 291784 If you set the import save value to 1 (one) and import a single configuration file (SCF), the import operation stops. This occurs when setting the import save value to 1. After initiating the SCF import, the import operation halts and does not resume. Workaround: To work around this issue, set the import save value to 2 or more. Note that the default value is 2.
ID 291786 When you use the domaintool utility to delete a domain when you are configuring Kerberos delegation, if that domain serves as the default, the system removes the domain but leaves it as the designated default. Workaround: To work around this issue, change the default to a different domain before the delete operation.
ID 305069 Using the COMPRESS::disable call in an HTTP_REQUEST event in an iRule does not work. This occurs in HTTP_REQUEST events in iRules. COMPRESS::disable call does not work. Workaround: As a workaround, use the COMPRESS::disable call in an HTTP_RESPONSE event instead.
ID 305091 You can create duplicate virtual servers with same address space that are enabled on different VLANs in the same partition. But you cannot create duplicate virtual servers with same address space enabled on different VLANs if the VLANs are in different partitions. This occurs on duplicate virtual servers with same address space that are enabled on different VLANs on the same partition. You cannot create duplicate virtual servers with same address space enabled on different VLANs if the VLANs are in different partitions. Workaround: None.
ID 305096 When using the vi editor to edit files on the BIG-IP 6900, you might have to enter as many as three escapes to return to command mode from insert mode. When using the vi editor to edit files on the BIG-IP 6900. You might have to enter as many as three escapes to return to command mode from insert mode. Workaround: None.
ID 305319 SNMP queries for ltmUserStatProfileStat values do not return accurate values for user stat profile fields. Instead, the system returns a 0 (zero) or a negative number as the value. This occurs in SNMP queries for ltmUserStatProfileStat values. The system returns a 0 (zero) or a negative number as the value. Workaround: None
ID 305380 If you initialize the Federal Information Processing Standards (FIPS) card and convert non-FIPS keys to FIPS keys, you must reload the configuration (using the tmsh load command) or restart the tmm process (using the bigstart restart command) before the system starts using the keys. This occurs when using FIPS. "If you try to run the system without reloading the configuration or restarting the tmm process, the system issues the following errors: 01260009:7: Connection error: ssl_hs_vfy_pms:2128: invalid pre-master secret (80) Connection error: ssl_basic_rx:232: mac miscompare (20)" Workaround: "Assuming you have an SSL profile that uses the newly converted FIPS key and you plan to reload the configuration, here is the command sequence to run: fipsutil -f init convert non fips key to fips load /sys"
ID 336885 There is a memory leak that affects Firefox 3.6 but not Internet Explorer 8. The leak occurs because of an interaction between the dashboard and the web browser. The workaround is to use Internet Explorer to view the dashboard. This occurs in Firefox 3.6 and involves the dashboard interaction with the web browser. When this occurs, there is a memory leak. Workaround: If running the dashboard for a long time, use Internet Explorer instead of Firefox.
ID 336986 If a hard drive is in the process of replicating and an install to a non-existent volume set is started, the array status for the replicating drive will transition to 'failed' while the volume sets are created. They are created at the very beginning of the installation, so this failed status should last no more than 1 minute. After the volume set is created, the status will go back to 'replicating', as expected. This occurs when installing to a control plane that doesn't exist yet, for example, in the middle of replication. The array status shows 'failed'. Workaround: None.
ID 338426 Clusterd can core on shutdown under certain circumstances. This occurs with vCMP, and only happens when clusterd is shutting down. When this occurs, clusterd can assert. Workaround: None, but it has taken care of all notifications to other system components, so the core can be safely ignored.
ID 338450 On VIPRION blades, the BIG-IP system might log error messages about kernel-owned interfaces. This is a timeout-related error on VIPRION blades. The system posts messages similar to the following: -- slot1/mychassis notice chmand[3782]: 012a0005:5: Tmstat::updateMgmtIf: HAL Svc -- error: MiiNic: failed to send cmd to driver: readPseMii ioctl on: eth2Phy & Reg:1e:1a -- returns:Invalid argument -- slot1/mychassis notice chmand[3782]: 012a0005:5: Tmstat::updateMgmtIf: HAL Svc -- error: MiiNic: failed to send cmd to driver: getStatusReg: timeout wait for result. Workaround: None, but these are innocuous and can be ignored.
ID 341928 "tmm daemon will crash with accompanying log message: Assertion ""cmp dest set on incorrect listener type"" failed." A CMP enabled virtual targets (e.g. via 'virtual' iRule command) a CMP disabled virtual. Failover or network outage. Workaround: Avoid use of CMP disabled virtual servers.
ID 342319 When you add a Domain Name System (DNS) server to the BIND forwarder server list from the Configuration utility, the recursion option is set to no and the forward option is not set. The parameters 'recursion yes' and 'forward only' are not being updated in named.conf when creating entries in the BIND Forwarder Server List from the GUI. This issue may cause some DNS queries that are sent to the BIG-IP system to fail. Workaround: You can work around this issue by setting the recursion and forward options. For more information, see SOL12224: Configuring the BIND forwarder server list does not correctly set additional options for the named.conf file, available here: http://support.f5.com/kb/en-us/solutions/public/12000/200/sol12224.html.
ID 342325 If username and password have not been configured for a RADIUS accounting monitor, it will try to connect with a <NULL> username-password. This occurs when the username and password have not been configured for a RADIUS accounting monitor. The system attempts to connect with a <NULL> username-password. Workaround: Configure the username and password for the RADIUS accounting monitor before attempting a connection.
ID 342423 The statsd process computes the value for system-wide CPU usage using a formula: process 'A' CPU usage divided by the number of CPUs on the chassis. Assuming a chassis is fully populated with PUMA I blades, the average is divided by 16. If a blade drops out, the number of CPUs is now 12, so while that blade is out of circulation, the data is divided by 12. However, even for the 5-second window: it is possible that the average might be calculated incorrectly. This occurs when calculating average system-wide CPU usage when a blade drops out. "Example =========== -- From time1 to time4, there are 16 CPUs on the box, and processA is using 96% of its CPU. -- At time5, one of the blades drops out. -- The calculation to compute CPU and system usage happens at this time. -- Before the blade dropped out, the system-wide average was 96/16 = 6. When the blade drops out, the system-wide average is 96/12 = 8." Workaround: None. However, this is a small difference. Although blades going down should not happen often, when it does happen, it is only the first 5-second system-wide average that is affected. The next average will be correct.
ID 344226 Trying to create a CRLDP server using a name that already exists fails. The resulting error message does not indicate the problem. This occurs when creating a CRLDP server using a name that already exists. The operation fails with the message 'An error has occurred while trying to process your request.' A more accurate message is 'The requested CRLDP server ('crldp_server_name') already exists in 'partition_name'.' Workaround: None.
ID 345092 "When a RAID system is booting, the system posts the message: Press 'CTRL-I'; to enter Configuration Utility..." This occurs on RAID systems during boot. Pressing Ctrl+I has no effect. It is not possible to enter the Configuration utility this way. This is a hardware constraint. Workaround: Instead, you can configure RAID parameters through TMOS.
ID 345529 The BIG-IP Configuration utility may incorrectly allow you to assign certain health monitors to pools while their pool members are configured with a wildcard service port. This occurs when assigning the pool health monitor before assigning a member-specific monitor to each pool member. For LTM configurations, the system fails to pass traffic due to the configuration failing to load. For GTM configurations, sync group members may fail to answer wide IP requests. Workaround: To workaround this issue, make sure to specify an Alias Port on a monitor when it needs to probe a specific service port on wildcard pool members. For more information, see SOL12400: The BIG-IP Configuration utility may incorrectly enable you to assign certain health monitors to pools and server objects that are configured with a wildcard service port, available here: http://support.f5.com/kb/en-us/solutions/public/12000/400/sol12400.html.
ID 347174 When starting BIG-IP VE on a Hyper-V platform, the BIG-IP VE system posts multiple Advanced Configuration and Power Interface (ACPI) messages. This occurs when starting BIG-IP VE on a Hyper-V platform. The system posts ACPI messages such as: 'ACPI: LAPIC (acpi_id[0x3f] lapic_id[0x3e] disabled)'. Workaround: None, but these messages are expected and you can ignore them.
ID 348431 "If you cancel a qkview when it is being generated via the GUI, a zero-byte sized qkview will be created. Subsequent attempts will still generate a zero-byte qkview (even when deleting the previous qkview). Canceling qkview generation via the GUI does not stop the qkview process; until its finished or killed, qkviews will have size zero." Cancel a qkview while being generated via the GUI; immediately re-generate a qkview via the GUI. Confusion and inability to generate a qkview. Workaround: "Wait until qkview process has finished or kill the process and regenerate. Removing the lock file (# rm /shared/tmp/.qkview_lock) will also allow it to work, but having 2 processes overwriting each other's the temp files is not recommended."
ID 348502 Deleting or renaming a vdisk from the file system (for example, using bash) will not be detected by vcmpd and can lead to unexpected behavior if the system later attempts to use that vdisk. This occurs when deleting or renaming a vdisk using the file system rather than TMSH/iControl. The system, by design, does not support the detection and handling of direct (for example, using bash) vdisk delete or rename. Workaround: Deleting or renaming the vdisk files directly is not supported. Only use tmsh commands, the UI, or iControl to delete or rename vdisks.
ID 348503 "WMI monitor reports ""not found"" for LoadPercentage, CurrentConnection, GETRequestsPerSec, and POSTRequestsPerSec when probing IIS 7.5 on Windows 7." Workaround:
ID 349242 The load balancing method 'Ratio Least Connections (node)' does not perform correctly with 'Performance (Layer 4)' virtual servers. This occurs when using the Ratio Least Connections load balancing method. Does not perform correctly with 'Performance (Layer 4)' virtual servers. Workaround: None.
ID 349629 "The error is usually similar to : 01070257:3: Requested VLAN member (1/2.1) is currently a trunk member Unexpected Error: Loading configuration process failed." Config will fail to load. Workaround:
ID 351934 Booting with SSD installed, you will be able to see the SSD sled activity light blinking while the other spinning media sleds do not. This happens when booting with SSDs installed. SSD tray is only tray to blink activity while booting. Workaround: None, but this is normal behavior.
ID 352560 Proxy SSL is incompatible with persistence profiles. This occurs with persistence profiles and Proxy SSL. The result does not work. Workaround: None, but persistence profiles and Proxy SSL should not exist on the same virtual server.
ID 352840 When using partition default route domains, an attempt to load a previously saved configuration which had a different default route domain on a VIPRION may result in the secondary daemons restarting. Workaround: To work around this, load the default configuration before loading a config that has a different default route domain on any partition.
ID 352925 Updating a suspended iRule assigned via profile causes the TMM process to restart when trying to return to the suspended iRule. This occurs when the iRule is suspended and the TMM process is trying to restart. TMM restarts. Workaround: To work around this, assign the iRule to the virtual server instead of assigning it to the profile.
ID 352957 Established flows via virtual servers with iRules using the "node <addr>" command to set the nexthop to a different address than the gateway returned in route lookup, or transparent flows to a pool member, might fail (due to mis-routing of packets) after a route table change, even if the change does not affect any of the addresses used in the flow. New flows established after the route table change will work as expected. There is no workaround for the problem. Workaround:
ID 353249 LTM Virtual Server Bytes in/out and Packets in/out values may be larger than expected on PVA platforms, when using FastL4 profile with PVA in 'Assisted' mode. This occurs when using the FastL4 profile with PVA in 'Assisted' mode. LTM Virtual Server Bytes in/out and Packets in/out values may be larger than expected. Workaround: None.
ID 353621 You can get an error from tmsh when adding a device to the trust-domain that says the device cannot be found. This occurs in TMSH, if the 'name' option is omitted. This only occurs in TMSH. Adding devices in the GUI does not result in an error. The system posts the error: 'The requested device (10.10.20.30) was not found.' Workaround: This error actually indicates the "name" parameter was not specified in the command. The message does not indicate that there is a connectivity issue to the device being added to the domain.
ID 354467 When you create an opaque VLAN group before creating the route domain to assign it to, opaque mode does not work. This occurs with VLAN groups created before the associated route domain. In this case, opaque mode does not work Workaround: To work around this issue, you can add the VLAN group to the route domain and then set its mode to opaque, or if you are already in this state, you can restart tmm.
ID 354972 In some cases, TMSH does not properly recognize hostnames as an item reference for commands. This occurs in tmsh commands. Hostnames are not recognized when referenced in tmsh commands. Workaround: Use IP addresses instead of hostnames when creating addresses with tmsh in this release. Or use the GUI.
ID 355299 PVA acceleration can be configured on a platform without a physical Packet Velocity ASIC present. This occurs when configuring PVA acceleration on a platform without PVA present. No acceleration can occur, because the platform does not support it. Workaround: None, but the setting has no actual effect and is harmless.
ID 355564 "The Error message ""The requested unknown (/Common/traffic-group-1 /Common/bigip1) was not found."" might appear in the log during startup. This message does not indicate a problem, and can be ignored in this situation." Configuration is new or has been set to defaults. The error message will appear in the log during the device name change. There is no impact, as the message appears due to the device name changing. Workaround:
ID 355616 ltm virtual-address objects are only shown in tmsh list output when specifically requested, as in 'list ltm virtual-address', not in commands such as 'list ltm'. This occurs when running 'tmsh ltm'. Virtual-address objects are not shown. Workaround: To workaround this, use 'list ltm virtual-address' instead.
ID 356611 You can invoke imish (the shell for configuring dynamic routing) from tmsh. When you subsequently press Ctrl + Z, sshd and imishd start consuming CPU until the imish shell times out. This occurs when tmsh is not the login shell. If the system is already in this state, run the fg command, and then exit imish. This occurs when invoking imish from tmsh and press Ctrl + Z. sshd and imishd start consuming CPU until the imish shell times out. Workaround: None, but suspending tmsh is not recommended behavior.
ID 356705 After completing the setup wizard in the Configuration utility, the user is redirected to the Welcome screen. After completing the setup wizard in the Configuration utility and returning to the Welcome screen. The menu at left should also change from the restricted setup menu to the full menu, but occasionally it does not. Workaround: In this case, the workaround is to log out/in or refresh the browser.
ID 356938 Special characters (such as the Yen sign) in data group names generate garbage characters. This occurs when using special characters in data group names. The system generate garbage characters in the GUI. Workaround: Do not use special characters of this type for data groups.
ID 357262 When a logging pool is not available, the system closes the connection whenever it serves an HTTP response on a logging error. This occurs when 'Respond On Error' is set to Enabled, and the associated logging pool is unavailable. The system sends a TCP reset to the client connection. Workaround: Although there is no direct workaround, you can get the service back up by setting 'Respond On Error' to Disabled and update the request logging profile. You can do so at the command line by running the following command: root@(BIG-IP)(cfg-sync Standalone)(Active)(/Common)(tmos)# modify ltm profile request-log hsl_logger proxy-respond-on-logging-error no
ID 357391 The racoon IKE (ISAKMP/Oakley) key management daemon must be initialized before it can process connections. You can determine whether racoon is initialized by looking at /var/log/racoon.log. After configuring IPsec objects, /var/log/racoon.log reports that it has loaded the configuration and there is no error after it in a message similar to the following: 2011-04-27 11:03:35: INFO: Reloading configuration from '/etc/racoon/racoon.conf'. This occurs when using racoon to negotiate IPsec tunnels. Traffic sent before initialization is complete fails to be processed. Workaround: None. The racoon daemon must complete initialization before traffic is sent for processing.
ID 357656 When you use bigstart restart to restart all daemons on a guest on VIPRION platforms, the system logs a benign ltm log message. This occurs when restarting all daemons on a guest on VIPRION platforms. "The system logs the message: Apr 25 15:43:27 slot1/vcmp1 notice chmand[7975]: 012a0005:5: Chmand cleanup: Slot:Led:Color (1:3:0) not succeed: virtual void Hal::NullAnnunSvc::ledSet(Hal::LedFunction&, Hal::LedColor&, uint32_t&, uint32_t&, uint32_t&)" Workaround: None, but this is a benign message and you can safely ignore it.
ID 357822 User can use "delete cm trust-domain all" to create or fix trust-domain when loading a blank or inconsistent SCF. Workaround:
ID 357852 If a device that is part of an established trust-domain is added into a second, separate trust-domain, the devices in the original trust-domain still have references to the original device. This occurs when moving members from one trust-domain to another. Devices in the original trust-domain still have references to the removed device. Workaround: Delete the device from the trust-domain from a certificate authority before adding it to a different trust-domain.
ID 357874 "Creating an overlapping route can cause an unclear configuration exception message, such as: 1. [root@ltm-56:Active] config # tmsh create net route test_route_ipv6 network 2002::1/128 gw 2002::3 2. [root@ltm-56:Active] config # tmsh create net route default-inet6 { gw 2002::1 } 01070712:3: Caught configuration exception (0), Netlink reply from kernel has error: -113 (for static route create: ::/0 gw 2002::1 in vlan '') - net/validation/routing.cpp, line 332." Workaround: There is no workaround.
ID 358063 If you issue the command 'restart sys service all' from the tmsh shell, the next command you issue result in the error message: 'The connection to mcpd has been lost, try again.' Workaround: There is no workaround.
ID 358099 If two devices have different provisioned modules, then the application with those modules configured in one device might not be able to sync to the other device. This occurs when syncing two devices that have different provisioned modules. The two devices are out of sync and cannot recover in this situation. Workaround: For sync to occur correctly, both devices must have the same provisioning.
ID 358191 "If the user resets the trust and changes the host name of the device, the other devices in the trust domain still show the unchanged, former host name and show the device as still attached." This occurs in a trust configuration. Changing host name has no effect. Workaround: None.
ID 358575 The traditional ConfigSync mechanism has been replaced with a more robust MCP-to-MCP communication mechanism. As a result, UCS files now load the full configuration in all cases, and no longer have the concept or ability to only load the "shared" portion. Loading of UCS files created on a different device is no longer supported. Workaround: There is no workaround.
ID 358615 Because there is no 'add' option for unicast-address, if you have two existing unicast addresses, the command to add another replaces both addresses with a single address. For example, given a device with two existing unicast addresses, this command replaces both addresses with a single address: modify cm device centmgmt1.f5net.com unicast-address { { ip 10.10.10.1 } } The result is that the device unicast has only the mgmt address, and has lost the internal IP address. Workaround: When modifying failover unicast addresses using tmsh, you must specify all addresses, even if the intention is to remove or add a single address.
ID 358655 The system posts an error message 'No such file or directory' during kernel installation. This occurs during kernel installation. The system reports an error such as the following: info: RPM: ls: /etc/modprobe.d/*.conf: No such file or directory. Workaround: None, but it does not negatively impact the installation itself.
ID 359393 In order to be compliant with the FIPS-140 standard. Keys cannot be exported from a FIPS card in plain text, hence they can only be exported by encrypting them with the master key on the FIPS card. This occurs when the master key on the FIPS card has changed since the keys have been exported. In this case, it is not possible to import the keys back into the card Workaround: None.
ID 359395 Invalid or empty SSL certificates, keys, or CRLs will not be rolled forward on upgrade to v11.0.0. Workaround:
ID 359491 When a system's hostname is set by the user via the tmsh setting "modify sys global-settings hostname new-hostname.example.com" only the local copy of the self device is set. Remote copies of the hostname are not updated accordingly. Thus, running the command "list cm device name-of-device hostname" would have the hostname "new-hostname.example.com" on the local machine and "old-hostname.example.com" on other machines in the trust domain. Workaround:
ID 359774 In v11.x, pools used in an HA group must be in Common. If the user has a v10.x configuration that has pools in different partitions that are used in an HA group, an upgrade to v11.x fails. HA group pools in administrative partitions other than Common. Upgrade fails. Workaround: None, except ensuring that all pools used in HA groups exist in the Common administrative partition.
ID 359873 LTM-initiated SSL renegotiation is not attempted when secure renegotiation is configured as required and the peer is unpatched (does not support SSL secure renegotiation). This applies both to configuration-based (e.g., renegotiate-period), as well as iRules-based attempts to renegotiate. This occurs when secure renegotiation is required and the peer is unpatched. LTM-initiated SSL renegotiation is not attempted. Workaround: None except to ensure that all peers are patched.
ID 360122 The iControl method System.Statistics.reset_all_statistics() does not reset iStats. This occurs when running the iControl method System.Statistics.reset_all_statistics(). Does not reset iStats. Workaround: To work around this, do the following: 1. bigstart stop. 2. Remove all files (not directories) in /var/tmstat2. 3. bigstart start.
ID 360134 6400, 6800, 8400, and 8800 platforms with Cavium NITROX Federal Information Processing Standards (FIPS) cards do not support secure SSL renegotiation with RC4 ciphers. Initial SSL handshakes are unaffected, but attempts to perform mid-connection rehandshakes fail when SSL secure renegotiation is negotiated. This occurs on the 6400, 6800, 8400, and 8800 platforms with FIPS cards using secure SSL renegotiation with RC4 ciphers. Initial SSL handshakes are unaffected, but attempts to perform mid-connection rehandshakes fail. Workaround: You can work around this by disabling SSL renegotiation or RC4 ciphers. Platforms with Cavium NITROX-PX FIPS cards are unaffected.
ID 360485 Node statistics, especially after a statistics reset, may be too high for a node whose address is in a lasthop pool. Lasthop pool configured. Inaccurate node stats. Workaround: None.
ID 360675 Creating a configuration object with a FIPS 140 key will always create a key in the FIPS 140 device even when the configuration objects are not saved. Configuration objects that are not saved will require the user to delete FIPS 140 keys manually from the device. Keys can be deleted manually with "tmsh delete sys crypto fips by-handle". Key handles can be listed with "tmsh show sys crypto fips". Workaround:
ID 361036 When the AOM powers down the Host for cause (for example, over temp) it abruptly stops the Host, bypassing a normal graceful power-down sequence. Occurs when the Host is powered off for cause. Because of this, some log messages sent from the AOM to the Host might be lost. Workaround: None.
ID 361181 You can run the command 'fipsutil -f init' to force re-initializing the FIPS card or 'fipsutil reset' to reset the FIPS card. Both these operations delete all the keys in the card. However, issuing the command does not delete the BIG-IP configuration objects representing those keys. It also does not modify SSL profiles utilizing those keys. When there are BIG-IP configuration objects referencing to such FIPS keys, these operations will result in the failure to load configuration on reboot. This occurs when running the command 'fipsutil reset' or 'fipsutil -f init' and when BIG-IP has configuration objects referencing keys on the FIPS card. The system posts messages similar to the following: 'notice mcpd[5816]: 01390002:5: The size of the configuration DB has been extended by 2097152 bytes, now using a total of 10485760 bytes', 'err mcpd[5816]: 010713e4:3: FIPS subsystem reported error while attempting file object operation: FipsMgr::get_handle_from_modulus error unable to obtain handle. Modulus(e1:fb:55...ef:89:b3), FIPS:ERR_HSM_NOT_INITIALIZED. ', 'err mcpd[5816]: 010713e4:3: FIPS subsystem reported error while attempting file object operation: fips_insert_masked_object error on import, ERR_HSM_NOT_INITIALIZED. ', 'err mcpd[5816]: 01070712:3: Caught configuration exception (0), unable to import FIPS 140 key (/Common/zzFIPSTest) from key file.) - sys/validation/FileObject.cpp, line 4714. ', 'err tmsh[6948]: 01420006:3: Loading configuration process failed. ' Workaround: "To avoid this situation, delete the FIPS keys and remove the usage from profiles before resetting or re-initializing the FIPS device. If the system gets into the failure condition, you can recover by completing this procedure: 1. Edit the bigip.conf file where the FIPS key is referenced. Delete all occurrences of the key. 2. Delete the key from /config/ssl/ssl.cavfips 3. Find and delete the key from filestore/files_d/<partition-name>/certificate_key_d/ 4. Run 'tmsh load sys config partitions all' to make sure the config loads. After this point, the config should load without issue after a reboot."
ID 361315 if you go to the System : Preferences screen and simply click the Update button without editing any values, the system incorrectly posts a Changes pending notice (that is, recommendation for synchronization). Many values on this screen are not even synchronized across BIG-IP devices. This occurs when you click the Update button on the System : Preferences screen. The system incorrectly recommends a sync, even though it's not needed. Workaround: None.
ID 361470 If a virtual server's destination address is entered into tmsh with invalid IPv4 or IPv6 numbering or a hostname, the error message 'The requested virtual address (</PATH/ADDRESS>) was not found.' is displayed. This occurs when entering an invalid IPv4 or IPv6 numbering or a hostname in tmsh. The system posts the message. Workaround: None.
ID 362225 Disabling connection queuing via "tmsh edit" while connections are queued causes the queued connections to become stuck. This occurs when using tmsh edit while connections are queued. Queued connections become stuck. Workaround: The workaround is to use tmsh modify command instead of edit.
ID 362405 If a vdisk migration occurs, the original copy is left unchanged on the source slot. The copy is never synchronized with the new vdisk copy on the destination slot. After vdisk migration is successful, the original vdisk can be safely deleted but can also be kept as a valuable backup. However, note that if the guest is once again allocated to the slot containing the old vdisk, then that old vdisk is used without it first synchronizing with any other vdisk. This might result in unexpected behavior, for example: If that slot is the only one the guest is allocated to, it boots up with the old software, configuration, and license that existed on the guest at the time the guest was migrated to another slot. If, however, the guest is already deployed on other slots, the guest uses the old vdisk on that slot but synchronizes the software, configuration, and license from the guest's primary slot, per normal clustering behavior. Workaround: None.
ID 362874 There is a misleading Upgrading Device Trust banner that can appear on GUI. The banner indicates that the device is waiting for its peer to be contacted. This occurs when a device that is configured to be in a redundant pair is upgraded to version 11.x, but its peer device cannot be contacted. After upgrading, the GUI might post the following message for several hours: 'Upgrading Device Trust Device trust is still being upgraded. Please do not make modifications to Device Management or Traffic Groups pages while this message is displayed.' Workaround: If the peer device is no longer in use, the following workaround should be used to remove the banner message: * Set the trust.configupdatedone db variable to 'true'. * Set the failover.isredundant db variable to 'false'. * Restart devmgmgtd. * Reset trust.
ID 363216 A virtual server might indicate 'vlans-disabled', but does not include a list of which ones are disabled if that list is empty. The tmsh list command does not indicate that a VLAN is disabled. This can bee seen only in GUI. "This occurs when you add a VLAN to a virtual server. The default setting is disabled. For example, this means that the virtual server is disabled for no VLAN entries, which is the default setting: ltm virtual sample_vs { destination any:any profiles { fastL4 { } } vlans-disabled }" Silently disables the VLAN added to a virtual server. Workaround: Running the command 'list ltm virtual all-properties' indicates whether the VLAN is enabled or disabled.
ID 363284 The cipher list 'DEFAULT:!NATIVE' is different on v10.2.2 (valid) and v11.0.0 (invalid, empty). This can cause configurations to fail loading on v11.x during the upgrade. This occurs because ciphers 'ALL' in the Client SSL profile only includes 'NATIVE' ciphers. That means that 'COMPAT' must be specified to include 'COMPAT' ciphers (e.g., EXP, EDH). As all SSLv2 ciphers are COMPAT ciphers, this also means that 'ALL:SSLv2' no longer includes SSLv2 ciphers. Note that this change impacts upgrade. Workaround: So if your configuration uses COMPAT ciphers, it requires a configuration change (to specifically include COMPAT ciphers) for upgrade to complete successfully.
ID 363541 You can create an 'and' rule for the default node monitor that includes the monitor '/Common/none'. This occurs with the none monitor. When this occurs, the state of the node is not reported correctly. Workaround: None.
ID 363756 Simultaneous blade-to-blade migrations of guests might occur. In rare instances, multiple migration tasks take longer than the allocated interval, and could time out. If this happens three times, the guest is placed in the "failed" state. This occurs with simultaneous blade-to-blade migrations of multiple guests on vCMP configurations. If multiple guests must migrate before power on, it is possible that the first two guests will likely migrate, while all others will fail due to timeout values. Workaround: "To recover a guest from this condition, wait until all guest migration tasks complete successfully or fail after three timed-out attempts. Then on any blade with a guest in the 'failed' state, execute the 'vretry' command. This will cause any guests in the failed state on that blade to retry the failed action. Executing 'vretry' one blade at a time and waiting until all migration tasks on that blade are complete will avoid these failsafe timeouts. If a guest's retry attempts also fail, re-provisioning the guest might resolve the issue. To do this, change the guest's state to 'configured' and then subsequently back to 'provisioned' or 'deployed', as preferred. Note that this might cause the guest to be allocated to a different blade."
ID 363912 In rare occasions, when there are no monitors assigned as the default node monitor, an entry 'none' may appear in the Active select box on the 'Default Monitor' page in the Configuration utility. This still represents the fact that no monitors are selected as the default node monitor and the BIG-IP system operates as such. This occurs because tmsh allows /Common/none for the default-node-monitor GUI displays correctly, but none is not in GUI by default. Workaround: None.
ID 364407 When vCMP is provisioned and guests are created, when vCMP is later deprovisioned, attempting to deletion/modification/etc. cannot succeed. Even after vCMP is deprovisioned, VLAN deletion/modification incurs a verification check that prevents VLAN from being deleted/modified. You cannot remove VLANs that a provisioned/deployed/configured vCMP guest made use of. Workaround: To work around this, reprovision vCMP, delete/modify the guest, delete/modify the VLANs, and then deprovision vCMP (reboot required).
ID 364522 A user with the app_editor role can create an app service; however, because app_editor users cannot create objects (they can only update and enable/disable them), app_editor users actually cannot create an app service. This occurs with users with the app_editor role. App_editors cannot add pool members unless node already exist. Workaround: There are two workarounds: 1. Use the new add_member_v2 method, which does not have this constraint (the add_member command is deprecated). 2. Have a user with the appropriate role create/manage the node address prior to using add_member.
ID 364588 Running the show cmd from /Common to display pool in another partition does not show all of the information. This occurs when you run the show command from /Common partition to display the details of a pool in another partition. The monitor instance line is missing. Workaround: To work around this, navigate to the partition first. Then the show command presents the expected results.
ID 364717 There is an issue when using the node-port option with the delete command for persistence persist-records. This occurs when using the delete command to delete persistence records on a nonexistent port. The system deletes all the persist table entries irrespective of the port specified. In addition, the show command with nonexistent port displays all the entries irrespective of the port specified. Workaround: None, except to ensure that the port exists before deleting the persist table entries.
ID 364978 If an active/standby system is misconfigured with unit 2 failover objects, two traffic groups are automatically created: traffic-group-1 and traffic-group-2. This occurs when an active/standby system is misconfigured with unit 2 failover objects. For traffic-group-2, the default device points toward the unit 2 box. Instead, it should point to the unit 1 box, because it is an active/standby pair. Workaround: "To work around this, modify the default device to point to the unit 1 box, using a command similar to the following: tmsh modify /cm traffic-group traffic-group-2 default-device <unit 1 device name>"
ID 364994 When OneConnect is in use, server-side flows are reused, whenever possible. If this is disabled client-side (via an iRule), this can lead to a tmm crash if the server-side flow is not in a reusable state. This happens when OneConnect is enabled. tmm crash if the server-side flow is not in a reusable state Workaround: "Add: when SERVER_CONNECTED { if { [info exists oc_reuse_ss_disable] } { ONECONNECT::reuse disable ONECONNECT::detach disable } } and rewrite client-side thus: set oc_reuse_ss_disable 1 # pick a new connection, so SERVER_CONNECTED fires ONECONNECT::reuse disable CACHE::disable COMPRESS::disable HTTP::disable"
ID 365006 Installing a 10.x UCS on a "clean" 11.0 will cause daemons on secondary blades to restart. Workaround:
ID 365219 "Trust upgrade fails when upgrading from version 10.x to version 11.x. The upgrade fails without apparent error, but there will be one of the two following error messages in /var/log/ltm log: -- com.f5.devmgmt.certmgmt.TrustConfigUpdateForHAPairTask.run(TrustConfigUpdateForHAPairTask.java:425): Trust configuration update for HA Pair has failed: [STACK TRACE: {java.lang.Exception: Config sync password is invalid.}{ at com.f5.devmgmt.certmgmt.TrustConfigUpdateForHAPairTask.run(TrustConfigUpdateForHAPairTask.java:200)}. -- devmgmtd[7983]: 015a0000:3: Trust Config Update: [TrustConfigUpdateForHAPair.cpp:521 ] Skipping already-completed trust." Upgrading high availability version 10.x configurations that use the factory default admin password. Trust upgrade for version 10.x high availability configuration fails. Workaround: Change the default admin password in the 10.x configuration before upgrading to 11.0.0. This is intended functionality. The default admin password should be changed before deployment.
ID 365555 The DES ciphers have been deprecated for TLS V1.2 but TMM is including them. These ciphers are supported on earlier versions of SSL/TLS, such as SSLv3 and TLS v1.0, which are widely used. TLS v1.2 is trying to depreciate and move to higher standards. Workaround: None. F5 recommends that you do not use these ciphers.
ID 365756 During the load of a bad SCF file, once an error occurs, the user is left in the partition folder where the error occurred. If the user attempts a second load, they get an error: 'Data Input Error: 01070734:3: Configuration error: Invalid mcpd context, folder not found'. This occurs when loading a bad SCF file. The system changes the cli location to folder that has the error. Workaround: Fix the SCF file, change directory/context back to /Common and attempt to reload.
ID 365757 Mixed mode is presented as an option for extra disks. When trying to change the mode for logical disks, the system presents all options in the GUI and tmsh, even those that are not valid. When applied, this configuration option presents an error message: '01071372:3: Cannot change the mode for logical disk (HD2) from (NONE) to (MIXED). Disks cannot be changed to MIXED or CONTROL modes.' Workaround: Only None and Datastor are functional modes for extra disks.
ID 365767 The verify option during a load .scf file operation from tmsh on the VIPRION system will cause mcpd to restart. To work around this issue, do not use the verify option on VIPRION. Workaround:
ID 365836 Changing provisioning using two commands in sequence (for example, LTM=none and VCMP=dedicated)in TMSH results in a fatal TMM error. That happens when typing the two TMSH provisioning commands LTM=none and VCMP=dedicated in succession. This results in a fatal TMM error, and, if the config was not saved after entering the provisioning commands, the primary reboots, which results in no provisioned modules or the previous provisioning settings. Workaround: Use the GUI or iControl to adjust the system provisioning level. Or, issue a provisioning transaction for vCMP with a custom command at the root. The following example shows how to set LTM=none and VCMP=dedicated. 'echo "create cli transaction;modify sys provision ltm level none;modify sys provision vcmp level dedicated;submit cli transaction;quit"|/usr/bin/tmsh'. When you run this transaction, secondary blades will likely reboot automatically. The primary might reboot automatically as well. If the primary does not reboot and the status is REBOOT_REQUIRED, wait two full minutes before rebooting the primary blade. Waiting ensures that provisioning completes, the secondaries have rebooted, vcmpd starts, and the system enters a quiescent state.
ID 366060 There is an issue that is rarely encountered in FTP mirroring. FTP mirroring occasionally fails when connections come from tmm0. "When it does fail, the idle timer on the standby is not updated and the connection is reaped in the 30-50 second range." Workaround: None.
ID 367072 Running the command 'tmsh show sys hardware' on appliance-based system shows a Registration Key field with a -- value, even on licensed systems. This field is designed only for chassis-based systems, so you can ignore the value This occurs on appliance-based systems when running the command. The Registration Key field contains a -- value. Workaround: There is no workaround, but this field is designed only for chassis-based systems, so you can ignore the value.
ID 367198 Running 'tmsh show sys hardware' on appliances shows a blank Registration Key field. This occurs when running this command on hardware other than VIPRION chassis. Blank Registration Key field. Workaround: This is by design; this field is intended for VIPRION chassis only.
ID 367714 When accessing the serial console on some BIG-IP platforms, if the baud rate is changed repeatedly on the serial client, the serial console port may cease functioning. In this case, a reboot of the BIG-IP system is required to restore serial console functionality. "This problem is known to occur on BIG-IP 6900 appliances, and may also occur on BIG-IP 1600, 3600, 3900, 8900, 8950, 11000 and 11050 appliances. This problem has been observed to occur more frequently when connecting to the BIG-IP serial console from a client using a USB-to-Serial adapter. Different makes and models of USB-to-Serial adapters do not perform identically." The serial console interface to the affected BIG-IP system is lost. A reboot of the BIG-IP system is required to restore serial console functionality. Workaround: The BIG-IP system can be accessed via the management IP address, or by the AOM management IP address if so configured. For more information, see SOL13331: The BIG-IP serial console port may lock up when the terminal emulator is configured with a mismatched baud rate, available at http://support.f5.com/kb/en-us/solutions/public/13000/300/sol13331.html.
ID 367996 Chunked HTTP responses might not be unchunked before they are compressed and forwarded to the client. This issue occurs when the following conditions are met: - The NTLM and OneConnect profiles are applied to a virtual server. - HTTP compression is enabled on the virtual server. This can also be triggered when replacing the NTLM profile with an APM access policy configuration on the virtual server Client connections might fail. Workaround: To work around this issue, you can either modify the type of response chunking or disable compression. For more information, see SOL14030: The BIG-IP system may fail to unchunk server response when compression is enabled, available here: https://support.f5.com/kb/en-us/solutions/public/14000/000/sol14030.html.
ID 368888 The system allows you to create a virtual server (which creates the virtual address) in traffic-group 2 and a SNAT translation IP in traffic-group 1, and then to assign the SNAT IP to the virtual IP address, even though doing so could cause asymmetric routes if these traffic-groups were not active on the same unit. This occurs with multiple traffic groups and SNAT translation tables. This configuration might cause asymmetric routes. Workaround: To workaround this, only perform this type of configuration when two traffic groups are active on the same unit.
ID 369596 'tmsh show ltm pool' command doesn't show the latest updates for connection and rate limits. The connection and rate limits do not get published to the UIs until a monitor instantiates a state change on the pool member or node. Note that this does not impact the data path, it is only a UI issue. Configure a pool member or node to have connection or rate limits. Workaround:
ID 369640 If an iRule is assigned to two different virtuals in different contexts, the first time the rule runs any internal object conversions/lookups will be performed in the first context. When the second virtual runs the same rule, it will assume that the objects that have been looked up are correct, and point to the wrong members. Two virtuals in different folder paths use short names for objects like pools, procs, nodes and virtuals. iRule can point to objects outside the current folder path. Workaround: Give each virtual it's own copy of the iRule (it is not necessary to provide complete folder paths).
ID 371647 When using ACA kerberos delegation, users must manually add the iRule _sys_auth_krbdelegate to their profile. This step must be manually done when using kerberos authentication in ACA. This does not apply to APM authentication. Workaround: Add the iRule.
ID 372209 When the certificate used to verify a signed iRule expires, the iRule verification status still remains 'Verified' as long as the certificate exists on the device. This occurs when an expired certificate that was used to sign an iRule still exists on the system The iRule status remains 'Verified', even though the certificate is expired. Workaround: To avoid the misleading status, the signature for iRules signed with an expired certificate should be modified to have the 'ignore verification' property set to true, or edited to remove the signature (edit the rule and remove the 'definition-signature' line).
ID 373467 MD5 certificate do not work with TLS 1.2. This occurs with TLS 1.2 and MD5 client certificates. Client does not authenticate with certificates signed with rsa-md5. Workaround: None.
ID 374067 Using the 'snatpool' command in the CLIENT_ACCEPTED iRule event causes keepalive requests to originate from the self-IP of the BIG-IP system. An iRule using the 'snatpool' command in CLIENT_ACCEPTED. Keepalive connections occasionally source from the BIG-IP system's self-IP address. Workaround: Use the HTTP_REQUEST event to set the SNAT pool.
ID 374109 The radvd config is not migrated to tmsh syntax during a UCS restore. The workaround is to create the config manually with tmsh. Workaround:
ID 374333 When the rate of new connections (CPS) is extremely low, observed/predictive load balancing can perform uneven connection distribution across pool members. Configure a pool using predictive or observed load balancing methods. Uneven connection distribution across pool. Workaround: None.
ID 375207 On rare occasions, tmsh writes an innocuous error message to /var/log/ltm based on a query to mcpd. Here is one case that issues the message: In tmsh, type the command 'generate sys icall event', and then press the tab key. The following error is posted: 01070734:3: Configuration error: Invalid wildcard query, invalid or missing class ID. Workaround: None, but this message is innocuous and can be safely ignored.
ID 375605 Management IP addresses that are not saved in the configuration can remain on the interface after a reboot. This occurs if you change the management IP address, but then reboot the system before saving the configuration. Can result in inconsistent system configuration that may be difficult to discover and correct. This is a rarely encountered timing issue. Workaround: Rebooting again or removing the unwanted address manually will solve the issue.
ID 375887 Using the cluster member 'disable' command with a trunk that spans blades can cause a brief period where received broadcast and multicast packets egress out the enabled trunk members of the cluster. This occurs on a trunk that spans blades. To an external device running spanning tree protocol or variant, this can look like a loop. Workaround: None.
ID 376120 When a non-default route domain is configured for dynamic routing, then subsequently deleted and re-added, tmrouted might restart. Non-default route domains in use. Dynamic routing for all route domains is interrupted. Workaround:
ID 376166 QSFP+ module ports do not allow a media capability setting of 1 GbE. This occurs when setting the media capability of the 10 GbE port to 1 GbE. This action fails to turn the 'link-up' LED to amber; the LED remains green. Workaround: None. This action is not supported on this port.
ID 376447 If a VLAN group member is used in the configuration of another object, an error may result. It should not be possible to add that VLAN directly to a route domain since it is part of a group, however, if you create a new route domain. The VLAN appears. Attempting to add that VLAN results in the error. This occurs when using tmsh or iControl and the VLAN group feature. "The system posts an error similar to the following: 01070712:3: Caught configuration exception (0), Cannot create vlan 'vlanx' in rd0 - ioctl failed: File exists - net/validation/routing.cpp, line 395." Workaround: To avoid the problem, when using tmsh and the VLAN group feature, only use the VLAN groups, never their members, when configuring other objects. Furthermore, it is not necessary to work with the VLAN group member (that is, in this case, the group is already in the route domain, so adding the VLAN itself is not even necessary).
ID 377231 VIPRION B4300 blades only support 9600 and 19200 baud, even though other baud rates are accepted. This occurs when using baud other than 9600 or 19200 on VIPRION systems. You can select other baud rates, but they do not work. Workaround: None. VIPRION B4300 blades only support 9600 and 19200 baud.
ID 378055 The serial console on the B2100 blade in a VIPRION C2400 chassis cannot be set to 38400 using the tmsh command 'tmsh mod sys console baud-rate 38400,' but can be set using the AOM Command Menu. After setting to 38400 via the AOM Command Menu you can use the tmsh command to see that the baud rate has been set to 38400. This occurs on the B2100 blade on a VIPRION 2400. Cannot use tmsh to set baud rate to 38400. Workaround: Use AOM to set baud rate to 38400.
ID 378967 Users in partitions attached to sync-only device groups do not sync to other devices in that device group. There are users whose active partitions are attached to a sync-only device group. This affects sync-only device groups only, not the failover device group. Workaround: None.
ID 379002 MSRDP persistence fails when pool members are in route domains, causing the pool's load-balancing mechanism to be used instead. A configuration with route domains and MSRDP persistence. Connections will be load-balanced in perpetuity. Workaround: Do not use route domains if possible.
ID 380047 Listing objects that exist in partitions other than /Common shows no results. This occurs when you are in the /Common partition and you attempt to list objects that exist in another partition, for example, running the command 'list ltm profile ntlm my_subfolder/my_ntlm_profile' when /Common is the active partition. Listing certain objects in subfolders of the current folder (e.g. 'list ltm profile ntlm my_subfolder/my_ntlm_profile') may not show any output. Workaround: As a workaround, you can change into the partition ('cd my_partition') and then list the object: 'list ltm profile ntlm my_ntlm_profile'.
ID 380415 TMM CPU utilization statistics reported by sFlow or by running 'tmsh show sys tmm-info' are less than actual TMM CPU utilization. This occurs when using sFlow or by running 'tmsh show sys tmm-info' to report TMM CPU utilization statistics. The values reported are less than actual TMM CPU utilization. Workaround: TMM CPU utilization stats can be found by running 'tmsh show sys proc-info tmm'.
ID 381123 Enabling more than 10 sFlow receivers may impact the performance of the BIG-IP system and, therefore, is not recommended. This occurs when using more than 10 sFlow receivers. Slower system performance. Workaround: None. This configuration is not recommended,
ID 381710 The test-monitor and test-pool-monitor commands require the monitor or pool argument to include its partition; e.g. /Common/pool1. This occurs when using these commands inside a partition. Tab completion from inside a partition causes the partition name to be omitted. Workaround: To work around this, run these commands from the root partition, or to manually type the full pool or monitor argument including partition.
ID 382040 Config sync fails after changing IP address of a pool member with a node name. IP addr change achieved by deleting the pool member and node then recreating the pool member/node. "Delete an existing pool member which has a node name set. Recreate the pool member with a different IP address using the same node name before syncing the config. Sync the configuration. ltm pool ip_mod_pl { members { ip_mod2_nd:http { address 10.168.1.4 } ip_mod_nd:http { address 10.168.1.1 } } } ltm node ip_mod2_nd { address 10.168.1.4 } tmsh modify ltm pool ip_mod_pl members delete { ip_mod2_nd:http} tmsh delete ltm node ip_mod2_nd tmsh modify ltm pool ip_mod_pl members add { ip_mod2_nd:http { address 10.168.1.5 }} tmsh run cm config-sync to-group S48-S49 On 11.4.0 and up this only happens if a full load is being done. Note that full loads may still happen on occasion even if full-load-on-sync is false for the device group." Config sync fails Workaround: Current work around is to delete the pool member and node on the peer then sync the configuration. The issue does not affect pool members/nodes with no name associated with the node.
ID 382252 If TMM cores, the High Speed Bridge (HSB) driver clears its transmit and receive ring buffers as part of its shutdown routine. This causes the loss of HSB ring buffer data and state information that might be useful in diagnosing the cause of certain TMM cores resulting from invalid buffer data. "- BIG-IP platforms containing a High Speed Bridge (HSB) FPGA device. - A TMM core occurs." HSB ring buffer data and state information, that might be useful in diagnosing the cause of the TMM core, is not preserved in the resulting TMM core. Workaround: None.
ID 382363 The system does not require min-up-members of a pool to be set greater than zero when also using gateway-failsafe-device on the same pool. A pool's min-up-members is 0 when gateway-failsafe-device is set. Failure to set min-up-members greater than zero when using gateway-failsafe-device might cause errors. The tmm might crash. Workaround: Set min-up-members greater than zero when using gateway-failsafe-device.
ID 382577 When you run the imish 'terminal monitor' command, you do not receive the expected results. The imish command has no effect in TMOS. This occurs when running imish command. There is no display of debug logs in the imish session. Workaround: The workaround is to configure the log file (under /var/log) and use the tail command to monitor it in real-time. Note: For this workaround, users must have access to bash.
ID 382613 On VIPRION 4400 chassis containing B4100 blades, the Speed LED stays with solid yellow when at 10Mb. VIPRION 4400 chassis containing B4100 blades. The Speed LED stays with solid yellow. Workaround: This is not an indication of a problem with the system, even though the Platform Guide: VIPRION 4400 Series indicates that the Speed LED should blink yellow.
ID 382804 There is a difference in time zone adjustment between VPE and tmsh. When a date and time is entered in tmsh, it is interpreted as local time. The input time is adjusted and stored as GMT time. However, when a date and time is entered in the VPE, there is no time zone adjustment. For this reason, the timestamp entered through tmsh will be different than the one entered through the VPE for the same date and time. As a result, pre-logon inspection will fail when using tmsh to configure the agent for endpoint Linux check file. Workaround: The recommended workaround is to use the VPE to configure the agent for endpoint Linux check file. If tmsh must be used, then subtract or add the difference from your time zone with respect to GMT. PST time zone is -8:00hr from GMT. The date and time for the agent must be -8:00hr from PST.
ID 383128 While upgrading or booting between versions on the VIPRION B2400, B4200, and B4300 Blade Series, it should be expected that firmware upgrades between versions may delay the cluster from becoming active by up to fifteen minutes. This occurs when upgrading or booting between versions on VIPRION blades. Firmware upgrades between versions may delay the cluster from becoming active by up to fifteen minutes Workaround: None.
ID 383442 If a packet is split into multiple fragments and the matching part of the tcpdump filter is in a later fragment, it does not match. This occurs on multi-fragment packets. The tcpdump packets do not match. Workaround: None.
ID 384451 SSL per-virtual stats might cause SSL profile cert/keys/chain to be instantiated per-virtual server. This occurs when using cert/keys/chain in SSL profile virtual servers. In this case, cert/keys/chain are are duplicated and those duplicates might cause excessive memory use and disk activity which might lead to SIGABRTs and low-memory conditions. Workaround:
ID 384717 While viewing 'watch-trafficgroup-device', if devices in the device group change, 'watch-trafficgroup-device' can sometimes become non-responsive. This occurs while viewing 'watch-trafficgroup-device' if devices in the device group change. The 'watch-trafficgroup-device' can sometimes become non-responsive. Workaround: Killing the tool and restarting after the device group membership stops changing keeps the 'watch-trafficgroup-device' running stable.
ID 385508 Loading a pre-11.0.0 UCS onto a system running 11.0.0 or later resets the device trust group, and should be avoided after the original migration. Save a new 11.x UCS immediately after migration is complete and use that UCS going forward. Migrating with pre-11.0.0 UCS onto system running 11.0.0. Resets device trust group. Workaround: None.
ID 385825 The CMI watch_* scripts (such as watch-devicegroup-device, watch-sys-device, watch-trafficgroup-device) should not be allowed to run indefinitely as they may adversely affect performance of the unit after a few hours. Run a CMI watch script for an extended period, for example: 'tmsh run cm watch-devicegroup-device'. May cause processes to fail, or unit to failover or unexpectedly reboot when non-tmm memory is exhausted. Workaround: The CMI watch-* scripts (like watch-devicegroup-device) should not be allowed to run indefinitely. Usually problems will occur after a few hours, so keeping runs to less than an hour should normally be safe.
ID 385915 When using the tmsh command 'list net interface all lldp-tlvmap' to display the lldp-tlvmap values, you might see values that deviate from the default of 130943 (for example, 114552). "This issue occurs when Link Layer Discovery Protocol (LLDP) is enabled and you use the BIG-IP Configuration utility to manually update the properties of a BIG-IP interface. This issue occurs when unused bits in the Type, Length, Value (TLV) bitmask are incorrectly set." None. This issue is purely cosmetic. Workaround: Manually modify the value as needed.
ID 386778 IPsec in HA deployment cannot use anonymous ike-peer. This occurs when using IPsec in an HA configuration. The tunnel is not created. Workaround: - Create a new ike-peer with the required remote IP field holding the remote peer's IP address. - If using RSA (the default) uncheck the verify certificate field (not required when using PSK). - Change the presented ID and verified ID fields to 'address'.
ID 387106 Ramcache statistics are associated with only one virtual server per profile. The statistics for all of the virtual servers that use this profile are reflected in the ramcache statistics for that virtual server. This occurs in reporting ramcache statistics. System reports statistics for only one virtual server per profile. Workaround: The workaround is to create a copy of the profile for each virtual server if the individual statistics are desired. However, this adds complexity to the configuration and should only be done when necessary.
ID 387448 Monitoring device group status from a device from outside the group might return an incorrect status. When monitoring device group status from a device that does not belong to that group, the config sync status reported could be inconsistent with the device-level status. For example, the sync status for device A is 'Changes Pending,' but the device-group to which device A belongs shows a status of 'In sync.' Workaround: View the sync status from a device in the device group.
ID 388098 Running dmesg can report hda cable detect errors. This occurs when running dmesg. dmesg might display a message similar to the following: 'localhost warning kernel: hda: host side 80-wire cable detection failed, limiting max speed to UDMA33'. Workaround: None. This is expected and does not indicate any problem with the hardware or software.
ID 388273 On a VIPRION, the failover daemon does not communicate correctly with the peer chassis unless the management port is configured on each blade. This occurs on a VIPRION when the failover daemon attempts communication with the peer chassis. Communication does not occur correctly, and both chassis can become active for an interval of time. Workaround: Configure the management port on each blade. Specifically, assign a network address and subnet to the management port for each blade.
ID 389397 On 12050/12250 (D111) and 10350N (D112) platforms, setting the db variable platform.powersupplymonitor to disable might not stop power supply error messages on power supplies that are connected but not turned on. This occurs on BIG-IP 12050/12250 (D111), 10350N (D112), and 10000s/10050s/10200v/10250v (D113) platforms on which platform.powersupplymonitor is set to disable. The power supplies in the system that are not turned on might log error messages until power is removed. Workaround: Remove power on disabled power supplies.
ID 389912 A chassis uses a yellow Secondary LED on secondary blades of the standby device to indicate that the chassis is in standby mode. On a chassis containing a single blade, there is no way to indicate standby mode with the blade LED(s). This occurs on single-bladed chassis in the standby mode. There is no blade LED indication that the chassis is in standby mode. Workaround: None.
ID 389976 There is a memory leak in the kerberos delegation feature. There is no current workaround. Using Kerberos Delegation in Advance Client Authentication. APM functionality is not affected. Workaround:
ID 390423 Performing a 'sync from group' causes a mismatch in LSS 'Last Successful Sync' IDs. This occurs when viewing the configsync status from devices outside of a device group but in the trust domain. Viewing configsync status might be incorrect on some devices and not others. Workaround: View the sync status from a device within the device group.
ID 390764 BFD session may not show the correct session "Up Time" value when user displays BFD session information using the IMI shell command 'show bfd session detail'. any bfd session parameter is modified through imish. "No functional impact. Only diagnostic. BFD session will appear has having bounced when it has not." Workaround: None
ID 392085 On a standalone BIG-IP system, on the properties screen for Device Management, the Force to Standby button might become available. Since this is a standalone unit and there is no active-standby configuration, this button is not valid and it should not be clicked. This occurs on a standalone BIG-IP system. The Force to Standby button might become available, even though it is not valid. Workaround: None.
ID 393647 The availability status for objects configured with a connection rate-limit can remain yellow even if the object is available to handle traffic. This occurs when using objects configured with a connection rate-limit. Once the connection rate falls below the configured value, the object's status will continue to show unavailable until the object receives additional traffic. Workaround: None. However, this is a cosmetic issue and is limited to testing scenarios where the test tool stops sending traffic upon receiving a reset packet. ApacheBench is one such tool. In real world scenarios, continued traffic processing automatically restores the correct status.
ID 395148 When setting the baud rate for the front panel serial management port using the AOM command menu, the LCD display does not reflect the baud rate change until fpdd is restarted. This occurs when changing the baud rate using the AOM command menu. The incorrect baud rate might be shown. Workaround: Restart fpdd using the command 'bigstart restart fpdd'.
ID 395269 Reapplying a template to reconfigure an Application Service Object deletes any firewall rules that have been created through the Security screen. This occurs when reconfiguring an iApp. Firewall rules are deleted. Workaround: To retain a set of firewall rules, include creation of the desired firewall rules in the template itself.
ID 395720 On the BIG-IP 4000 platform, sometimes on boot, Ethernet devices do not get renamed. For example, eth6 should be renamed to pf1-7. This occurs on the BIG-IP 4000. Ethernet devices do not get renamed. Workaround: To work around this issue, reboot the device.
ID 396122 In a non-homogeneous cluster, validation on a secondary blade may fail if the module is not allowed or resources are not available. Workaround: Make sure the primary member of a cluster is the blade with the least available resources (Puma1).
ID 396273 When running dmesg, you might see errors similar to the following: 0000:17:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update. This can occur when 'lspci -vvv' has been executed. This is a benign message, and you can safely ignore it. Workaround: There is no workaround, but this is not a functional issue.
ID 396278 If you set MGMT IP address using the LCD module, the ltm log contains a message stating the management route was not found. This is the message: Aug 31 12:01:20 localhost err tmsh[9771]: 01420006:3: 01020036:3: The requested management route (/Common/default) was not found. This is a benign logging message that is reporting a non-existent error condition. This occurs when you set MGMT IP address using the LCD module on 1600, 2000, 3600, 3900, 4000, 5000, 6900, 7000, 8900, 10000, and 11000 platforms. The system writes this message to the ltm log: Aug 31 12:01:20 localhost err tmsh[9771]: 01420006:3: 01020036:3: The requested management route (/Common/default) was not found. Workaround: There is no workaround, but this is a benign logging message that is reporting a non-existent error condition.
ID 396293 SNAT bounceback does not work when the non-default CMP hash is used on a VLAN carrying that kind of traffic. This occurs with SNAT bounceback using non-default CMP hash. SNAT bounceback does not work. Workaround: None.
ID 396294 At startup, the BIG-IP 4000 logs a message 'SwEdge Error: No core edge found' in /var/log/ltm. This occurs at startup time on the BIG-IP 4000. The system logs the message 'SwEdge Error: No core edge found' in /var/log/ltm. Workaround: None. This message is benign and reports a non-existent error condition.
ID 396831 Provisioning Virtual Clustered Multiprocessing (vCMP) on 2000/4000 series platforms can cause a kernel panic. vCMP is not supported on these platforms. This can occur on the 2000/4000 series platforms. A kernel panic can occur. Workaround: The release notes contain information about which platforms support vCMP. You can also check the AskF5 Knowledgebase. If a vmdisks application-volume was created on a platform that does not support vCMP, it should be removed.
ID 398947 It is possible that the text 'serial8250: too much work for irq4' may be seen on the host serial console. These messages are extremely rare. The cause of the message is a temporary overload of the serial port. However, once the serial port has recovered from the overload, it continues to operate normally. The system might post the text 'serial8250: too much work for irq4' may be seen on the host serial console. Workaround: None. No character loss on the console has been observed when this condition is encountered.
ID 399073 You might encounter the error 'err ntpd[5766]: Frequency format error in /var/lib/ntp/drift' in /var/log/daemon.log once after boot. This occurs after boot. The system posts the error: err ntpd[5766]: Frequency format error in /var/lib/ntp/drift. Workaround: None. This message indicates an innocuous condition.
ID 399470 Switch based platforms incorrectly identify Fiber Channel SFP modules. This occurs on switch based platforms. The platform incorrectly identifies the Fiber Channel SFP. Workaround: None. Switch based platforms do not support Fiber Channel SFP modules.
ID 399726 "tmm restarted during license or config loading. New tmm core file is in /shared/core. Message ""HA daemon_heartbeat tmm fails action is go offline down links and restart."" from sod daemon in /var/log/ltm file." It occurs when tmm takes more than 10 seconds to mmap in the GeoIP files as part of license loading process because of high disk latency. It may trigger failover. Workaround:
ID 400078 When removing a pluggable module from some specific ports on 4300/4340N blades or on the 10000 and 12000 series platforms, it is possible for the adjoining ports to lose link briefly. For example, this might occur when removing a pluggable module from the 4300 blade's ports 1.1 or 1.5 When this occurs, it may cause established link on ports 1.2 or 1.6 respectively, to drop briefly. Workaround: None. Workaround: None.
ID 400346 A DHCP option field populated with a properly formatted URL in a DHCP response may cause the dhclient process to generate an error. This occurs when DHCP sends a response containing characters such as forward slash and colon, such as might exist in a URL specified with the server-name, merit-dump or filename options. The system posts a message in daemon.log: 'err dhclient: suspect value in server_name option - discarded'. This message is benign and can safely be ignored. Workaround: The message can be avoided by configuring the DHCP server to distribute a specific lease without the DHCP option, or configuring the BIG-IP management port with a static IP address. Note that the DHCP option may be required for PXE installations, or can be specified during PXE installation time.
ID 400584 lsn-pool object can be created without any member prefix, however will not function for translation until prefixes are added. lsn-pool without any member prefix lsn-pool without any member prefix will no perform translation Workaround: add prefixes to lsn-pool
ID 400778 On a VIPRION system during failover in which the blade transitioning from secondary to primary, log messages make it appear that chmand is looking to delete logical disks on CF1 and HD1. This occurs on VIPRION systems. The ltm log displays messages: 'Oct 9 01:31:00 slot2/cluster err chmand[6909]: 012a0003:3: Physical disk CF1 not found for logical disk delete', 'Oct 9 01:31:00 slot2/cluster err chmand[6909]: 012a0003:3: Physical disk HD1 not found for logical disk delete'. Workaround: None. These messages are benign and you can safely ignore them.
ID 402115 Using the command 'tmsh show sys memory' displays zero usage for some entries. Any running product. The division of memory usage may not be clear. Workaround: None. However, the information shows the most important value, which is the memory utilization of each thread; the memory available to each thread is derivable from the total.
ID 402455 Before attempting synchronization using the GUI setup wizard, clocks of the BIG-IP devices must be synchronized. It is recommended to use an NTP server for completing this operation. This occurs when using the setup wizard. Establishing device trust group fails. Workaround: To facilitate this, synchronize the clocks of the BIG-IP devices, preferably using an NTP server.
ID 402855 If a config is created with route domains and a config is created that is identical except without any route domains, then while one config is loaded, a load of a UCS of the other config may fail. Load will fail initially. Once defaults have been loaded, the configuration may be loaded again. Workaround: "Clear the current config by loading defaults before loading the UCS. i.e. tmsh load sys config default ; tmsh load sys ucs <ucs_name>"
ID 402873 Source IP address for SNMP traps is inconsistent. For example, traps regarding monitor up/down status are sent with the TMM self IP as the source IP; however, traps regarding the restart of the SNMP agent are sent with the management IP as the source IP. The desired destination for SNMP traps is configured on TMM interface(s), and there is no specific management route configured. Routing change, or SNMP manager does not accept the SNMP trap if it does not come from the registered source IP address. Workaround: "The recommended workaround is to configure a specific management route to make the SNMP traps consistently source from the management IP address. The following configuration will make the SNMP traps consistently source from the TMM self IP address (10.x.x.y): sys snmp { traps { my_trap { community public host 10.x.x.z } } } ltm rule trap_translate { when CLIENT_ACCEPTED { log local0. ""original src-ip is [IP::client_addr], going to translate"" snat 10.x.x.y } } ltm virtual-address 10.x.x.z address 10.x.x.z arp disabled mask 255.255.255.255 traffic-group traffic-group-1 } ltm virtual trap_translate_vip { destination 10.x.x.z:snmptrap ip-forward ip-protocol udp mask 255.255.255.255 profiles { fastL4 { } } rules { trap_translate } translate-address disabled translate-port disabled vlans-disabled }"
ID 403002 It is not possible to set up configuration synchronization using a configsync-ip on a nonzero route domain, but the system does not prevent you from configuring a device in this manner. This occurs when configuring route domains. The system does not prevent configuration of nonzero route domain. Workaround: None.
ID 403613 The drop counters for the 1.x interfaces on the 2000s / 2200s and 4200v platforms currently do not work in LTM mode due to a hardware issue. This occurs on 2000s / 2200s and 4200v platforms drop counters for 1.x interfaces. Drop counters do not work in LTM mode. Workaround: There is no workaround.
ID 403688 Hardware syncookies currently require both client side and server side profile context to have hardware syncookies enabled in order to function. This occurs with hardware syncookies. Hardware syncookies do not function. Workaround: Enable client side and server side profiles for hardware syncookies.
ID 403764 If a log message is not matched by any filter, then the log will be processed by the syslog-ng daemon. Workaround: To disable log processing by the syslog-ng daemon, create a filter with source equal to "all" and level equal to "debug" then route as desired.
ID 404398 Using tmsh merge to update route-domains does not work. Workaround: A workaround is to manually merge the changes to /config/bigip_base.conf (or /config/partitions/<partition_name>/bigip_base.conf) and load.
ID 404588 LSN iRules persistence-entry get/set and inbound-entry get/set might not work properly for RTSP if the 'after' command is used. This occurs when using the 'after' command. LSN iRules persistence-entry get/set and inbound-entry get/set might not work properly for RTSP. Workaround:
ID 405255 Issuing a 'reset-stats net interface' command in tmsh does not clear the stats for an interface with status 'disabled'. This occurs when resetting stats on a disabled interface. Stats do not reset. Workaround: Enabling the interface with 'modify net interface x.y enabled' before resetting stats causes the stats to correctly clear. The interface can be disabled again afterwards if needed.
ID 405356 Hot swapping hard drives at a rate of approximately once per second may result in the drive failing to show back up after insertion. Occurs when the swapping occurs at a rate of approximately once per second. Loss of access to an affected drive. Workaround: "It is possible to recover missing devices by manually forcing the kernel to rescan the SATA/SCSI host bus. To find out how many SATA/SCSI busses you have: shell> ls -l /sys/class/scsi_host/ drwxr-xr-x 3 root root 0 Feb 12 19:01 host0 drwxr-xr-x 3 root root 0 Feb 12 19:01 host1 drwxr-xr-x 3 root root 0 Feb 12 19:01 host2 drwxr-xr-x 3 root root 0 Feb 12 19:01 host3 drwxr-xr-x 3 root root 0 Feb 12 19:01 host4 drwxr-xr-x 3 root root 0 Feb 12 19:01 host5 To find out which device(s) may have an error perform the following: dmesg | grep -i sata Example Output: ata1: SATA link down (SStatus 0 SControl 300) (Indicating host bus 1 (ata1) is down. If you know the host interface which you need to rescan, perform the following: (wildcarding the Channel, Id, and LUN with '- - -'). shell> echo '- - -' > /sys/class/scsi_host/host<n>/scan (replace the <n> with the number of the SATA/SCSI host bus to be rescanned) NOTE: Do not perform this procedure on a mounted device! To verify the device was recognized and attached by the SATA/SCSI subsystem, use the proc interface. shell> cat /proc/scsi/scsi An example of the output: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1000CHTZ-0 Rev: 04.0 Type: Direct-Access ANSI SCSI revision: 05 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: WDC WD1000CHTZ-0 Rev: 04.0 Type: Direct-Access ANSI SCSI revision: 05 Notice after the 'Attached devices:' line above, there are 3 lines for each recognized device. Each host shows its host bus number. In the example above there are two devices. host bus 0 (scsi0) and host bus 1 (scsi(1)."
ID 405539 When you disable an interface, the state shows DISABLED. When you enable that interface, the indication for the interface still shows DISABLED. This occurs when using both tmsh and the GUI. The state of the interface remains DISABLED. However, the interface passes traffic after enabling. Workaround: You can reboot correct the indicator.
ID 406071 The command [clock -clicks milliseconds] on 32 bit versions of BIG-IP will return a 32 bit version of the integer milliseconds since epoch. Since this is larger than 2^31, the value will wrap. Greater than 2^31 ms since epoch The actual number of milliseconds since epoch is not accessible, but time differences less than 2^31 milliseconds work fine. This is 24.8 days. Workaround:
ID 406238 FTP active mode data connection does not work from the BIG-IP system command line, if the connection is exiting through an interface with SP DAG. "cmp-hash = src-ip or dst-ip ftp initiated from the BIG-IP" the data connection cannot be established with active mode. Workaround: Use FTP passive mode for data transfer.
ID 406500 Applying a self-ip to a tunnel type vlan will connect the objects. The self should not be deleted unless disconnected from the vlan. "Repro: create net tunnels tunnel t1 profile dslite local-address 10.10.10.1 create net self s1 address 10.5.10.1/24 vlan t1 create net route r1 interface t1 delete net self s1 modify net route r1 description ""test test"" You will receive an error about no self-ip" The problem may cause the system configuration to not load. Workaround:
ID 406878 If you have a version of TMOS on multiple devices configured for sync, when you upgrade them all to a later TMOS version, there might be inconsistency in what versions one device reports as being present on other devices. You can run the command 'list cm device' on a given device to see the version/build correctly shown for that particular device. This occurs after upgrading members of a trust domain from TMOS v11.0.0 or later. Sync occurs correctly; this is only a cosmetic problem. Workaround: Make a change to the device's description field, or some other non-operational change. This will force the device to advertise an updated trust configuration, including the updated version field.
ID 408599 iRule node command does not work under LB_SELECTED event Using iRule node command under LB_SELECTED node command does not function properly Workaround: Use node command under other events.
ID 408810 BIG-IP with Vyatta neighbor on a single link may appear to be stuck in ExStart/Exchange state because Vyatta incorrectly drops a database description packet containing a 24 byte router-LSA (zero link LSA). "OSPFv2 or OSPFv3 Neighbor is a Vyatta router" OSPF session will not come up Workaround: None
ID 409059 Hairpin connections are not supported for NAT64. "lsnpool with NAT64, hairpinning enabled" hairpinned connections will not work Workaround: Hairpin via upstream router
ID 410036 "If a client and server attempt to resume a TLS connection using TLS session tickets through a BIG-IP virtual server configured for Proxy SSL, the BIG-IP resets the connection. If Reset Cause Logging is enabled (refer to SOL13223), the reset cause is 'SSL Session Not Cached.'" #NAME? Resumed handshakes do not succeed, which might result in traffic disruption for the affected clients through the virtual server. Workaround: Disable TLS session tickets on either the pool members, or the client systems.
ID 410114 When OSPF protocol running on BIG-IP system sends a 24 byte router LSA, Vyatta discards such an LSA and this may cause OSPF protocol to get stuck in ExStart/Exchange and never reach FULL state. This occurs intermittently. OSPF v2 protocol configured between BIG-IP system and a Vyatta neighbor. OSPFv2 protocol does not synchronize without manual intervention. Workaround: In imi shell, run the command 'clear ip ospf process'. You might need to run the command multiple times.
ID 410223 For a virtual with a SIP profile configured as an ALG using the TCP transport, TCP FIN and RST packets are being unnecessarily sent by the BIG-IP to multiple peer clients/servers when one of the client/servers issues a FIN or RST packet. SIP ALG TCP virtual configuration and one of the clients/servers send a FIN or RST packet to the virtual. Unless the SIP clients/servers are configured to automatically reconnect when they receive an unexpected FIN or RST, the in-progress sessions/calls that are using the connection being closed will fail. Workaround: "Configure the mblb (message based load balancing) profile to isolate the clients and servers from RST and FIN packets generated by the other client and servers. Add the following mblb profile to the SIP virtual: ltm profile mblb /Common/test { defaults-from /Common/mblb isolate-abort enabled isolate-client enabled isolate-expire enabled isolate-server enabled }"
ID 411636 The LCD System is enhanced with a new menu for DHCP. This menu reflects the current DHCP value set using LCD DHCP, tmsh, or configuration scripts. If the DHCP value is enabled, the LCD System Management menu still allows setting values for the management data. If you check the front panel, it appears as if the address is actually used. In fact, there is no connectivity to the manually configured address, because DHCP configuration is still in use. This occurs only on appliances (that is, non-chassis systems). Attempting to save the changes results in a message: 'Disable DCHP from LCD before setting IP'. Workaround: To change the management IP address, use the LCD to disable DCHP first.
ID 411875 The persist command generates an erroneous intermittent error when resuming after server-side shutdown This occurs when the persist command parks and the flow is closed before it resumes. Any portion of the iRule following the park does not run, and the connection logs a spurious error. Workaround: Insert a [catch] around the [persist add].
ID 412458 It is possible to misconfigure a SIP ALG virtual by adding a transport protocol profile to the virtual server that does not match the ip-protocol of the virtual server. This invalid configuration will result in a core. If a UDP profile is applied, then the ip-protocol type should be udp. If a TCP profile is applied, then the ip-protocol type should be TCP. Workaround:
ID 414018 Hairpin connections between different subscriber hosts fail. The subscriber network(s) and the internet are in different route domains. Applications on different subscriber hosts cannot establish connections. Workaround: Use the same route domain for the subscriber networks and the internet.
ID 414160 Configuring the VLAN used for inter-device mirroring for an IP cmp-hash mode may cause errors establishing the mirroring connection between devices. Workaround: Configure the VLANs used for the mirroring connection with the default cmp-hash mode, not an IP cmp-hash mode.
ID 414454 When you update an iRule and replace an event that contains script content with a blank script, TMM cores with a stack trace. In response, TMM cores because it is trying to compile an empty script. Note that when creating a new iRule, there is a check for adding an event script with no content, so the error does not occur on create. This occurs when replacing iRule events containing valid Tcl code with whitespace or with no Tcl code. When the issue occurs, TMM cores with stack trace. Workaround: To work around this issue, delete or comment out the empty event, or insert a comment.
ID 415483 A license activated on 11.2.1, or later, is not backward compatible with software versions 11.2.0, or earlier An issue occurs after performing a software downgrade from version 11.2.1, or later, to software version 11.2.0, or earlier. The license becomes non-operational. Workaround: You must acquire a new License Key, or request for 'allow move' from F5 after downgrade.
ID 415961 Unused HTTP Class profiles are not rolled forward during upgrade or UCS restore. If you have defined HTTP Class profiles but have not assigned them to virtual servers, the system does not bring forward those profiles into the new configuration when you upgrade. No Policy is created from the HTTP Class profile and the profile does not appear in the new configuration. This occurs when upgrading a pre-v11.4.0 configuration with a HTTP Class profile not attached to a virtual server. You might lose unused HTTP Class profiles in the configuration. Workaround: Attach all HTTP Class profiles to a virtual server before upgrade or save of a UCS.
ID 416727 "Under rare conditions, a BIG-IP appliance may exhibit the following symptoms: - repeated reboots - chmand core - I2C errors in ltm log, such as: info chmand[5876]: 012a0006:6: I2C device not ready for writing, retrying - SMBus errors in kernel log, such as: err kernel: i801_smbus 0000:00:1f.3: SMBus is busy, can't use it!" "BIG-IP 1600 or EGW 1600 platform. Other platforms which may be affected include: BIG-IP 800, 3600, 3900, 6900, 89xx, 11000, 11050" BIG-IP is inoperative, systems reboots repeatedly. Workaround: "Power down the system from the AOM menu or LCD panel. Remove external power (complete cold power-down). Reconnect external power and boot BIG-IP."
ID 417045 Upon shutdown, the system posts the message 'err chmand[8873]: Error sending MCP system_information (err:1020003)’ to the ltm log. This might occur intermittently when shutting down the system. This message is benign, and the system should power up correctly. Workaround:
ID 417526 "When a power cable is reconnected to a power supply, a message will typically show up in the log /var/log/ltm like this: Mar 29 11:09:37 SJPtengs-Treadstone notice chmand[9322]: 012a0016:5: Blade 0 hardware sensor notice: Power Supply 2 GPIO status(SPAFFIV04G): Good But sometimes, the status may switch from Good to Bad, then back to Good within seconds: Mar 29 11:09:37 SJPtengs-Treadstone notice chmand[9322]: 012a0016:5: Blade 0 hardware sensor notice: Power Supply 2 GPIO status(SPAFFIV04G): Good Mar 29 11:09:37 SJPtengs-Treadstone crit chmand[9322]: 012a0013:2: Blade 0 hardware sensor critical alarm: Power Supply 2 GPIO status(SPAFFIV04G): Bad Mar 29 11:09:40 SJPtengs-Treadstone notice chmand[9322]: 012a0016:5: Blade 0 hardware sensor notice: Power Supply 2 GPIO status(SPAFFIV04G): Good" This may happen when a power cable is disconnected, then re-connected to an AC power supply. This does not affect the normal operation of the BIG-IP. It simply means it may take a few seconds for the fan in the power supply to go up to speed. Workaround: None.
ID 417548 The FIPS key object contains an encrypted copy of each key such that each record is ~2.5k. An out-of-memory exception can occur if thousands of FIPS keys are configured. An issue occurs if there are thousands of FIPS keys configured. It is possible to cause an out-of-memory error in the GUI. This presents a blank page in the GUI. Workaround: A simple workaround is to use TMSH to list FIPS keys. Or run tmsh modify sys db provision.tomcat.extramb value 64. This increases memory provisioned for the GUI database query
ID 417720 "If a power supply fan unit becomes jammed or experiences a failure that prohibits the minimum RPM threshold to be met, the LTM log will erroneously indicate that the power supply has been turned off. For example: localhost crit chmand[8482]: 012a0013:2: Blade 0 hardware sensor critical alarm: Power Supply 2 GPIO status(73-610-125): Bad localhost crit chmand[8482]: 012a0013:2: Blade 0 hardware sensor critical alarm: Power supply #2 fan-1: Bad localhost warning chmand[8482]: 012a0018:4: Chassis power module 2 turned off." Any kind of power supply fan failure that prevents the unit from achieving the minimum spec. for RPMs. Misleading log message. Workaround:
ID 417899 If you run the command 'service network restart' to stop and start all the network interfaces, the connection to LOP is lost, and the log shows 'Lopd status: 2' in the log messages to indicate the LOP has no response. This occurs when you run the command 'service network restart'. TMOS is not able to communicate with LOP firmware, which reports data about sensor and backplane interface status. Workaround: Recreate the special VLAN that connects to LOP by running the command 'service lopd restart' to restart lopd.
ID 418509 It is not possible to match a literal ( in the stream filter "Stream filter enabled Stream expression includes a ( not intended as the opening of a regex group" Unable to directly match expression that contain a literal ( Workaround:
ID 418709 The LCD module might report the error 'Low fan speed'. However, it does not specify which fan component on the unit is low: the CPU fan, the chassis fan, or a specific PSU fan. This occurs on the 2000 series, 4000 series, 5000 series, 7000 series, and 10000 series platforms. There is an indication that a component is failing, but no indicator of which specific component is failing. Workaround: Use the console to determine which fan is low either by viewing console messages/warnings as they show up or by running 'tmsh show sys hardware' or viewing the /var/log/ltm file.
ID 418890 When trying to upgrade from version 10.x to version 11.x, SSL keys can fail to roll forward. The roll-forward process does not handle what appears to be an OpenSSL bug (tested through OpenSSL 1.0.1c). This occurs when rolling forward RSA keys from version 10.x to 11.x. Rather than receiving the expected decrypt failure unable to load Private Key with a bad decrypt, approximately 0.3% respond differently, where the return is non-zero and does not contain 'bad decrypt'. In this case, the system considers the key bad even though it is fine. Workaround: There is no workaround.
ID 418924 Secondary blades in a cluster go into swap when there are too many iso images in /shared/images. Too many iso images in /shared/images. Secondary blades are slow. Workaround: Use tmsh or the GUI to delete as many iso images from /shared/images as feasible.
ID 418967 If two iRules in HTTP_RESPOND events are present with different priorities, and the iRule to run first executes "HTTP::retry", the second iRule will cause an error to be generated. Workaround: Perform iRules with HTTP::retry with higher priority.
ID 419345 Changing Master Key on the standby of an HA configuration on a chassis might cause secondaries to restart processes. This occurs when you modify the master key on standby chassis. Users might not be able to access the cluster. The secondary blades of that chassis might experience continuous restarts of mcpd and other daemons, accompanied by 'decrypt failure' messages in the ltm log. Workaround: Run the command bigstart restart on secondaries to return system functionality. In general, you should change master keys on the primary in the cluster.
ID 419621 After a blade failover, an existing inbound session may not have the delete event logged when it completes. "lsn-pool with NAPT Inbound session logging enabled HA configuration After failover" The add event for the inbound session may not have a matching delete event. Workaround:
ID 419623 If a command that needs to suspend processing (for example, table, session, after, sideband, and persist) is evaluated within the content of an expr block, tmm cores. This occurs when using the table, session, after, sideband and persist commands inside an expr block within an iRule. Tmm cores. Workaround: Assign result of command to a variable outside the block and operate on that value.
ID 419733 BIG-IP systems configured with additional non-default management routes via static, OSPF or other protocols might post error messages. The problem occurs when multiple management interfaces are defined. The system might post route_mgmt_entry count errors during the operation of the /usr/bin/config script. Workaround: You can use an alternative method exist to configure the mgmt address and default route: GUI, iControl, tmsh, and configuration file load.
ID 419741 TMM can crash and dump core. Core analysis is typically necessary to determine whether this bug is the cause. Triggering this bug is difficult and seems to require vip-targeting-vip (e.g., use of the 'virtual' command in an iRule) and more than one blade. In rare situations, the TMM crashes. Workaround: None. This occurs rarely, and the system recovers automatically. Although this workaround has not be verified, in situations where virtual A targets virtual B via the 'virtual' command, it should be sufficient for virtual A to have shorter timeouts than virtual B.
ID 420053 Although the IPFIX Logging Destination accepts transport protocol profile configuration, it does not use parameters from the profile. An IPFIX Logging destination can be configured with non-default protocol profiles, such as a custom TCP profile with specific values for Idle Timeout or Keep Alive interval, but the selections are not used. This occurs when customizing parameters within the configured protocol profile. Parameters specified within the configured protocol profile are not utilized, and default values are used instead. Workaround: None.
ID 420184 A transaction fails when you create a new folder and then create an object in that new folder in a batched set of command-line commands. This occurs when a folder does not yet exist, and you try to create the folder and the object in a batched set of command-line commands. The transaction fails with an error similar to the following: 01070734:3: Configuration error: Invalid mcpd context, folder not found (/AAA). Workaround: To work around this, create a folder before using batch commands to create objects in a folder.
ID 420213 The system posts an error message during trust initiation when the peer is unreachable. This occurs when configuring device trust. The system posts an error message: 'java.io.IOException: Could not read response from server: ParseError at [row,col]:[1,236] Message: The processing instruction target matching '[xX][mM][lL]' is not allowed.' Workaround: This indicates that the device that you are attempting to add is not accessible from the current device (that is, there is no route). Here is a more accurate message: 'Unable to retrieve device certificate. SSL handshake failed: java.net.NoRouteToHostException: No route to host'
ID 420341 Connection Rate Limit Mode is set to Per Virtual Server and Source Address, you might encounter unexpected results. Once a particular client is above the limit, other clients (other source IP addresses) are also throttled by the system. This occurs in the following manner: There is a configured connection rate limit per virtual server per client; one client exceeds the configured rate limit; and the virtual server also throttles other, unrelated clients. The virtual server throttles clients that are not exceeding the connection rate limit. Workaround: None.
ID 420344 When BFD is configured between the HA pair neighbor and the HA pair units, BFD fails to establish a session because the IS-IS routing module uses floating self IP address for establishing adjacency rather than non-floating self IP address. BFD is used with IS-IS in HA pair configuration. BFD cannot be used with IS-IS in HA pair configuration. Workaround: None.
ID 420689 A single configuration file (SCF) as generated by the command save sys config file 'name', does not contain information describing what configuration objects have synchronized between the device and other devices. This occurs with an SCF generated using the command: save sys config file 'name', Loading the SCF can cause the system to lose track of this information. Workaround: From one device, run the following command: modify cm device-group <device group name> devices modify { <device name> { set-sync-leader } }'.
ID 421092 The maximum number of named variables in an iRule is 4,194,304. This occurs when using iRules. System drops core file and posts message: Assertion 'maximum pages' failed. No more than 4,194,304 named variables can exist in an iRule. Although the maximum pages limitation has always existed, beginning with 11.3.0, the assert occurs very early when this is detected. Workaround:
ID 421311 'user_disabled unchecked' node becomes 'user_enabled' on config load. During config load, the values are reset to the defaults. configure node to user-disabled; load configuration. Traffic is passed to a user-disabled node. Workaround: "'guishell -c ""select * from node_address""' will force all nodes to recompute the status. 'guishell -c ""select * from pool_member""' will force all pool_members to recompute the status."
ID 421670 TMM will sometimes crash when using plugins Intermittently, under the right conditions, the TMM will crash when plugins are in use. Traffic processing will be interrupted while TMM restarts Workaround: Do not use plugins. This is likely not practical.
ID 421702 The BIG-IP system publishes the mgmt MAC addresses using offsets of the chassis base MAC address, instead of the MAC addresses from the kernel (as ifconfig and dmesg report). This occurs on BIG-IP systems MAC addresses. MAC address is inconsistent between ifconfig and 'tmsh show sys mac'. Workaround: None.
ID 421851 When iRules are saved into bigip.conf, the first line is automatically indented with four whitespaces. Usually these whitespaces are removed when the config is loaded, but when an iRule starts with commented lines, the whitespace is not removed. Every subsequent save/load operation adds another four whitespaces. When users adds checksum to the iRule, loading fails at checksum verification error This occurs when both conditions are true: 1. Line 1 begins with a # character and white spaces. 2. The checksum operation is performed on the iRule. Load failure. Workaround: Remove the whitespace at the beginning of the iRule
ID 421971 Renewing an existing certificate fails in UI if a user provides Subject Alternative Name (SAN) as input. Provide SAN while renewing certificate. Cannot renew certificate. Workaround: Do not provide SAN information while renewing certificates.
ID 422087 "As a result of this issue, you may encounter the following symptoms: - The TMM process crashes with a SIGABRT - The BIG-IP system fails over to the peer system in a high-availability configuration. - The BIG-IP system generates a TMM core file in the /var/core directory." "- Associating a Web Acceleration profile with a virtual server - TMM has become deficient in memory." The BIG-IP system may temporarily fail to process traffic, and may fail over if configured as part of a high-availability system. Workaround: There is no workaround for this issue.
ID 422259 "An IPFIX logging destination is configured with a pool of nodes to identify the collectors to which IPFIX messages should be sent. The health of the nodes and the overall pool can be monitored by the BIG-IP using a health monitor (only the default ""gateway_icmp"" monitor is supported for EA). However, if network or other issues cause the ICMP monitors to mark a node as Offline, the BIG-IP will continue to try to establish connections and send data to that node, instead of deferring such attempts until the node is declared Online again by the health monitor." Network or other issues that cause ICMP requests to a pool member to fail. Minimal, other than extra processing load that could be avoided. Under normal circumstances, if ICMP traffic to a pool member is not successful, the BIG IP will not be able to establish a connection to that member; IPFIX messages will be transmitted to other available nodes in the pool. Workaround: None
ID 422292 "When a BIG-IP IPFIX logging destination uses the TCP protocol, and one or more of its destination collectors becomes unavailable, the BIG-IP system repeatedly tries to re-establish a connection to that collector. RFC 5101 requires that the exporting IPFIX process must not attempt to reestablish a connection more than once per minute. In the EA release, the IPFIX logging destination will attempt connection re-establishment more frequently than the spec requires (up to once every 1/10 seconds)." Configured IPFIX collector becomes unavailable, and the IPFIX logging destination is configured to use the TCP protocol. Frequent unsuccessful TCP connection setup attempts by the BIG-IP system. Workaround: "You can configure a TCP half-open health monitor to cause a collector failure to be detected quickly. The BIG-IP system may attempt unsuccessfully to re-establish a TCP connection for a few seconds, but once the monitor has deemed the node to be unavailable, the attempts cease. This does not make the BIG-IP system strictly compliant with the RFC text, but it mitigates the situation by not attempting to reconnect at frequent intervals for excessive durations."
ID 422315 When trying to remove certain interfaces from list, the user can encounter an error in the UI. For example, if more than two interfaces exist in the Interface list on a trunk object, you receive an error if you attempt to remove one of the interfaces that appear between the first and last interfaces listed. More than two interfaces exist in Interface list on trunk object. Customer tries to remove a 'middle' interface and Update. Customers cannot remove all interfaces from Trunk using UI. Workaround: Use tmsh.
ID 422460 TMM restarts without any core file on startup or when mcpd is loading the configuration if the size of configuration is considered big (for example over 1000 passive monitors). This issue occurs when all of the following conditions are met: -- The mcpd process loads a large configuration with thousands of objects. -- The platform is running 12 or more TMM instances (BIG-IP 11000, 11050 platform, or VIPRION B4300 blade). Traffic processed by the affected TMM instance is interrupted while TMM restarts. TMM might enter a restart loop and restart multiple times, without producing a core file. You might see errors similar to the following in log/tmm or log/daemon: -- LTM01 notice mcp error: 0x1020003 at ../mcp/db_net.c:575. -- LTM01 crit tmm11[28599]: 01010020:2: MCP Connection aborted, exiting. -- LTM01 emerg logger: Re-starting tmm. This might cause serious traffic disruption. Workaround: To work around this issue, you can increase the time-out used for the MCP connection by adding a zero_window_timeout 300000 setting to the profile tcp _mcptcp stanza in the tmm_base.tcl file. This lengthens the timeout and hence avoids the restart. For more information, see SOL14498: The mcpd connection to TMM may time out on either startup or configuration load and cause TMM to restart, available here: http://support.f5.com/kb/en-us/solutions/public/14000/400/sol14498.html.
ID 422709 Intermittently, if a secondary blade is being disabled, it may miss the command and stay enabled. Unknown. Secondary blade will still pass traffic as if it is active. It will not be considered inactive for counting of min-up-members. Workaround: As this only happens rarely, you can re-enable the blade and re-disable the blade.
ID 423304 Objects may display extra parameters that don't belong to the object. "When deleting a monitor or profile object and recreating it as a different type with the same name, after syncing parameters from former object get appended to the new object. e.g.: delete ltm monitor https monitor1 create ltm monitor http monitor1 <...> 'monitor1' now changed to http type will have parameters from the original https monitor." Bad configuration on the box that is synced to, and no obvious warning signs. Workaround: "Do the changes and sync incrementally. e.g.: delete ltm monitor https monitor1 <sync> create ltm monitor http monitor1 <...> <sync>"
ID 423392 In previous versions of iRules, the variable tcl_platform was readable as: 'set myvar static::tcl_platform'. However with recent changes, the variable is in the global, not static namespace and should be accessed as '::tcl_platform'. This occurs on pre-11.4.0 iRules that use the variable 'static::tcl_platform'. iRules that worked properly under earlier versions can result in runtime Tcl exceptions (disrupting traffic) after an upgrade to v11.4.0 or later, if those iRules reference static::tcl_platform. Workaround: To map tcl_platform into the static namespace in an iRule, use the following: when RULE_INIT { upvar #0 tcl_platform static::tcl_platform }. Or you can use ::tcl_platform instead of static::tcl_platform. Note: The latter workaround might demote a virtual server from CMP. For more information, see SOL14544: The tcl_platform iRules variable is not in the static:: namespace, available here: http://support.f5.com/kb/en-us/solutions/public/14000/500/sol14544.html.
ID 424228 If a virtual server is created without an assigned pool (i.e. the pool is assigned in the iRule) and the iRule parks, the iRule may not return from suspension and the packet will be dropped. A virtual server is created and an iRule is assigned that parks, and the virtual server has no assigned default pool. Packets are dropped. Workaround: Either use the CLIENT_ACCEPTED event for UDP data or assign a default pool.
ID 424568 When a certificate contains multiple/nested OUs, the X509 data returned through iControl has only the first OU. This occurs when using iControl. X509 data returned through iControl does not return multiple/nested OUs. Workaround:
ID 424649 Blades will continually fail over with a large enough translation address space in an lsn-pool in DNAT mode. An example of a translation prefix large enough to cause this problem would be /8, or several translation prefixes summing to a large number of translation addresses. an lsn-pool in deterministic mode, assigned to a virtual, with a /8 prefix (or similar number of addresses.) System is rendered unusable until DNAT mode is disabled. Workaround: Change to NAPT mode, or use a smaller translation prefix range. There is no other workaround.
ID 425017 For Thales HSM clients, the tmm and pkcs11d daemons must be restarted for changes to take effect to the key protect mechanism. This occurs for Thales HSM clients when support is added for module keys and token keys, or for softcard features, or when these are enabled or disabled. Changes do not take effect. Workaround: None. The tmm and pkcs11d daemons must be restarted for the changes to take effect.
ID 425018 Loading a SCF after modifying self IP may cause route in Linux kernel to be dropped. Linux host applications may not be able to connect when they are expected to. Create a config with a self IP on a VLAN and a default gateway route on that VLAN, save a SCF file, then modify the self IP in that SCF file and then load the SCF. Linux kernel default gateway route is dropped and host applications looking for the route may not be able to connect. Workaround: Reset the config to default before loading modified SCF: 1. tmsh load sys default. 2. tmsh load sys scf <SCF_filename>. For more information, see SOL14572: Routes configured in a single configuration file may be missing from the Linux kernel route table after loading the single configuration file, available here: http://support.f5.com/kb/en-us/solutions/public/14000/500/sol14572.
ID 425347 vCMP guests report 'unknown' as platform type. This occurs on vCMP guests. Customer is unable to remotely determine exactly which platform is being monitored. Workaround: None.
ID 425817 The boot_marker entries found in system logs might not accurately reflect the version of the software in the active slot. This occurs when slots name share a common prefix, such as 'HD1.test' and 'HD1.testing' and you run the command tmsh show sys software. The result might show the incorrect version number. Workaround: None.
ID 425826 "Unit in HA configuration constantly cored until the system was rebooted. An intermittent error appears: notice panic: ../kern/xbuf.c:2273: Assertion 'valid xfrag' failed" It is unclear whether this is an high-speed bridge (HSB) issue or a driver issue. The return buffer is provided by the driver and used by HSB to return the packets. Either the provided buffer is corrupt or HSB somehow corrupts it. This issue is rare and has been seen across several platforms and HSB bitfiles. Rare issue that results in kernel panic. You might see invalid return buffer and invalid xfrag messages. Workaround: This is typically cleared on reboot. The issue might also be cleared with a bitfile upgrade.
ID 425992 If the BIG-IP mgmt interface is connected to a switch port with fixed settings (e.g., 100Mbps Full duplex) but with auto-negotiation Disabled, the BIG-IP mgmt interface will be set to 100Mbps HALF duplex instead. "1. The remote switch port is configured with fixed media settings (speed, duplex) and auto-negotiation disabled. 2. The Management interface on the BIG-IP system is configured with fixed media settings (speed, duplex)." Inability to access BIG-IP via mgmt interface. Workaround: "1. Enable auto-negotiation on remote switch (with only the desired option advertised). 2. Toggle the mgmt interface media setting between 'auto' and '100TX-FD' after the BIG-IP boots."
ID 426128 If the passphrase for the pkcs12 file being installed is greater than 49 characters in length, installation could fail with the error - "Key management library returned bad status: -28, Bad password". This occurs with pkcs12 files with passphrases greater than 49 characters. When this occurs, installation could fail with the error - "Key management library returned bad status: -28, Bad password". Workaround: Use passphrases containing fewer than 50 characters for pkcs12 files.
ID 426129 CGNAT translation logs sent to ArcSight HSL destinations will not be in a compatible format for ArcSight to parse. "LSN pools are configured for a virtual server A log profile is configured to use an ArcSight destination and attached to the LSN pool" CGNAT log messages will not be processed correctly by ArcSight Workaround: "Modify ArcSight for custom parsing Use a different log server."
ID 427260 Type tmsh show sys pptp and it shows the identical flow with different stats incremented CGNAT and PPTP-ALG with default DAG Cosmetic but may be confusing Workaround: Grep and aggregate the stats for a unified view
ID 427580 When a PSU is absent from the system, LCD warning does not display module number. When the condition is detected, the ltm contains a log with all the information about which module is reporting the alert. PSU is absent. None. Workaround: Use the ltm logs for troubleshooting.
ID 427924 When inserting a new blade in a VIPRION C2400 chassis, with UDP or TCP hash set to 'ipport', the new blade uses the 'port' hash instead. Rebooting the blade or restarting bcm56xxd and tmm causes the correct DAG (Disaggregator) hash to be used. UDP or TCP hash algorithm changed from default (e.g. changed from 'port' to 'ipport'). -- UDP or TCP virtual servers configured. -- New blade inserted into chassis. New blade includes external interface to which traffic will arrive. Prevents adequate distribution of traffic within a chassis, which may disrupt traffic flows or reduce the traffic throughput of the BIG-IP system. Workaround: Reboot the new blade after it has been configured. Issue the 'bigstart restart' command (to restart the bcm56xxd and tmm modules and program the DAG with the correct hash type).
ID 428752 Occasionally, on shutdown/reboot of a platform, diskmonitor may be started while the system is shutting down. This occurs when the system is shutting down, halting or rebooting. After a shutdown, halt, or reboot is initiated, the system console may display this message: 011d0002: Can not access the database because mcpd is not running. The ltm log file shows the same database warning along with a date and system entry: Aug 23 14:31:02 BIG-IP.web1 warning diskmonitor: 011d0002: Can not access the database because mcpd is not running. Workaround: The warning is innocuous on shutdown and may be ignored. The diskmonitor script automatically runs when the system is booted next and detects disk space issues at that time.
ID 428976 If a self IP is configured for advertisement in OSPF and is moved to a different VLAN, the LSA may be removed from the database and not readded. OSPF enabled, self IP moved between VLANs. Missing prefix from OSPF. Workaround: Remove and readd connected route redistribution, delete and readd the self IP, or clear the OSPF process ("clear ip ospf process" in imish).
ID 429013 Log file permissions for one specific log file were incorrectly set. This has been fixed to address an issue with CCE-26812-8, CCE-26821-9 and CCE-27190-8 syslog-ng configuration/permissions. Since only Administrators can have advanced shell access, they are on the only ones who could be able to see the log files. This just sets the file permissions the same as the rest. Very little impact. Workaround: none
ID 429096 Various tools, including the Dashboard, display an SSL TPS limit provided in the base license, ignoring any additional licensing modules that might increase the TPS limit. This occurs when the system is using licensing modules that increase base SSL TPS. An incorrect SSL TPS limit is reported. Workaround: None. This a display issue only. The correct SSL TPS limit is actually used.
ID 429213 "A race condition may occur in which a monitor instance be killed abruptly if another copy of the same monitor attempts to check health of the same node IP:port in a different route domain. The killed monitor will then contribute to a monitoring timeout and potentially mark the node as down. This issue occurs because the PID file created to prevent duplicate monitoring of the same pool member is not sufficiently unique to distinguish between route domains. For example, SIP monitor named ""sip_london"" applied to pool members 1.2.3.4%100 and 1.2.3.4%200 would share the same PID file: /var/run/SIP__Common_sip_london.::ffff:1.2.3.40..5060.pid" "For health monitor types which execute outside of the bigd process (see list below), a health monitor profile is assigned to monitor 2 different nodes which have the same IP:port in different route domains. The affected monitor types include: Diameter IMAP LDAP NNTP POP3 Radius Radius Accounting RPC Scripted SIP SMB SMTP WAP" Pool members may flap down/up. Workaround: "To work around this, perform the following steps: 1. Create a duplicate copy of the monitor profile, and add the route domain to the name of the monitor profile. For example: ltm monitor radius /Common/radius_seattle_rd43 { default-from /Common/radius_seattle } 2. For nodes or pool members in that route domain, replace the old monitor profile with the new duplicate monitor profile."
ID 429613 TACACS+ accounting packets are only sent to the authentication server. This occurs with TACACS+ accounting packets. These packets are only sent to the authentication server. Workaround: You can use syslog to send the messages (but not TACACS+ accounting codes) to multiple destinations simultaneously.
ID 430265 If an iRule runs a periodic after{} command containing a sideband connection that is closed in a different event, a core may occur if the flow is aborted because the periodic after command was not alerted that the flow is gone. Using a periodic after { sideband connection stuff } with the opening and closing of the sideband in different events from the after command core Workaround: Let the completion of the iRule close the sideband connection.
ID 430323 VXLAN daemon may restart when 8000 VXLAN tunnels are configured. 8000 VXLAN tunnels are configured. VXLAN daemon restart. Workaround:
ID 430354 When an alarm light is present on the primary blade and the USB LCD dongle is then attached all of the blades go from green/Pri or green/sec to amber status and alarm light is erased. A few moments later once the LCD screen is up the blades go back to their original green pri/sec assignment but the alarm light never returns. Although the alarm message is present on the LCD after it comes up the alarm light should stay on until the alarm has been cleared. Inserting or removing USB LCD module. The alarm message is present on the LCD after it comes up. Workaround: To work around this, run system_check manually.
ID 430915 When a power supply or fan tray FRU is inserted into a running BIG-IP system, a critical alarm may be raised indicating low power and/or fan speeds. This is due to the amount of time it takes for the power and/or fan speed levels to reach their steady state levels relative to when the sensors are monitoring them. Insertion of power supply or fan tray FRU. Critical alarm raised for temporary, non-serious issue. Workaround:
ID 431283 "Binary command does not check if the offset argument causing moving beyond the internal buffer boundary, this may core tmm. Here is an example: binary scan [TCP::payload] @${offset_num}c var1 if ""offset_num"" is larger than payload buffer length, tmm may core." "Here is an example: binary scan [TCP::payload] @${offset_num}c var1 if ""offset_num"" is larger than payload buffer length, tmm may core." tmm may core. Workaround: Check payload length and compare with the offset argument before using the command.
ID 431411 "Multicast NTP received by BIG-IP systems from an NTP server can interfere with ntpd maintaining client associations with that NTP server. The BIG-IP system may source NTP queries with the multicast address used by the NTP server or IP address 127.3.0.0" Multicast NTP is received on an appliance or virtual edition via management or tmm interfaces, and the BIG-IP system is configured to be a client to that NTP server. The BIG-IP system does not maintain time sync with the NTP server issuing NTP multicast Workaround: "See the comment#19 https://bugzilla.olympus.f5net.com/show_bug.cgi?id=431411#c19"
ID 431480 Occasionally, you might encounter a situation in which tmm dumps a core, and the system writes to the logs a message similar to the following: notice panic: ../base/listener.c:1116: Assertion 'laddr is not NULL' failed. The exact conditions that result in this error are unknown. When it occurs, the system posts a 'laddr is not NULL' message, and tmm dumps a core. Workaround: None, but the system recovers without any user action.
ID 431936 The SASP monitor does not mark pool members down when the GWM server cannot be reached. The GWM server does not send a RST packet to terminate its connection to the SASP monitor in case of a network failure. The pool members are not marked down for a SASP monitor in case of a GWM/network failure. They are marked down when the TCP connection to the GWM terminates on a connection timeout which was observed around 10 minutes. Workaround: Use the icmp monitor in conjunction with the SASP monitor. The icmp monitor should use the GWM server as its destination. This monitor should be associated with each of the nodes that are present in the pool using the SASP monitor. The pool members will be marked down when the GWM server cannot be reached.
ID 432242 Active device incorrectly marks pool members down or cycles status between up and down. This occurs with transparent VLAN groups. This occurs when monitors are configured to monitor through two layer2 devices on two different child VLANs. The issue occurs only with a significant amount of monitor traffic (for example, up to 128 nodes each way every second). The configuration might also require occasional broadcast ARP requests that were not known by the active device. This might result in monitor flapping and possible traffic misdirection on the active device. Workaround: Use translucent vlan-groups instead of transparent.
ID 432407 The GUI becomes inaccessible after the system logs become large and the user navigates to log lists under System :: Logs. This event is most likely to occur when the logging options are configured to show the most output. For example: Enabled, Verbose, Debug. The issue is most easily seen when the system has been configured with Audit logging enabled, particularly MCP, it sends numerous messages to the var/log/audit log. This causes the log to become large, which after time might render the GUI inaccessible. When logs become large, the GUI might become inaccessible if the user attempts to view the log files through the GUI. Workaround: Configure logging options to show only the most severe output: Emergency, Error, etc. (available under the System :: Logs). If the system is already in this unresponsive state, issue the command 'bigstart restart tomcat'.
ID 432790 "Blade point of load power supply faults may be incorrectly captured and logged during chassis power cycle and card pull events. The blade AOM function continuously monitors the blade health for reporting of hardware failures to the system layer. This AOM function is on standby power and is operational whenever chassis power is present. If the chassis or the entire blade powers down through an intentional or unintentional action, power health monitoring is indeterminate and incorrect power fail event status may be captured. The blade point of load +5V, +3.3V, +1.5V, +1.1V, etc power supply status is stored by the AOM in non-volatile memory. The information is saved in memory forever until reported and cleared by the application layer. Thus any transient power fail status captured during a power down is unintentionally logged by the application layer on the next power-up. This issue has been observed only on a few blades with very low frequency of occurrence during rigorous power cycle testing." This condition although very rare and can occur during chassis power cycles. It can also occur during a blade pull while servicing a system in operation. Incorrect power fault status may be reported in the system logs and maintained on the blade until the log files are over-written or deleted. This may cause confusion or concerns when viewing the system log files that a hardware issue exists. If point of load power fail system log messages are observed, you must qualify them with system main power events to discriminate between false positive errors and actual power supply faults. Workaround: Recommend process is to power down the blade prior to turning off chassis power or removing the blade from the chassis. Normal controlled blade power down events are unaffected by the issue.
ID 432998 The mssql monitor marks one pool member down that was considered up by the earlier software version. Other units upgraded from version 10.x that are monitoring this pool member are fine. This occurs after upgrade from version 10.x. The mssql monitor marks one pool member down that was considered up by the earlier software version. Workaround: "There is a Microsoft hotfix for SQL Server 2008 that resolves this issue. After applying SQL Server 2008 R2 SP4 to the server, encrypted communications function correctly. You can read more in the KB article that addresses the issue: 'FIX: You cannot connect to SQL Server by using JDBC Driver for SQL Server after you upgrade to JRE 6 update 29 or a later version' http://support.microsoft.com/kb/2653857. One additional issue: looking at the customer's response, they are running SQL Server 2008 SP3 (NOT R2). I would recommend that the customer either try the post-SP3 rollup package on their 2008 server, or upgrade to 2008 R2 and apply SP4. The KB article above addresses both versions. Note, I have not tested this fix on 2008 (non-R2) because I didn't catch until recently that their server version was different than the one stated earlier."
ID 433223 "On a VIPRION B4300 blade, VIPRION B2250 blade, or BIG-IP 10000-series appliance, messages similar to the following may be logged in the LTM log every 2 seconds: info bcm56xxd[25425]: 012c0016:6: _soc_xgs3_mem_dma: ING_SERVICE_COUNTER_TABLE_Y.ipipe0 failed(NAK) info bcm56xxd[7610]: 012c0016:6: _soc_xgs3_mem_dma: EGR_VINTF_COUNTER_TABLE_Y.epipe0 failed(NAK) info bcm56xxd[11548]: 012c0016:6: _soc_xgs3_mem_dma: EGR_SERVICE_COUNTER_TABLE_X.epipe0 failed(NAK) Similar errors also appear in the bcm56xxd log file." This error is logged if an internal parity error is reported by the Broadcom switch chip when stats are read from the chip by BIG-IP. Since these errors are reported for the interface that is used to retrieve stats from the Broadcom switch chip, they are not expected to impact the packet path/traffic passing. Workaround: To stop logging of these errors and clear the internal parity error from the Broadcom switch chip, perform one of the following actions: 1. Restart the bcm56xxd daemon: bigstart restart bcm56xxd 2. Reboot the affected blade or appliance. For more information, see SOL14865: Some BIG-IP systems may log excessive bcm56xxd messages, available here: http://support.f5.com/kb/en-us/solutions/public/14000/800/sol14865.html.
ID 433323 When a client request contains no-cache directive, ramcache excludes the request from caching and passes the request through. Because caching is disabled, the resource is not invalidated and the response is not cached. The expectation is the action should cause revalidation of the resource. Configure a virtual server with HTTP caching. Failure to invalidate resource. Increased load on origin server. Workaround:
ID 433466 When the bundled interface (e.g., 2.1) is disabled, it might result in link issues observed with the first member of the associated unbundled interfaces (e.g., 1.1). Disabling bundled interfaces affects first member of associated unbundled interfaces. Traffic unable to pass due to ports 'Down' status. Workaround: Do not disable the associated bundled interface (e.g., 2.1) when intending to use the first member of the associated unbundled interfaces (e.g, 1.1). Same for the interface bundle/unbundle relationships for 2.2/1.5, 2.3/1.9, vice-versa, etc.
ID 433572 DTLS does not work with rfcdtls cipher on the B2250 blade This occurs as a result of hardware acceleration offload on the B2250 blade when using dtls on vCMP. DTLS does not work with rfcdtls cipher on the B2250 blade Workaround: no
ID 433897 If a datagroup contains entries that are longer than the maximum length allowed by a Tcl object, the datagroup can fail to load the element without warning. This occurs when an external datagroup loads strings that exceed Tcl-imposed limits. Incorrect datagroup. TMM might core if the non-loaded element is referenced. Workaround: Use individual datagroup entries that are fewer than 65000 characters in length.
ID 434356 When an internal/external data-group configuration is modified, it doesn't reflect in a client SSL profile. Modifying a data group configuration. You have to manually restart tmm or re-apply the data-group to the SSL profile each time the data-group is modified. Workaround: Restart tmm or re-apply the data-group to the SSL profile each time the data-group is modified.
ID 434364 "When upgrading from 10.x or installing a 10.x originated UCS on 11.x, bigpipe is used to parse the newly created file-object definitions which had been generated from files in the 10.x install. If the filename being upgraded to file-object starts with a '.', then on initial load, bigpipe will give an error while trying to load the generated configuration, resulting in an error message similar to: BIGpipe parsing error (/config/bigpipe/bigip.conf Line 107): 012e0017:3: The requested item (.myfile.txt {) is invalid (<external monitor file object key> | show | list | help) for 'external monitor file object'" The installation of a UCS or configuration roll-forward from 10.x to 11.x in which the previous install had files that were upgraded to file-objects, but whose filename started with a '.' The UCS will not install properly, and/or the configuration on initial boot will not load. Workaround: Edit the name of the file-object in question which would be found in /config/bigpipe/bigip.conf to remove the leading '.' character from the object name, and make any references to the file-object match that change.
ID 434468 "For 11.5 htsplit mode is enabled by default. htsplit is actuals only for platform/blades which have CPU with hyper-threading. htsplit mode decrease number of tmms in twice. So after upgrade from 11.4 to 11.5, customer may see that DOS attacks happens on normal traffic rates. Example: Customer have Treadstone with 11.4 with 12 tmm, so he configured DOS accordingly. Then he make upgrade to 11.5 and get Treadstone with 6 tmm because of htsplit mode." Platform/blade CPU have hyper-threading and sys db scheduler.splitplanes.ltm = "true" Customer may see false-alarm DOS attack on normal traffic rates. Workaround: Increase thresholds for AFM DOS vectors in twice.
ID 434517 If a HTTP_RESPONSE event fires due to the server sending an early response (i.e. a response before the entire request has been sent), then HTTP::retry does not work correctly. Client begins sending a request. The server responds before that request is completely sent. A HTTP::retry is called in the HTTP_RESPONSE event. Typically, early server responses are error conditions. Workaround: HTTP::respond or HTTP::redirect may be used at the cost of an extra client-side request.
ID 434573 "While running a version of BIG-IP older than the most recent release on a new hardware platform (recently purchased or recently acquired through RMA exchange), the 'tmsh show sys hardware' command may display the Platform ID code in place of the official F5 platform name. For example, the 'tmsh show sys hardware' command may display a Platform ID like the following: Platform Name D113 instead of the official platform marketing name, such as: Platform Name BIG-IP 10000F" This may occur if the version of BIG-IP software installed is not the most recent release, and the hardware platform is a newer variant (due to added hardware features or other manufacturing change) than was originally supported by the older BIG-IP software release. Custom automation scripts which depend on correctly matching F5 platform marketing names may fail to match the platform ID. Workaround: Update platform-identification scripts to include the relevant platform IDs among the recognized match values.
ID 435022 TMM might crash if an ICMP packet refers to a closed UDP connection. "- A virtual server with UDP profile. This is more likely to occur if the UDP profile 'Datagram LB' option is enabled and/or if the UDP profile timeout is 0 or 'immediate'. - An ICMP packet (such as destination-unreachable) arrives matching the IP and p" Unexpected crash and failover. This is a rarely encountered issue. Workaround: If the UDP profile timeout is set to 0 or 'immediate', consider increasing this value.
ID 435332 If there are users defined on a version 10.2.1 BIG-IP system to have administrator or resource-admin roles, and they have partition access to a single partition, these user config objects fail to load during an upgrade to version 11.x. "Here is a sample user config from 10.2.1: user v-abban { password crypt '$1$UIPmGYdY$yewCx.a2qNDauz/UB1Jbp/' description 'v-abban' group 500 home '/home/v-abban' shell '/bin/false' role administrator in Common }" Upgrade or load UCS fails with the following error: 01070821:3: User Restriction Error: The administrator, resource administrator, auditor and web application security administrator roles may not be restricted to a single partition. Workaround: Prior to upgrade, edit the bigip_sys.conf to have the role line as follows: ... role administrator in [All] }
ID 435385 Unable to access the GUI. This occurs with frequent add/delete of vCMP guests. The speed at which the add/delete operations might also be relevant. TMUI becomes unresponsive. Workaround: To work around this, try add/delete at a slower page. To recover, run the command: bigstart restart.
ID 435494 DTLS handshake may fail when UDP messages are round robin among TMMs. "DTLS configuration. Round Robin DAG enabled for DTLS UDP packets." DTLS handshake could fail Workaround: Disable Round Robin DAG for DTLS packets.
ID 435646 lsn-pool inbound setting does not work when not associated with a virtual server. "lsn-pool with inbound or hairpinning enabled That lsn-pool is not associated with a virtual server but is assigned by an iRule." inbound and hairpinning is not enabled for subscribers using that lsn-pool when assigned via an iRule. Workaround: Create a virtual server for each lsn-pool.
ID 435670 If the DB variable Persist.WellKnownProxyClass names a deleted but loaded config item in Value List Object, the system posts an error. This occurs when the configuration item was removed from the running config, but exists inside a saved config. The configuration file does not load, and the system posts an error similar to the following: Error 0x1020036 occurred: 01020036:3: The requested value_list (/Common/test_group) was not found. Workaround: None.
ID 435814 CGNAT connections for a single client might exceed connection limits. This occurs when the persistence-timeout value is fewer than 30 seconds on lsn-pools with connection limits Connection limits are not enforced. Workaround: Set persistence timeout to a value greater than 30 seconds.
ID 435946 "TMSH incorrectly allows a user to configure two mutually exclusive failover methods, namely auto failback and HA group, concurrently without warning. In this case, the HA group method will be used." Using TMSH to configure failover and selecting these two methods. HA group method takes the place of auto failback, which may be unexpected if the user does not know about this issue. Workaround: Use the web interface instead on version 11.5.0 and later. It prevents invalid selections.
ID 436813 Messages for sync statuses differ when there is a sync config in memory that is newer than the one in the binary database, and the system is restarted. This occurs when set-sync-leader and then issue a bigstart restart before saving the config. On one system, the message posted is 'Not All Devices Synced', and on another, 'Changes Pending'. This issue is cosmetic only. The actual sync statuses will be correct. Workaround: Save the configuration on a device before rebooting it.
ID 436825 Under certain conditions, nodes (or any other object with an IP address) in a partition that belong to route domain 0 will be treated as part of the default route domain for the partition after an upgrade. "All of these conditions must be true: - A system is being upgraded from any TMOS v10.x release to any TMOS v11.x release after 11.1. Upgrading to 11.0 or 11.1 is not affected, but the upgrade process resets the partition's default-route-domain setting to 0. - It has a partition that has its default route domain set to a nonzero route domain - That partition contains nodes with no route domain set (so the default is used) - That partition contains other nodes in route domain 0" Those objects may no longer be addressable or able to connect. Workaround: "Set the partition's default route domain ID to 0 before upgrading, then set it back to its previous value after the upgrade. This field is only used by the GUI and shell, so temporarily changing it to 0 will have no effect on the dataplane."
ID 437226 The SERVER_CLOSED execution counter is incremented by 2 for every 1 run when the flow is parked in CLIENT_CLOSE. This occurs in the stats for SERVER_CLOSED when the flow is parked in CLIENT_CLOSE. The stats for SERVER_CLOSED become inaccurate due to parking. Workaround: None. This is a cosmetic issue. TMM does not core.
ID 437586 When running lspci -vv (or -vvv) on blades containing certain chipsets, the operation might encounter a Virtual Product Data (VPD) read failure, and the operation times out with the following message from dmesg output: linux-kernel-bde 0000:12:00.0: vpd r/w failed. This occurs when lspci -vv or -vvv is run on systems with specific chipsets. The system posts the following messages in dmesg: 'linux-kernel-bde 0000:09:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update.' There is no issue, other than time it takes for the pci subsystem to time out when it tries to read the VPD from the chipset. Workaround: None, but this is an cosmetic issue in the firmware on the device, and does not indicate a problem with the blade. You can ignore this output from dmesg and in kern.log.
ID 437768 Do not use 'bigip1' as a device name. The BIG-IP system uses it as the factory default device name. This occurs when using 'bigip1' as the device name. You might see an error similar to the following: 01070710:3: Can't save/checkpoint DB object, class:devicegroup_device status:13 - EdbCfgObj.cpp, line 127. Unexpected Error: Loading configuration process failed. Workaround: Treat 'bigip1' as a reserved word, and do not use it for device names.
ID 437905 Both ltm and/or tmm logs may show buffer overflow reports. If the report manifests exclusively in the ltm log, then Cave Creek has dealt with the error internally. But if the error manifests both in the ltm and tmm log (same timestamp), then the client will get a tcp reset and an incomplete transfer. Thus far investigation has only shown this behavior with png files, but the sample is very limited. Clients will get a tcp reset and an incomplete file. Workaround: "One customer added a filter to remove png files. Meanwhile we have a *temporary* workaround: a db-variable was added. The error report in /var/log/ltm has been updated to include the variable name and current setting: Device error: (null) Cave Creek compression error, buffer overflow. Consider increasing quickassist.compression.buffsize_multiplier (currently 150) For customers who experience the -11 issue, the db-variable should be set to ""300"", and that will keep Cave Creek from running out of compression workspace."
ID 438048 You might encounter a tmm core when the iRule on the client side sends a TCP:notify request. This occurs when an iRule runs a TCP::notify on the client side, and the server side (peer conflow) of this client side does not exist/is NULL. tmm cores. Workaround: None.
ID 438674 The log filter functionality in TMOS allows users to publish logs from a specific set of processes to various log destinations. Configure log filter that includes tamd. Client authentication might fail. When a log filter includes tamd, the tamd process might start to leak descriptors. Workaround: Do not define log filters that include tamd (tamd is included in 'all').
ID 438177 RSA key/cert pair must be configured as a default in clientssl profile even for only DSA/ECDSA ciphers. If ciphers only contain DSA/ECDSA ciphers. The connection cannot be built up if no RSA key/cert is configured on clientssl profile. Workaround: The clientssl profile must have RSA key/cert configured.
ID 438324 Virtual servers configured with Fast HTTP profiles can fail if TCP uses ipport hash on B2150/B2100 blades. The B2150/B2100 DAG (Disaggregator) hash cannot use both IP address and TCP port in selecting tmm in ipport mode. This occurs when TCP is configured to use ipport hash on B2150/B2100 blades and the virtual servers use Fast HTTP profiles. TCP-based virtual servers configured with the Fast HTTP profile can fail. Workaround: To work around this, you can either use port hash or use profiles other than Fast HTTP for TCP-based virtual servers.
ID 438666 iControl/REST relies on automatic parsing of tmsh output in order to reply to requests. The structure of 'show sys raid array' does not conform to the standard and, thus, the array-members are dropped and not returned in the output. This happens for any 'stats' query on a BIG-IP that has RAID. Clients will not be able to get array-members via iControl/REST. Workaround: Use tmsh or other UI (iControl/SOAP).
ID 439507 Running the qkview utility might take a very long time, up to 30 minutes, possibly longer if there are thousands of tunnels or virtual IPs created. This occurs when there are 500 virtual network interfaces or more in a configuration. qkviews are slow to generate. Workaround: Wait for qkview to finish, which might take up to 30 minutes.
ID 439628 Updating the Dynamic Ratio of a node or pool member using TMSH or iControl, instead of a built-in dynamic ratio monitor such as SNMP, results in a 'configuration sync needed' status, or an automatic sync if auto sync is enabled. This occurs when the following conditions are met. - Multiple devices in a device group. - Updating dynamic ratio via TMSH or iControl. - For automatic sync, auto sync is enabled on the sync-failover group. The sync status might unexpectedly transition to 'Changes Pending'. If automatic sync is enabled, the device group performs a ConfigSync immediately. If automatic sync is enabled, and the dynamic ratio is updated frequently (such as by an External monitor or an iControl script), the following additional impacts may occur: - An administrator's pending changes to the configuration may unexpectedly roll back on a receiving device. - A sync conflict may potentially occur. Workaround: "The following 'guishell' command syntax can be used to update the dynamic ratio as an alternative to using TMSH: guishell -c ""update pool_member set dynamic_ratio=<number> where pool_name='/<path>/<pool_name>' and node_name='/<path>/<node_name>' and port='<port#>'"" The node name is the full folder path to the object name, which might be the node address with the pool folder prepended. In external monitor scripts, the node name is available in the NODE_NAME environment variable. Example: guishell -c ""update pool_member set dynamic_ratio=123 where pool_name='/Common/SMTP_Servers' and node_name='/Common/10.50.5.251' and port='25'"""
ID 440199 Using the LCD buttons to change the console baud rate to anything other than 9600 or 19200 may cause the rate to default to 19200. This occurs when using the LCD to change the baud rate. Console input/output may not be usable after the changes. Workaround: Use tmsh to change the console baud rate for rates higher than 19200 baud.
ID 440215 When setting the Ethernet ports on BIG-IP 5000 and 7000 series platforms to half duplex and then pinging, the Activity LED blinks Green instead of Amber. This occurs because half-duplex operation is not supported at any speeds. This occurs when setting half-duplex on Ethernet ports on BIG-IP 5000 and 7000 series platforms. Operating in half-duplex may hang a port. Workaround: There is no workaround. User must operate in full-duplex modes. This is as designed.
ID 440365 At upgrade or UCS installation time, one or more files which share the same name may not be copied to a staging location, eventually leading to an error message at configuration load time, of the form, "File object by name (<file>) is missing." In a 10.x system it's possible that files of different types (e.g. certificates, keys, external monitors, etc.) which are to be upgraded to file-objects in an 11.x system may have identical filenames though they reside in different directories on the BIG-IP system. For instance, a certificate located in /config/ssl/ssl.crt/example and a key in /config/ssl/ssl.key/example, on a 10.x system which is to be upgraded could cause this condition. Error at first boot of a newly upgraded partition, or UCS load time. Workaround: Modify the duplicately named files and any references to them in the configuration before upgrade.
ID 440431 The hud_http_method_respond() does not work with response logging, so logging is blank when invoked. This occurs when using hud_http_method_respond() with response logging. The status logged is blank if hud_http_method_respond() was invoked. Workaround: If an iRule is calling HTTP::respond or HTTP::redirect, you can log directly from that iRule, and record parts of the old response, or the new one, depending on what is required.
ID 440959 "Symptoms: - within the threshold of configured timeout and retry, in the event of an ICMP unreachable, the monitor marks the weight to the default (1)." Configure a pool_member with SNMP_DCA monitor. Delay the SNMP server's response. Delayed SNMP responses are rejected by the monitor. Workaround: "The only workaround is to write an external monitor script, using the snmpget utility. For example: ------------ # values provided by bigd node_ip=`echo $1 | sed 's/::ffff://'` # example: use snmp get command=$(snmpget -v 2c -c private '$node_ip' -r 3 -t 5 .1.3.6.1.4.1.2021.4.5.0 .1.3.6.1.4.1.2021.4.6.0 .1.3.6.1.4.1.2021.11.50.0 .1.3.6.1.4.1.2021.11.51.0 .1.3.6.1.4.1.2021.11.52.0 .1.3.6.1.4.1.2021.11.53.0 .1.3.6.1.4.1.2021.9.1.2 .1.3.6.1.4.1.2021.9.1.9) To configure an external monitor: --------------------------------- tmsh create sys file external-monitor my_snmp_exec source-path file:/config/monitors/my_snmp2.sh tmsh create ltm monitor external my_snmp run my_snmp_exec tmsh create ltm node nodeA address 1.1.1.1 monitor my_snmp"
ID 441013 "When you change root password in single user mode, the system posts following error: error: unable to obtain slot from Lights Out Processor (LOP) : send to lopd failed [lopd addr:/var/run/lopdsvr] [client. The root password change succeeds, but root password sync to LOP fails, because LOP is not running in single user mode." This occurs when changing the root password in single user mode. The root password change is not synchronized to LOP, and the user might fail login to LOP when using the new password. Workaround: Repeat the password-change operation in multi-user mode.
ID 441297 When you restart mcpd on 2000/4000 series platforms configured with a Link Aggregation Control Protocol (LACP) trunk, the trunk remains down. This occurs on 2000/4000 series platforms with an LACP trunk when mcpd is restarted. Trunk status remains down after the restart, and interfaces are all reported as 'uninit'. Functionally, interfaces are all reported as 'uninit' does not affect single interface VLANs as traffic is still correctly carried. Workaround: None.
ID 441482 Although there is a tmsh provision command shown for Secure Web Gateway (SWG) on platforms with less than 8 GB of memory, running the command fails because there is no support for SWG on those platforms. This applies to certain BIG-IP appliances that have less than 8 GB of memory, and to vCMP and VE guests with less than 8 GB of memory allocated. (For memory information, see the Platform Guide for your platform.) Provisioning fails with a message similar to the following: Provisioning failed with error 1 - 'Memory limit exceeded. 5656 MB are required to provision these modules, but only 3964 MB are available.' Workaround: You may provision APM plus SWG only on platforms with 8 GB of memory or more. To use APM and SWG together on platforms with exactly 8 GB of memory, LTM provisioning must be set to None. (To do so, uncheck the box next to Local Traffic (LTM) on the Resources Provisioning screen, if applicable.) To fully support the LTM-APM-SWG combination, reserve at least 12 GB of memory for VE instances, or at least 16 GB for vCMP guests on BIG-IP or VIPRION platforms.
ID 441642 The primary symptom will be unrotated monitor log files. Other symptoms include: - Error messages: -- error: /etc/monitors/monitors_logrotate.conf:6 unknown unit 'B' -- error: found error in /var/log/monitors/*.log , skipping - No disk space This occurs in /etc/monitors/monitors_logrotate.conf. Monitor logs will not consider file size for rotation criteria. An email notification is generated periodically, which references an error in /etc/monitors/monitors_logrotate.conf. Workaround: edit /etc/monitors/monitors_logrotate.conf to be "size=5M" instead of "size=5MB" the file should look like this once edited: /var/log/monitors/*.log { compress missingok notifempty rotate 7 size=5M olddir=/var/log/monitors }.
ID 441719 The CRYTPO command can trigger a core when using invalid algorithms (for example, using a symmetric key (hamc-sha 256) instead of an asymmetric key (SHA algorithm ). This is a negative test that only helps to verify iRule completeness. This occurs when the CRYPTO:: commands use invalid algorithms. The system drops a core. Workaround: Only use the same type of algorithms (asymmetric or symmetric alone).
ID 441789 If provisioning is changed too quickly some processes are not allowed to properly finish. This can lead to core files. Changing provisioning levels before module daemons are fully up. Core file generation. Workaround: Check daemons to ensure they are running before making changes to provisioning.
ID 441796 "When you run hsb_snapshot or qkview from the command line, this may cause a watchdog reboot. One or more messages similar to this appear in the log: info kernel: Program hsb_snapshot tried to access /dev/mem between 164e6b000->164e6c000." Running qkview or hsb_snapshot from the command line. System reboot. Workaround: Do not run qkview or follow workaround procedure in SOL10052
ID 441833 Exporting Application Acceleration Manager performance reports generates files with incorrect extensions. The results are browser-dependent and not limited to csv exports. Problem encountered when exporting web acceleration performance reports in xml, csv or xls formats. An export file with an incorrect extension is saved, usually a file with a .do extension. Although there is no workaround, you can rename file to the correct extension. Workaround:
ID 441888 Hardware syn cookies are not supported on non-HSB platforms such as 4200/2200 platforms. However, both CLI and GUI have options to enable this option. Enabling this option has no effect on unsupported platforms. This occurs on non-HSB platforms when using hardware syn cookies. Enabling this option has no effect on unsupported platforms. This is a cosmetic issue, and there is no workaround. The system internally detects whether a platform supports hardware syn cookies and ignores the setting on unsupported platforms. Workaround:
ID 442227 When using tmsh, a user can set the start time or end time for the database download schedule as 24:01. The supported time range is between 00:00 and 23:59. User could set the download schedule more than 24 hours in start time or end time using tmsh Download schedule might behave randomly. Workaround: To prevent any problem with the schedule, set the time range between 00:00 and 23:59 or use the GUI to set the time.
ID 442489 The values when viewing the licensed SSL and compression limits are incorrect. Any multi-core system with SSL and/or compression licensed. Users think they have a different limit than the system actually has. Workaround:
ID 442569 There are some SELinux errors that can occur in this release when installing a hotfix, including /usr/sbin/load_policy: Can't load policy: No such file or directory. This occurs when installing a hotfix. The system presents messages: Can't load policy: No such file or directory. Workaround: None, but these errors are benign and SELinux corrects itself after reboot.
ID 442613 After user modifies tag map data group content, the tag replacement function may still use the old tag mapping data. After user assigns a data group to FIX profile's sender tag map attributes, user modifies the content of the data group. The replaced tag may still be the data defined in the old data group, this causes the FIX message receiver does not recognize the tag and reject the message. Workaround: After user modifies data group, user comes to FIX profile configuration to re-define the attribute by removing the sender tag map and adding it back.
ID 442647 Due to a mistaken internal object-size conversion, the statistical data used by the IP::stats iRule command reports a negative number when the data exceeds 2**31. Transferring more than 2 gigabytes or 2 billion packets on a connection that then uses IP::stats commands in an iRule will show a negative number. iRules cannot rely on the validity of the IP::stats counters when more than 2 gigabytes have been transferred. Workaround: Upgrade to a fixed version.
ID 442961 When more packets per second than defined in TM.MaxRejectRate causing "No handle" error is reaching TMM "Limiting closed port RST response" or "Limiting icmp unreach response" messages are logged. Packets per second causing "No handle" errors has to exceed TM.MaxRejectRate. Confusing log messages. Workaround: None.
ID 442974 When using certain common infrastructure like the MDS proxy as a generic half proxy, when a module requires specific properties from TCP, it isn't possible to tweak the associated TCP profile because other modules using this infrastructure might also be affected. Module requiring specific properties of TCP, when using certain common infrastructure like the MDS proxy as a generic half proxy. Delayed acks are enabled on the associated TCP profile and this is causing some performance problems. Workaround:
ID 444710 Out-of-order TCP packet will be dropped if it occurs during 3-way handshake. Client initiates TCP connection to BigIP with ACK segment arriving after (i.e. out-of-order) a second packet. Resultant sequence: 1. Client - BigIP : SYN 2. BigIP - Client : SYN-ACK 3. Client - BigIP : PSH, ACK (w/Segment #2) =-- Out-of-order ; Must be retransmitted. 4. Client - BigIP : ACK (w/Segment #1) Packet must be retransmitted by client. Workaround:
ID 445430 While nominal and minimum are not supported in this release of software, they may be provisioned. In doing so, the system will automatically provision the vcmp module to dedicated. If the system already provisioned vcmp to the dedicated level, then any running guests will be restarted. "vcmp is provisioned as dedicated guests are running" guests will be restarted with a new qemu process Workaround: if vcmp is already provisioned, do not attempt to adjust the provisioning levels to nominal, minimum or dedicated.
ID 445800 BIG-IP configurations fail to load after upgrading from version 10.x to 11.x. This issue occurs when all of the following conditions are met: -- Your configuration contains a pool that is monitored by the default SMTP monitor. -- You upgrade from BIG-IP 10.x to 11.x, or attempt to load a BIG-IP 10.x user configuration set (UCS) on a BIG-IP 11.x system. The configuration fails to load upon upgrade, and the system posts the error: BIGpipe unknown operation error: 01070712:3: Cannot use default monitor template (/Common/smtp) - ltm/validation/MonitorRule.cpp, line 351. Workaround: "Create an attribute-less smtp monitor, assign it to all the pools that use the base smtp monitor, and load the configuration monitor smtp-defaults { <<<<< defaults from smtp interval 5 timeout 16 time until up 0 dest *:* } pool poolA { monitor all smtp-defaults <<<<< members { 10.1.16.108:smtp {} 10.1.16.109:smtp {} 10.1.16.110:smtp {} } }"
ID 446712 When FTP is used with LSN pool, the data connections do not count towards the LSN client connection limit count. FTP is configured with LSN pool whose client connection limit value is greater than zero Data connections(active/passive mode) are not counted hence a subscriber will be able to create more connections than specified by LSN pool client connection limit Workaround:
ID 446713 1st boot to v11.5.0 causes daemon restarts and error messages on B4300/B4300N blades. This happens on each blade except blade1 (which is the Primary). When this occurs, the system posts various error messages and the daemon restarts. Workaround: None.
ID 446717 When running 'tmsh show sys hardware' on the Primary blade, the 'Blade Temperature Status' reports a blade other than the Primary. In addition, all other slots under this category are not reported. This occurs when running the command 'tmsh show sys hardware' on the Primary blade. tmsh reports the wrong slot under 'Blade Temperature Status' on the Primary blade. Workaround: To find out the temperature status of the Primary blade, use the EUD sensor test.
ID 446963 When messages are queued after processing of the HUDCTL_ABORT, processing those messages might cause a crash. After processing ABORT no other messages should be processed. But in the case in which HUDCTL_SHUTDOWN queued. HUDCTL_ABORT is processed and then HUDCTL_SHUTDOWN (queued by SIP filter), causing the crash. TMM crashes and the system creates a core file. Workaround: none
ID 447043 "Ltm policies have operands that can be matched against a set of values, causing a match when the operand matches one of these values. Sometime it is desirable to match all of the values. The specific situation where this is needed is 'contains'. This is currently not possible and configuring this causes a cryptic error message; 'Failed to compile the combined policies'." "Specify an ltm rule with 2 conditions with the same operand and match type, e.g.: conditions { 0 { http-header name User-Agent contains values { Android } } 1 { http-header name User-Agent contains values { Mobile } }" It is impossible to express certain conditions like 'user-agent contains 'Android' AND 'Mobile'. Workaround:
ID 447874 HTTP pipeline request might cause TCP window stay at 0 and not recover. This intermittent issue occurs when HTTP pipeline requests are sent, and those requests use the GET method. When this occurs, the resulting TCP zero window suspends data transfer. It is possible that the TCP window will be reduced to 0 (zero) and never recover. Workaround: None.
ID 447958 "A slow clientside SSL connection may result in a timeout due to the new default SSL timeout of 10 seconds. tm.rstcause may indicate ""SSL alert timeout exceeded""." Clientside is clientssl, and it is a slow connection such that it may require longer than 10 seconds. Data transfer might be interrupted. Workaround: Increase the alert timeout value in the configuration.
ID 448409 The 'verify' option on the 'load sys config' command is supposed to ensure that a configuration (either from a file or pasted to the terminal) is valid, but not have it take effect. However, the internal centralized management interface (CMI) state, including the connections to other devices, may be lost. Provisioning may also be impacted. This affects CMI if it is configured. CMI connections to other devices may be lost. Workaround: You can avoid this issue by using the 'load sys config verify' command 'merge' option, which keeps the current configuration during the validation step.
ID 448493 SIP response is not forwarded to the client. They will get dropped. This occurs when using SIP OneConnect with an iRule that uses the node/snat command in SIP_RESPONSE event in the iRule to direct the SIP response from the server. Some SIP flows do not complete, which affects the SIP clients. Workaround: Remove the node/snat command from SIP_RESPONSE event processing in the iRule.
ID 449158 "Http request to a vs:80 with a default pool and an iRule that specifies nexthop (to a mac address on the internal vlan) doesn't work - no packet forwarding occurs." "Http request to a vs:80 with a default pool and an iRule that specifies nexthop (to a mac address on the internal vlan) doesn't work - no packet forwarding occurs." Packet forwarding does not occur Workaround: None
ID 449502 Diameter monitor script doesn't allow custom grouped AVPs that contain only a single element. Capabilities Exchange Answer (CEA) with a custom grouped AVP containing only a single attribute. Duplicating the attribute in the Diameter monitor script doesn't work either. The monitor will fail. Workaround: Use multiple attributes, or use non-custom grouped-AVP.
ID 449596 At the command line, when you issue the 'show bgp neighbors <x.x.x.x> advertised-routes' command on one of the BIG-IP systems that is configured to establish a bgp session with another system, an error output is observed: % No such neighbor or address family. The BIG-IP system is configured to be in a bgp session with another system using IPv4 addresses. The command shows incorrect output. Workaround: "Any of the three commands will give you the correct result: show bgp (ipv4|ipv6) (unicast|multicast|) neighbors (A.B.C.D|X:X::X:X) advertisedroutes show ip bgp neighbors (A.B.C.D|X:X::X:X) advertised-routes show ip bgp ipv4 (unicast|multicast) neighbors (A.B.C.D|X:X::X:X) advertised-routes"
ID 449747 All of the self links and reference links in iControl REST responses will contain localhost instead of an IP address or a hostname or an FQDN. This occurs when using iControl. iControl REST clients will need to substitute 'localhost' with the correct server name (or IP address or FQDN) when navigating links returned in responses .This is by design. Workaround: iControl REST clients will need to substitute 'localhost' with the correct server name (or IP address or FQDN) when navigating links returned in responses.
ID 451549 If a fan tray is removed and replaced with another within a 30 second interval, the serial # of the new fan tray is not reflected in the hardware information. Chassis with a fan tray running any supported version of BIGIP. Any chassis where the fan tray is changed. Workaround: Wait more than 30 seconds between removing the fan tray and replacing it with a new one
ID 452487 If a sync-compatible pool is created and given pool members, pushing that sync operation will cause the member count to be incorrect on all other devices. This only affects device groups where incremental sync is in use. The number of pool members will be displayed incorrectly at various points (GTM statistics, the ltmPoolMemberCnt SNMP variable, and the GUI). Workaround: Perform a sync between the creation of the pool and the pool members.
ID 452683 The one-line option does not work for some configuration objects. This occurs when using when the 'one-line' option is specified for certain objects, for example, the APM resource. This results in multi-line display instead of the expected one-line display. Workaround: None.
ID 452837 It is not possible to add a device in the ca-devices of the Root trust domain using iControl REST. This occurs using iControl REST. Cannot set up a HA pair programmatically using iControl REST. Workaround: Workaround is to set up HA using GUI or TMSH.
ID 453232 The double-tagging packet stats counters are only supported the on VIPRION blades: B2250, B4300, B4340, and B4350, and on BIG-IP platforms: 10000, 10050, 10050N, 10200, 10250, 12050. Double-tagging packet counters are not supported on the B2100/B2150 VIPRION blades or the BIG-IP platforms 5000 series and 7000 series. The system is configured for and passing double-tagged traffic and showing zero values for the Double Tagged Packets stats in the GUI, TMSH, or via the iControl APIs. When running the command 'tmsh show net interface all-properties' on the unsupported platforms, 'DoubleTag Pkts In' and 'DoubleTag Pkts Out' always show a value of 0 (zero). Workaround: None.
ID 453362 SSL forward proxy does not work with OneConnect when there are multiple connections from the same client to the same server. This occurs with virtual servers configured with OneConnect. SSL forward proxy does not work. Workaround: Multiple connections worked fine without OneConnect.
ID 454209 TMM crash with a backtrace including dns_dev_pool coring at line 360. DNS virtual w/o datagram lb mode. Failover, traffic interruption. Workaround: Enable datagram-lb-mode in the udp profile used by the DNS virtual server, or turn off dns queueing via the db variable dns.queuing.
ID 454640 "Secondary blades' mcpd instances may restart on boot with messages like the following: 01071038:5: Secondaries couldn't load master key from the database. 01070734:3: Configuration error: Configuration from primary failed validation: 01071029:5: Master Key not present." Any VIPRION bladed system or VCMP guest may encounter this rarely. mcpd will restart on secondary blades but will then settle and the system will finish booting as normal. Workaround:
ID 454671 When SIP is used with LSN pool, the media connections do not count towards the LSN client connection limit count. SIP ALG is configured with LSN pool whose client connection limit value is greater than zero Media connections are not counted hence a subscriber will be able to create more connections than specified by LSN pool client connection limit Workaround:
ID 454672 When RTSP is used with LSN pool, the media connections do not count towards the LSN client connection limit count. RTSP is configured with LSN pool whose client connection limit value is greater than zero Media connections are not counted hence a subscriber will be able to create more connections than specified in LSN pool client connection limit Workaround:
ID 455090 "#" is TCL comment command which causes the TCL parser to ignore the rest of the line. When user wrongly inserts "#" to a command which has an open curly brace ({) at the end of line, there is a mismatch of open and close braces, but user can save the iRule script through the web interface and TMSH and later on at traffic run-time the system fails. "1. ""#"" at the start of a line which ends with ""{"" 2. The ending ""{"" perfectly matches a ""}"" in the script" When the iRule script runs at traffic time, system fails. Workaround: comment out or delete the matching closing "}".
ID 455467 QinQ VLAN functionality requires supported versions of software running on the guest and host. "QinQ VLAN configurations fail to load on vCMP guests The host or guest has a QinQ configuration object and is not running QinQ supported software" "This only applies to QinQ VLANs in a vCMP environment. This does not impact legacy vCMP VLAN functionality (non QinQ VLANs configured per guest on the host)" Workaround:
ID 455525 "If for some special reasons, the role and partition information are not present, there are two cases where this might occur: When the user's role and partition information is not provided, by default, the no-access role and all partitions are assumed. If the user's role and partition are explicitly deleted, this is also allowed with no further error message. This is potentially useful in cases where you want to preserve the user data such as password for later re-activation the user. In both cases, the user cannot login successfully due to the lack of the necessary role-partition information." User's role and partition information is missing or removed. The user with missing role and partition information is prohibited from login. Workaround:
ID 455840 EM analytic does not build SSL connection with discovered BIG-IP system. When using management SSL client profile. EM analytic cannot connect to discovered BIG-IP system. Workaround:
ID 456024 When vCMP is not provisioned, and you load vCMP guest objects, the guest state changes to CONFIGURED to avoid failing to load the entire configuration. This occurs when you save a UCS file from a vCMP-provisioned host with guests in the PROVISIONED or DEPLOYED state. After loading the UCS, the BIG-IP system successfully reboots into vCMP mode, but the guests cannot automatically deploy. Workaround: You must manually change the state of desired guests to PROVISIONED or DEPLOYED.
ID 456378 When using ipother profile, if there's an iRule that fires on CLIENT_ACCEPTED that contains a discard action, tmm is going to failover. Virtual server with ipother profile and an iRule firing on CLIENT_ACCEPTED with discard action. Site down since tmm fails over. Workaround: Use CLIENT_DATA as the firing event for the iRule. Will have the same expected result when discarding the connection.
ID 456508 Deleting persistence entries via iRules in PBA mode will not completely remove persistence as having a PBA block implies some persistence exists. "lsn mode = PBA iRules use LSN::persistence-entry to create and delete address persistence entries" "using lsndb to view persistence entries may cause confusion as the deleted persistence entries may still be present. These persistence entries will go away when they timeout." Workaround:
ID 456854 You might see error messages indicating that a specific string 'has no meaning.' This typically occurs when an iRule uses a regular expression including a backslash (for example, \B). The system posts an error similar to the following: /Common/rule1:2: warning: ["\B" has no meaning. Did you mean "\\B" or "B"?][{\B}]. This message is cosmetic only. The config loads successfully, and the iRule works as expected. Workaround:
ID 457149 If a local password policy with password expiry is set, even remotely authenticated users are subject to the password policy. This may disallow users whose password has been remotely authenticated but who have an expired password. Local password policy is set, but remote authentication used. some users may be locked out after the password policy expires their password. Workaround: Do not use a local password policy with remote authentication.
ID 457799 Configuration validation disallows creation of a static route in the default route-domain with an interface in a user-defined route-domain as the nexthop. This is a design limitation. Attempt to a route to a network in the default route-domain address space with a nexthop object that is in a different route-domain. Cannot specify nexthops into a user-defined route-domain. Workaround:
ID 457934 Some connections through a virtual server using SSL persistence hang and cause a high CPU condition in tmm. This occurs only when SSL persistence is configured as the default persistence profile, and there is a fallback profile of either source_addr or dest_addr. Large increase in CPU usage on the box and a percentage of SSL connections through the virtual server are delayed and eventually reset Workaround:
ID 458526 When a BIG-IP device is running the spanning tree protocol, it may continue to send one or more TCN BPDU packets after receiving a Topology Change Acknowledgement BPDU. Workaround:
ID 458527 When running spanning tree, a BIG-IP device sends TCN BPDUs after receiving a topology change notification on its root port. A BIG-IP device is connected to another switch running spanning tree and the BIG-IP device is not the root switch of the tree. No observable network impact from the TCN flag being sent in the BPDU. Workaround:
ID 458528 When a BIG-IP product is configured to use STP mode, it behaves according to the 802.1D - 2004 standard rather than the 802.1D - 1998 standard in any instance where the standards differ. Workaround:
ID 458822 "tmsh show sys cluster all-properties Availability offline State enabled Reason Too many cluster members HA offline." Blades were rebooted to the same version software, but on a different disk partition. Minimal -- mainly confusion about the state of HA Workaround: Disable and re-enable blades
ID 459048 "monpd is down, mysql is down, vcmp is up" "vcmp is provisioned the vmdisks application-volume exists one or more mysql volumes exist, but are associated with other boot locations" Application visibility will not be available Workaround: "remove the mysql volumes from existing boot locations (tmsh delete sys disk applciation-volume mysqldb_...) restart mysql with ""bigstart restart mysql"" after 30 seconds or so, check the status of mysql with ""bigstart status mysql"" once mysql is running, restart monpd with ""bigstart restart monpd""."
ID 459382 The GWM server can reset the TCP connection to the SASP monitor multiple times. In this scenario, the monitor does not re-attempt connecting the server. This results in incorrect status reporting of pool members and hence data traffic may be impacted. The GWM server sends TCP reset to the SASP monitor TCP connection. This could possibly affect data traffic send to the servers as the SASP monitor is no longer connected to the GWM server. Workaround:
ID 459471 ssl-ocsp and ssl-cc-ldap auth profiles can contain the same name leading to issues when trying to delete them. Workaround: Do not create the two auth profiles with the same name.
ID 459596 "Packets leaking onto network Memory leak appearing in tmm" Multicast traffic and a disabled interface Eventual TMM low memory, OOM and traffic outage due to TMM coring Workaround:
ID 459671 iRules source different procs from different partitions and executes the incorrect proc. Multiple iRule procs defined in multiple admin partitions. iRules "proc" lookup algorithm is not deterministic, or Virtual Servers are improperly caching and sharing the lookup results. Workaround:
ID 459753 When including cluster as a component of HA Group, clusterd on secondary blade may restart continuously. This is undesirable. When include cluster as a component of HA group and perform restart on the chassis, the clusterd on the secondary blade restarts continuously. The secondary blade becomes unusable. Workaround:
ID 460500 "When loading the config containing signed iRules, the following error is shown: 01071485:3: iRule (/Common/irule2) content does not match the signature. Unexpected Error: Loading configuration process failed." The iRules must have Global comments (outside any WHEN block) before the first block or after the last block (Global comments between WHEN blocks don't cause any issue). The config file cannot be loaded. Workaround: "- Delete the Global comments (outside WHEN blocks) that lie either at the beginning or at the end of the iRule (before the first or after the last WHEN block) - OR delete the signing entries (definition-signature and signing-key) from the config file bef"
ID 460627 When the SASP monitor starts up, it can attempt to open a new TCP connection to the GWM server when another connection exists to it. This happens when GWM server sends the SendWeight messages to SASP monitor immediately after the registration of the pool member is complete, but the registration of all the pool members is not complete. The SASP monitor fins an existing TCP connection to the GWM server. Workaround:
ID 460751 The RTP and RTCP conn flows get setup in response to the RTSP SETUP request from the client which may ask for one or two connections. When the client has requested UDP connections then those connections are NOT expired when the controlling RTSP connection is closed. For this reason PBA zombie port blocks will not be removed until the RTP and RTCP connections using the ports are deleted. Workaround: A shorter idle timeout can be configured on the RTSP profile so that RTP and RTCP connections are deleted sooner.
ID 460834 TMM asserts with tx_hist full during high rate of new active connections. Workaround:
ID 461140 You cannot configure High Availability (HA) using IPv6 IP address formatting. This occurs when using IPv6 formatted IP addresses. "When adding a peer device using an IPv6 address using the web interface, the system posts the following error message: 'java.io.IOException: Could not read response from server: ParseError at [row,col]:[1,150] Message: The reference to entity 'destaddr' must end with the ';' delimiter.' The system posts a similar error message performing the same operation using TMSH: 'Unexpected Error: Could not add ca-device (error from devmgmtd): [evConnection.cpp:162 tryConnect] evConnect(m_ev, fd, (void *) &destaddr, sizeof(destaddr), &::evOutgoingConnection, this, &m_connId): Network is unreachable.'" Workaround: Set up a IPv4 Self IP in an HA VLAN (VLAN on which each device can communicate with the other). Then add that Self IP to the device. To do so, in TMSH, run a command similar to the following: 'modify cm trust-domain Root ca-devices add { 10.10.3.102 } username admin password admin name 8950-3.sh.siterequest.com'. Running that command retrieves the already-set-up IPv6 addresses for management-ip, the config-sync IP addresses, and Network failover IP addresses already exist from the peer device and syncs both of them, so that HA device trust can work correctly.
ID 461157 There is no stats to indicate that the standby box is out of sync from the active The standby box is out of sync from the active box. No Obvious way to know that the standby box is out of sync from active box. Workaround:
ID 461199 Memory increases when using certain iRule methods related to Diameter (for example, AVP::insert, AVP::replace, AVP::codes). Inside the underlying function dime_method_optional_args_parse, A call to the function Tcl_GetIndexFromObj was not decrementing the refcount of an object. System must execute an iRule that (indirectly) calls the underlying dime_method_optional_args_parse function. Memory increases steadily, and eventually the customer will have to reboot their BIG-IP. Workaround:
ID 461375 The dhcp-enabled property was removed because it cannot be modified and its presence can lead to misunderstanding the configuration. This occurs in version 11.6.0. Can cause misunderstanding of the configuration data. Workaround:
ID 461524 "The command to install ISO or hotfix returns with ""operation unsupported"" error. The details are below - $ curl -s -k -X POST -u admin:admin -H ""Content-Type: application/json"" -d '{""command"":""install"",""image"":""BIP"", ""volume"":""HD1.1"", ""options"":[{""reboot"":true}]}' https://172.27.95.228/mgmt/tm/sys/software/image | python -m json.tool { ""code"": 403, ""errorStack"": [], ""message"": ""Operation is not supported on component /sys/software/image."" }" always Cannot install image or hotfix using iControl REST. Workaround: Use TMSH or GUI to install image or hotfix.
ID 461587 Connection remains half-open and appears in connflow table after receiving FIN/ACK from serverside. the BIG-IP system never sends FIN/ACK to serverside to indicate connection has been closed. Clientside connection is closed before serverside completes 3-way handshake. Serverside never completes 3-way handshake and LB::reselect command is issue via iRule. Connection remains half-open and stuck in connflow table Workaround:
ID 461776 "Regardless of the setting of the DB variable 'qinq.cos', the VLAN priority of packets arriving at customer-tagged interfaces does not correctly affect the egress CoS mapping." VLAN Class-of-Service can not be used with Q-in-Q VLANs on customer-tagged interfaces. Workaround:
ID 462507 If CGNAT PBA is configured for block lifetimes, when the lifetime expires it terminates any flows still associated with that port block. However, SIP media flows cannot be terminated, so the block cannot be released until the media flows terminate. This occurs when the following conditions are met: -- Using CGNAT PBA mode. -- block lifetime set. -- Using SIP-ALG. -- Media flows outlive block lifetime. Blocks cannot be released as expected until media flows terminate. Workaround:
ID 462523 "Installations of block-device-image or block-device-hotfix images within Liveinstall Signature validation enabled guests will fail without signature validation. CC MODE enables this feature by default" "Installation is using a block-device-image or block-device-hotfix. Installation has signature validation enabled (liveinstall.checksig is enabled)." "Local iso and sig files must be used within the guest when making use of the Liveinstall signature checking feature Alternatively, if the host environment is trusted the liveinstall signature check can be disabled within the guest. The value can be modified with ""tmsh modify sys db liveinstall.checksig value disable"". New installations using block-device-image or block-device-hotfix can then take place." Workaround:
ID 462524 "When a User-Agent identifies a browser which has known compression limitations, the ""browser workarounds"" will disable compression. Browsers requiring these workarounds include: - Microsoft Internet Explorer 6.0 - Netscape Navigator 4.1 - Netscape Navigator 5.0 Unfortunately, the functionality will falsely identify many modern browsers as needing compression workarounds, disabling compression." Enable HTTP compression browser workarounds. HTTP compression will not compress responses for modern browsers. Workaround: "Disable browser workarounds. If legacy clients require compression workarounds, an iRule which selectively disables compression depending on User-Agent can be used."
ID 462714 A source address persistence record created on a VIP with a FastL4 profile will time out and be aged out even while traffic is flowing through that flow. The traffic that generates this bug is UDP with checksum of 0. The profile has to be FastL4. Traffic which is either UDP with checksum of 0 , or SCTP are definitely affected. Source address persistence is not usable as the entry ages out while it should not. Workaround:
ID 462853 Invoking the AOM during BIOS Setup or F5 Disk Erase Utility may cause the AOM menu to display incorrectly, or not at all. Additionally, the AOM menu may interfere with the current terminal output, permanently corrupting the appearance of BIOS applications such as Setup or F5 Disk Erase Utility until those applications are exited. The terminal emulator foreground and background colors may be set to black on black, making it impossible to visually navigate the AOM menu. If the AOM menu is exited by pressing the 'q' key, the BIOS Setup or F5 Disk Erase Utility terminal layout may appear corrupt until exited. While running BIOS Setup or F5 Disk Erase utility over the serial console, press the ESC-( key sequence to invoke the AOM. Users should avoid launching AOM during F5 Disk Erase or BIOS Setup. Workaround: "It is advised to have a copy of the AOM menu on-hand when launching the AOM from any BIOS application. See http://support.f5.com/kb/en-us/solutions/public/14000/500/sol14594.html If the AOM menu does not appear to display, it is possible to copy and paste the terminal emulator output into a text editor to see the current state of the AOM menu. It is also possible to force the AOM menu to display by temporarily disabling support for colors in the terminal emulator connected to the serial console."
ID 463970 "When using ""LB::reselect pool <current pool>"" in an iRule, the pool stats don't get increased/updated at all. Virtual servers stats do get increased as expected." "Set up a virtual server with an iRule with the following event handling: when LB_SELECTED { LB::reselect pool pool2 } Hit the virtual server. Verify the Pool stats don't get increased (tmsh show ltm pool) while Virtual server stats do (tmsh show ltm virtual)." Misleading stats reporting, and probably incorrect traffic based load balancing. Workaround: "Add extra logic to ensure the redundant call to LB::reselect pool SAME_POOL is not performed. Like: if {[LB::server pool] ne ""/Common/poolIwant""}{ LB::reselect pool ""/Common/poolIwant"" }"
ID 464048 User is unable to use Google Docs through Portal Access due to multiple errors both shown by web application itself and in JS console. Google Docs is accessed through Portal Access. It is impossible to use Google Docs through Portal Access. Workaround:
ID 464116 When a response-adapt profile is applied on a virtual with ramcache, HTTP responses are not cached. Both ramcache and response-adapt on a virtual. HTTP responses are not cached. Workaround:
ID 464132 Cannot disable serverside SSL via iRule command or CPM policy. "This occurs on a virtual server that meets the following conditions: - Rewrite profile - Serverssl profile - iRule using the 'SSL::Disable serverside' command in an HTTP_REQUEST event or a CPM policy with a 'server-ssl disable' action and an http-uri condition." Cannot disable serverside SSL. Workaround: Utilize iRule with 'SSL::Disable serverside command in the SERVER_CONNECTED event.
ID 464489 "User is unable to create or modify SSL profiles, and sees an error message in the LTM log similar to: May 9 11:41:23 HouF5mgmt err mcpd[6412]: 01070313:3: Error reading cert PEM file /config/filestore/files_d/Common_d/certificate_d/:Common:default.crt_14711_1 for profile /Common/testclientssl: Memory exhausted. However, memory is not exhausted." User must have at least one SSL profile, or be attempting to create one. SSL profiles can't be created or modified. Workaround:
ID 465052 TMM cores when executing an HTTP::cookie command in an iRule. If the command does not have the minimum required number of arguments, the code is not checking for this condition; it assumes they are there. An iRule command must execute an HTTP::cookie command (such as "HTTP::cookie sanitize") with missing required arguments. TMM restarts, possibly causing a failover in an active/standby system. Workaround: "Ensure all HTTP::cookie commands in iRules have the correct number of arguments. A work around is to add a line ""log local0. some text"" before the line ""HTTP::cookie sanitize"". Then, there will be no tmm crash."
ID 465197 The OData $filter is implemented only for filtering iControl REST results based on the partition in which config objects reside. No other filtering can be done. Always. No filtering can be done other than partition. Workaround:
ID 466017 Tab-completion does not work for TCP/HTTP profiles with the command: ltm virtual profiles'. This occurs with TCP and HTTP profiles when using Tab-completion in tmsh. Cannot use Tab-complete with TCP or HTTP profiles. Workaround: Type the profile name out completely, instead of using tab-completion to complete the name of the profile.
ID 466285 "When certain users switch partitions, their displayed role will show Unknown for several seconds. It will switch to display their appropriate role for the selected partition after that time period. This issue only affects users who do not have access to all partitions on the BIG-IP. This issue is only cosmetic, the user's actual role switches immediately. Any activity performed in this time period will be performed as the user's true role in that partition." "A user is logged in who has access to selected partitions (not all on the box). The user switches partitions." No real impact. The user will see Unknown as their role in the top bar in the GUI. Workaround:
ID 466570 When grandchild (child of a child) monitor is viewed in web UI, error "An error has occurred while trying to process your request." is displayed. "Configure a grandchild (child of a child) http monitor (either via tmsh or WebUI) save the config, then load the config via tmsh. Monitor objects are loaded alphabetically, by name. In order to encounter this bug, the grandchild must be loaded before the child. For example: http -> z_child -> a_grandchild a_grandchild will load before z_child, triggering the error." Limits the ability to manage monitors via web UI. Workaround: Name monitors such that the child monitor is loaded before the grandchild.
ID 466837 Using the GUI to modify a virtual server with multiple profiles results in multiple audit logs. This occurs with multiple profiles on a virtual server. The system writes multiple audit logs for a single user transaction. This is intended functionality. Workaround:
ID 466875 Egress packets have a source address that is not associated with the VLAN or interface. "Occurs when the following conditions are met: - Virtual utilizes SNAT automap. - There exists a route matching a self-ip on interface A to a VLAN on interface B." Packets may not be routed properly. Workaround: Use SNAT pool instead of automap.
ID 467043 Modifying banner and banner-text while sshd service is disabled, result in error. This occurs when modifying banner and banner-text while sshd service is disabled. The system posts an error. Workaround: "Workaround is to change config order to enable login before banner change, or perform the operations in separate commands. tmsh modify sys sshd login enabled banner disabled banner-text none or tmsh modify sys sshd login enabled tmsh modify sys sshd banner disabled banner-text none"
ID 467181 The TMM can core if forced to shutdown while logging or using iRule side-channels. There is a race condition in the cleanup of existing sockets during shutdown. The variation in 11.2 has only been seen in debug builds of the TMM. In the case of this bug, syslog logging was being used. The log server fell behind, and the logging proxy was still delivering data when its socket was killed. This code was refactored in later releases to shut down "less gracefully" when the TMM is going down. The bug is essentially harmless as it has only occurred during manual shutdown of an instrumented build. Workaround:
ID 467196 In this release, the max log size setting is 1024. This causes large systems (multiple blades, high-availability) to truncate log files, and often prevent log files from storing messages for more than 24 hours. Multiple blades in a high-availability configuration. Cannot have log files spanning more than 24 hours. This makes it very difficult to use the log when diagnosing problems, because the system overwrites the files before the customer can report the issue. Workaround: From the TMSH shell, run the command: tmsh edit /sys log-rotate all-properties. This uses TMSH to start the vi editor. Modify the contents of the file. Type i to enter insert mode (i.e., edit mode). At the location 'max-file-size,' change '1024' to '0'. Type :wq (with a colon at the beginning) to write the edited file and quit the editor. Verify the changes using the command: edit /sys log-rotate all-properties, and then type :q to quit vi.
ID 467589 "The /usr/share/mysql/purge_mysql_logs.pl script that ships with the new install (and is run hourly via cron) throws an error. The script is meant to be exited if AAM, ASM and PSM are not provisioned, but the check is not done appropriately and it continues execution, failing later. When running the script /etc/cron.hourly/purge_mysql_logs.pl (linked to /usr/share/mysql/purge_mysql_logs.pl), the following error is output: Usage: $class->connect([$dsn [,$user [,$passwd [,\%attr]]]]) at /etc/cron.hourly/purge_mysql_logs.pl line 27" BIG-IP with NO AAM, ASM and PSM provisioned for this issue to happen. The script gives false output and attempts to execute invalid actions. Workaround: "Remount /usr partition as RW: # mount -o remount -rw /usr Edit /usr/share/mysql/purge_mysql_logs.pl and change the original check: unless( $provisioned_am || $provisioned_asm || $provisioned_psm ) { exit 0; } to: unless( $provisioned_am == 1 || $provisioned_asm == 1 || $provisioned_psm == 1 ) { exit 0; }"
ID 467646 If the device experiences an IDE DMA timeout, some processes become unresponsive and the kernel logs messages containing 'DMA timeout error' in kern.log. An unfulfilled request from the kernel of the IDE device might result in uninterruptible, stuck processes. This occurs on VIPRION B4100/B4100N (A100), B4200/B4200N (A107) blades and on Virtual Edition (VE) configurations deployed with IDE storage drivers (Xen, Hyper-V). This condition can cause the i/o request to never complete and result in unresponsive and uninterruptible processes. Various symptoms result depending on the affected process. Some conditions might require a power cycle to correct. Workaround:
ID 467652 "The Octeon compression card on the customer's 6900 systems occasionally seem to stop servicing compression jobs and all compression rolls over to software, resulting in high CPU, high memory, and eventual device instability. The customer had another event, failed over, and then cored TMM." a large number of enqueued jobs and the amount of software compression that has occurred core Workaround:
ID 468021 "When attempting to upgrade to 11.5.0 or later, from an earlier release, some .ucs files may cause the system to run out of memory, and the kernel to kill the process. You may also see an error: ""UCS application failed; unknown cause.""" "In the .ucs file, in bigip.conf, is a section like this: ltm profile client-ssl /Common/my-clientssl { ... defaults-from /Common/wom-default-clientssl ... } The problem happens because /Common/wom-default-clientssl and /Common/clientssl-insecure-compatible was not defined in a couple of our fixup scripts, resulting in infinite recursion in another fixup script." It can be impossible to upgrade the software image to 11.5.0 or later because the config fixup exits in error. Workaround: A workaround is to change instances of "wom-default-clientssl" and "clientssl-insecure-compatible" to "clientssl" in the configuration files in the UCS archive.
ID 468323 bdpd has one occurrence of a SIGSEGV in bgp_global_delete function while handling SIGTERM. BGP protocol daemon is killed with SIGTERM. Generates a core file but does not impact traffic or system performance. Workaround:
ID 468472 "TCP4 asserts if it receives spurious internal events. This results in the following assert: ""../modules/hudfilter/tcp4/tcp4.c:937: %svalid pcb%s""" "If the tcp filter receives a spurious events, then it will cause an assert. This is a general problem with how events are internally propagated and this bug is one instance where this can occur. In the case of this bug, SSL and compression delayed propagation of events through the HUD chain/filters. This leads to a spurious event received by the TCP filter and the assert." TMM will assert and failover. Workaround:
ID 468473 If a monitor send or receive string contains a backslash character, this backslash should be escaped (prepended with another backslash) when the monitor is saved through tmsh. If the string in the configuration contains proper backslashes, they will be removed upon save, causing load to fail due to an incorrect number of backslash characters. The error seen will be something similar to the following: 01070642:3: Monitor /Common/myhttp_80 parameter contains unescaped " escape with backslash. To trigger this, a monitor must be configured with a send or receive string which uses triple backslash escape characters and double-quote character. Loading a configuration that has been saved using this version will run into a load failure do to an incorrectly escaped double-quote or backslash. Workaround: "Configuration file can be run against a simple sed command. Something like: sed -ie 's/\\""/\\\\""/g' /config/bigip.conf"
ID 468505 tmsh crypto commands will fail when executed in tmsh batch mode. tmsh batch mode and 'sys crypto' commands. tmsh crypto commands will fail when executed in tmsh batch mode. Workaround: Run the tmsh 'sys crypto' commands outside of a 'cli transaction' i.e. not in batch mode.
ID 468542 Virtual server with SPDY profile ignores SNAT 'None' setting This occurs on virtual servers that have an associated SPDY profile when the Source Address Translation setting is 'None'. Virtual server with the SPDY profile determines the server-side source address using SNAT Automap, which might result in the incorrect server-side source address. Workaround:
ID 469035 "If the configuration included encrypted items -- like an LDAP bind password -- that are empty strings, a SecureVault rekey operation will fail with this error: 01071029:5: master_decrypt failed during rekey. This may occur when using the ""modify /sys crypto master-key"" tmsh command, or during the introduction of a device into a Trust Domain." Empty string as encrypted configuration item The rekey operation will fail. This may result in a ConfigSync failure. Workaround: Do not use empty strings as passwords. Alternately, remove the offending configuration object (which may require changing system authentication to a different source), perform the rekey operation, and then recreate the configuration.
ID 469296 MCPD config validation error might occur. This occurs when MySQL infinitely restarts on one of the blades after a failover event. Config sync fails, or MCPD restarts, and the system logs the message 'requested integer (0) is invalid'. Workaround:
ID 469366 A config sync operation might fail with a parent-profile-not-found error message, despite the fact that the parent profile is present in the running configuration of both systems. On the sync target (the system receiving the configuration, and the one that reports a sync failure), a system-supplied profile (e.g. /Common/serverssl) has been modified, and is present in /config/bigip.conf. An administrator is unable to synchronize system configurations. The system might post messages similar to the following example: '01020036:3: The requested parent profile (/Common/serverssl) was not found.' Workaround: "One of the following: 1. Manually replicate the changes on the base profile to the system that is sourcing the config sync. 2. Undo the changes to the base profile on the system that is receiving the configsync (to do so, save the configuration, manually remove the base profile from /config/bigip.conf, and then re-load the configuration), and then perform a force sync operation. 3. Perform a sync in the other direction. Important: Performing a sync in this direction overrides any unsync'd changes on the other system."
ID 469549 "Upon reviewing the log file in /var/log/ltm, a user may see the following error: err mcpd[8105]: 01070820:3: User Modification Denied: User (root) may not change the role of system account (admin)" This only happens during the first reboot after a software install. If the error is seen again, the audit log should be checked. There is no known impact at this time. Workaround:
ID 469613 "Crash in mcpd on a bad fdnext element while in MCPConnection::sendMessage(). Core was generated by `/usr/bin/mcpd -dbmem 208 -listen 127.0.0.1 -f'. Program terminated with signal 11, Segmentation fault." memory corruption. crash Workaround: 1. upgrade to later version, this crash only seen in 10.21
ID 469705 TMM panics with following string: "domain != RT_DOMAIN_NONE" "SIP Requests are being processed with a via header that does not contain an ""rport"" attribute. Virtual has ""dialog aware"" SIP profile attached." TMM panic Workaround: Disable the "dialog aware" option on the SIP profile, or configure SIP OneConnect.
ID 470203 Setting a remote syslog destination to a localhost address results in recursive log messages. Using 127.0.0.1 or a hostname resolving to it as a host for syslog's remote-server. Using a localhost address as a remote syslog destination results in continual log entries until the BIG-IP system runs out of disk space. Workaround: Use a non-local remote host for syslog's remote-server.
ID 470807 When an iRule specifies a data-group that is not in Common, or that does not have an explicit path to it, it does not result in an error when the iRule is saved, or during runtime. User saves an iRule with a data-group not in Common or with an explicit path to it. When such an iRule is saved, it can cause all traffic to fail. Workaround:
ID 471042 During periods of high velocity in the traffic pattern, datastor will seem to stop caching new objects. A traffic pattern that requires that a given percentage of the working set be displaced in order to move the cache content towards the new working set. For web sites that have a fairly static working set, this will reduce the efficacy of their caching by a percentage relative to the write reserve. Workaround:
ID 471059 An HTTP Cookie value containing a space appears before the persistence cookie causes the persistence cookie to be ignored. HTTP request contains malformed cookie value that occurs before the BIG-IP system persistence cookie, For example: Cookie:foo=bar =bar; BIGipServerhttp=60361226.20480.0001 Persistence is ignored. Workaround:
ID 471288 tmm might crash with session-related commands in iRules. This occurs when the following conditions are met: 1) session/table command. 2) client_closed/server_closed irule tmm might crash and failover occurs. Workaround:
ID 471393 Saving very large files in /config results in failure to upgrade and system rebooting due to resource starvation. This means one or more files large enough to fill up the /config directory so that the upgrade or config copy fails. Too little room left in /config. System reboots; unable to complete config operations. Workaround: The workaround would be to move enough files out of the /config directory in order to avoid the problem.
ID 472308 When the management address changes (either as a result of enabling mgmt-dhcp, or the leased address changing), the system does not synchronize this updated address to other devices in the failover device group / trust domain. (That is, the system does not trigger an update to the device_trust_group). This occurs on HA configurations. This can be catastrophic in an HA environment. The sod process discards any HA heartbeat traffic it receives (e.g. over the self IP addresses) that does not contain a 'known' cluster_mgmt_ip. Workaround:
ID 472573 Cannot set a password of 14 characters --the maximum length-- for the security officer. "Occurs when the following conditions are met: - NG FIPS security device installed. - Initialize FIPS security domain. - Attempt to set password of maximum length (14 characters)." Setting a password using more than 14 characters prevents the creation of the security officer password, and causes device initialization to fail. Workaround: Use a password shorter than 14 characters for the security officer.
ID 472867 Using Firefox version 31 or later cannot connect to a BIG-IP system, The browser hangs instead of connecting properly and displaying the configuration utility. No error messages are given, so it appears that the BIG-IP is down. This occurs when using Firefox version 31 or later. Cannot connect to the BIG-IP Configuration Utility using the using Firefox version 31 or later. Workaround: Use a different browser, or manually regenerate the device's SSL certificate and restart the web server. To manually regenerate device SSL Certificate: 1) /usr/bin/openssl req -rand /dev/random -new -sha256 -key /config/httpd/conf/ssl.key/server.key -x509 -days 3650 -out /config/httpd/conf/ssl.crt/server.crt -extensions usr_cert. 2) bigstart restart httpd. If your system is already running version 31 or later, reinstall the version 30 Firefox browser.
ID 473033 Datastor did not use the normal syslog facility, causing some very rare disk full errors in /var/log. "When datastor is heavily overloaded or experiencing a traffic pattern that it was not designed for, it can generate copious notice messages to its log. Because datastor writes directly to its log, log rotation may seem to work, but inadvertently leave a large, hidden file in /var/log." In very rare cases, this hidden large file may cause out of disc errors, preventing logging from occurring. Workaround: Log rotate can be configured to restart datastor if this becomes an issue.
ID 473105 With 'pva-acceleration' set to 'guaranteed', the BIG-IP system can take up to five seconds to detect that one of either the client-side or server-side connections has not been offloaded to the ePVA hardware. This occurs with 'pva-acceleration' set to 'guaranteed' and only one of client or server connections is offloaded to hardware. This results in the connection that has not been offloaded being reset five seconds after being established. Workaround:
ID 473200 Manually renaming a virtual server causes unexpected configuration load failure. This occurs when attempting to reload a BIG-IP system configuration containing a virtual server with an empty pool that was renamed by editing bigip.conf manually. "Cannot reload configuration. The system posts the following error: 01020056:3: Error computing object status for virtual_server broken (<old virtual server name>). Unexpected Error: Loading configuration process failed." Workaround: "Perform any one of the following: a.) Remove the pool assignment from the virtual before renaming b.) Ensure the pool contains members before renaming c.) After renaming, issue ""bigstart restart"" Please note, some of these workarounds may result in a temporary service disruption."
ID 473213 Failed system fan emergency alert is exhibited as critical alert at LED and LCD screen. A failure of a system fan would cause this issue to appear. Relatively small event causes unnecessary critical alarm instead of just emergency level. This alarm should be treated at an emergency level and not critical. Workaround:
ID 473724 If a DC PSU hotswap is performed on BIG-IP 10000-series or 12000-series appliances, but the PSU is left unpowered, the front panel PSU LED is amber, but no other alerts, LCD messages or LED indications are issued to indicate that the appliance is in a non-redundant PSU state. "This occurs on BIG-IP 10000-series or 12000-series appliances if a DC PSU is hot-swapped but external power is not applied. FND850 DC PSUs for BIG-IP 10000-series or 12000-series appliances do not indicate their presence to the BIG-IP system until external power is applied. Thus, the presence of an unpowered DC PSU in this case is not detected, and its status is reported as Not Present. By design, no alerts are issued by BIG-IP for non-present PSUs." Operators may not be aware that the appliance is left in a non-redundant PSU state after a DC PSU hot-swap. This is expected behavior. FND850 DC PSUs for BIG-IP 10000-series or 12000-series appliances do not indicate their presence to the BIG-IP system until external power is applied. Workaround: "When hot-swapping DC PSUs on BIG-IP 10000-series or 12000-series appliances, verify the success of the operation by: 1. Verify that the front panel PSU LED for the newly inserted PSU is Green. 2. Verify that the status of the newly inserted PSU is reported as Good by the 'system_check -d' or 'tmsh show sys hardware' utilities."
ID 474002 If a BIG-IP virtual server is configured with a Server SSL profile, and a pool member or server selects a DHE-based ciphersuite (e.g. DHE-RSA-AES128-SHA), the BIG-IP system might not successfully complete an SSL handshake with the server. This occurs when the following conditions exist: - HTTPS Pool member or server. - Virtual server with Server SSL profile. - Server is configured with 2048-bit or larger Diffie-Hellman keys. Traffic to affected pool members fails, although the pool members are marked up by HTTPS monitors. Workaround: Either disable the use of ephemeral Diffie-Hellman (DHE) key exchange on the backend servers, select a smaller set of DH parameters on the backend servers, or disable DHE ciphersuites in affected virtual servers' Server SSL profiles.
ID 474149 SOD posts benign error message: Config digest module error: Traffic group device not found In a failover device group, if the peer device (non self device) has gone through the management IP address change, SOD fails to clean the old IP address from its internal storage, so the system subsequently and incorrectly behaves as if there is a 'configuration data inconsistent' error. System posts the benign message notice sod[8118]: 010c0062:5: Config digest module error: Traffic group device not found. Workaround:
ID 474179 SOAP monitors configured with a leading ':' in the URL path will fail. Enabling monitor debug will provide additional clues, indicating "Error calling getaddrinfo". SOAP monitor configured with leading ':' in the URL path. Monitor will fail unconditionally. Workaround: "A leading ':' in a URL path is now allowed by RFC 3986, section 3.3. If the URL path is, in fact, a colon, then a leading slash should work (i.e. ""/:""). If your URL path leads with a colon, you need to either escape the colon, or need to add a leading slash."
ID 474323 IPv6 full hardware acceleration with ePVA feature is disabled in the v11.6.0 release. An issue was uncovered in the Aluminum bitstream that results in Flow Status Updates (FSUs) due to a collision eviction being corrupted in certain cases. This occurs when the flow cache entry being evicted and the incoming snoop are different sizes. In the Aluminum design, the IPv4 and SYN VIP flow cache entries and snoops are the same size, and the IPv6 flow cache entries and snoops are larger than IPv4/SYN VIP. There are no FSU-related issues when a cache entry is evicted due to a collision by a same size snoop, and there are no issues when an eviction is explicitly requested by software via the evict opcode. Cannot enable full acceleration for an IPv6 VIP. Workaround:
ID 474388 Certain conditions might produce error messages similar to the following, in the core file/tmm.log: -- RVAvpBigIP01 notice RIP=0x8cc872 -- RVAvpBigIP01 notice session_process_pending_event_callback ERROR: could not send callback to 192.168.96.27:50441 - 192.168.96.28:443 ERR_NOT_FOUND. This occurs because of a race condition, for example, one between the HTTP and APM-related profiles during which an APM-profile-related action completes after the HTTP-profile closes the connection. When the APM profile attempts to access the closed connection, TMM restarts. Workaround:
ID 474797 "If malformed SSL packets are sent to Big-IP, the following errors can be logged to /var/log/ltm: Device error: cn9 core general crypto codec cn-crypto-4 queue is stuck." Malformed SSL packets being set to Big-IP. Error logs in /var/log/ltm. Workaround:
ID 474983 "This issue occurs when issuing the 'tmsh show ltm virtual' command - if the connection limits of a pool member have been met, issuing the command above does not reflect the status. The work around is to refresh the pool member status by executing 'tmsh show ltm pool <name> member', or by viewing through the GUI. Please note that the TMM does the correct behavior in traffic processing, and this is just a visibility issue in TMSH." Requires a pool member whose connection limits have been met. Please note that the TMM does the correct behavior in traffic processing, and this is just a visibility issue in TMSH. Workaround: The work around is to refresh the pool member status by executing 'tmsh show ltm pool <name> member', or by viewing through the GUI.
ID 475346 Under this deployment, it can be proved that traffic flows from the server through the LTM to the client, when the expected behavior would be not to complete the SSL handshake in the server side. "The server SSL profile property ""expire-cert-response-control"" is not honored. Specifically: 1. A virtual server is deployed with a SSL server profile. Such profile is configured to request a server certificate, don't drop the connection if the certificate is untrusted, but drop it if the certificate has expired. 2. A SSL server is configured with a self-signed, expired certificate, and that SSL server is added in the pool where the Virtual Server with the described server ssl profile is pointing to." since the certificate is expired, the SSL handshake should be dropped on the server side. Workaround: "renew certificates ahead of expiration to avoid this problem if certificate is expired, update as soon as possible."
ID 475525 Connections fail to pass data and may be reset unexpectedly. "This can occur when the following conditions are met: - Virtual uses OneConnect profile. - Virtual uses serverssl profile with unclean-shutdown disabled. - Backend pool member generates an ssl/close_notify alert but does not send a tcp/fin." Connection loss. Workaround: Disable OneConnect profile.
ID 475791 Ramcache profile might dispatch internal messages out-of-order, leading to assert. "Assert may occur when the following conditions are met: - Virtual server uses ramcache profile. - Virtual server has mirroring enabled. - Device is in standby mode. - Active unit is unable to fulfill incoming HTTP request (ramcache entry is invalid / no pool members). - Standby unit is able to fulfill mirrored request (ramcache entry is valid)." Due to this rarely occurring race condition, a tmm_panic occurs ('valid pcb') when a connection is being closed and the ramcache feature is able fulfill an incoming request. Standby unit becomes temporarily unavailable. Workaround: Do not use ramcache profile and connection mirroring feature together.
ID 475896 "Running the following command does not work: load sys config from-terminal sys file external-monitor ext_monitor { source-path ... }" This occurs when running the command 'tmsh load /sys config from-terminal' external-monitor. The system posts the following error: Failed: name (/Common/<name>) cache path expected to be non empty. This error prevents using cut and paste to configure external monitors. Workaround:
ID 476136 On VIPRION B2250 and B4300/B4340N blades, you might encounter log entries of this type: notice HA: ha_enabled_put(daemon_heartbeat, tmm, FALSE): error 01140012 or notice HA: ha_enabled_put(daemon_heartbeat, tmm, TRUE): error 01140012. This occurs only on VIPRION B2250, B4300, B4340N blades. The system posts the error messages. These messages are benign and can be safely ignored. Workaround:
ID 476218 If the ePVA drops an evict command, then a flow can be orphaned in the ePVA. This could result in an increase in hash collisions, due to more space occupied in the ePVA by orphaned flows. guaranteed mode hash collisions and orphaned flows Workaround:
ID 476398 The TCP profile options Receive Window and Send Buffer are not used. TCP profile has Mptcp, Rate Pacing, or Limited Transmit Recovery enabled, or congestion algorithms illinois, woodside, westwood, cdg, chd, cubic, or vegas are selected. This prevents configuring these settings. Workaround: TCP Auto Tuning can be disabled by modifying a sys db variable. tmsh modify sys db tm.tcpprogressive.autobuffertuning value disable.
ID 476544 mcpd runs out of memory when a connection's send message queue has a lot of messages in it. The connection's m_current_msg_byte_cnt is high, but does not account for the entire 2GB virtual memory space. mcpd runs out of memory when a connection's send message queue has a lot of messages in it. The connection's m_current_msg_byte_cnt is high, but does not account for the entire 2GB virtual memory space. mcpd cores and restarts if it runs out or memory. Workaround:
ID 476708 In a very specific mesh network configuration as shown in the SR, BGP does not correctly update TMOS when a ECMP path that had become unavailable comes back up. Using the mesh network topology in this bug, disable the downstream ECMP link such that one of the two equal cost paths becomes unavailable. Then re-enable the downstream ECMP link. ECMP does not function as desired because both available paths are not utilized. This can only be recovered by clearing the BGP connection on the affected ECMP path. Workaround:
ID 476920 RESOLV::lookup does not resolve if route domain is not given as part of ip address%<route domain> ip address is not given with %route domain id. Need to explicitly provide the route domain id Workaround: Provide the route domain id explicitly with the ip address.
ID 477232 When using a LSN pool with persistence mode address, in addition to reusing the same translation address for subsequent connections, the translation port also persists and is reused. LSN pool with persistence mode address. Poor utilization of available translation ports and very high levels of port reuse. In the case of TCP connections this port reuse can cause servers to reject connections because a previous connection is in the TIME_WAIT state. Workaround:
ID 477375 Rarely, the SASP monitor cores. This occurs when the SASP monitor is configured in push mode. When the monitor cores, a pool member gets marked down, which might lead to an outage. This occurs rarely. Workaround:
ID 477705 The 'untrusted-cert-response-control=drop' command is not honored. This occurs when the following conditions are met: virtual server is deployed with a SSL server profile that is configured to request a server certificate and drop the connection if the certificate is untrusted. The ssl handshake is not properly dropped. Workaround:
ID 477742 The DTLS message sequence number is incorrect. SSL over UDP (DTLS) is configured. Incompatibility with some SSL clients. For example the OpenSSL1.0.1j. It works fine with old OpenSSL version. Workaround:
ID 477786 Depending on the release, sending a SYN packet to a self IP address with Port Lockdown set to Allow None might respond to the SYN with a RST packet, or might silently drop the SYN. "With Port Lockdown configured to Allow None, the LTM behaves differently upon receiving a SYN packet. In 11.3.0 and 11.4.1, when receiving a SYN packet the LTM replies with RST. In 11.4.0, 11.5.1, and 11.6.0, when receiving a SYN packet the LTM does not reply (sends a REJECT)." Inconsistent behavior based on version, sometimes RST in response to SYN on closed port, and sometimes nothing (REJECT). Because the traffic is not allowed in either case, there is no fundamental impact. This is primarily a behavioral difference between releases. Workaround:
ID 477967 tmm segfaults when attempting to apply TSO processing to an outbound packet that does not need it. Occurs when applying TSO to packets. tmm crashes and the system fails over. Workaround:
ID 477992 The log is never created. Error messages in /var/log/ltm stating the log file cannot be opened. Create pool members via an iApp, and attempt to enable logging on the pool member. No logging, error messages. Workaround: If logging is required, bigdlog is also available: 'tmsh modify sys db bigd.debug value enabled'.
ID 478920 SIP::discard is invoked only for the first 2 request messages and the other request messages are allowed to pass through. "The following iRule is present and the iRule is not invoked for all the request messages. when SIP_REQUEST { SIP::discard }" iRule is not invoked for all the SIP messages Workaround:
ID 478922 "Attempting to turn on ICSA logging for non-ESP packets will lead to the following logs. Aug 21 10:47:17 2000a info tmm1[10347]: 01070417:6: ICSA: source: %A, destination: %A, spi: 0x%x, seqno: 0x%x ESP packet discarded: ""inbound""" "ICSA logging for is enabled. Connections are sent through the BIG-IP. Logs similar to the following are found in /var/log/ICSA Aug 21 10:47:17 2000a info tmm1[10347]: 01070417:6: ICSA: source: %A, destination: %A, spi: 0x%x, seqno: 0x%x ESP packet discarded: ""inbound""" ICSA logging misses information that is required for certification. Workaround:
ID 478986 When power is removed from the PSU but the PSU remains in the system, 'tmsh show sys hardware' reports the PSU as 'not-present'. This occurs when an installed DC powered PSU loses power, and the user runs the command 'tmsh show sys hardware'. Only the message is incorrect. Although the PSU is present, the system cannot read its data without power, so the system marks the PSU 'not present'. Once power is restored, all information is available. Workaround: Plug the power cable into the PSU. The system can now detect the power supply status and read the PSU info.
ID 479129 TCP window scaling is not applied, which can be observed in transmitted packets containing small segments that are about the size of the unscaled window. SYN cookies have been activated. Poor performance / throughput. Workaround:
ID 479176 The TMM attempts a DNS db load while starting. This is a potential race condition that might occur intermittently after the restart. One thread hangs indefinitely and tmm receives a SIGABRT after a period of time. Workaround:
ID 479262 The 'readPowerSupplyRegister error' is logged in LTM log when DC PSU loses its power. When a DC powered PSU loses its power, 'readPowerSupplyRegister error' will be logged into LTM log, because PSU data is not available without power. Cosmetic. Erroneous LTM messages. Workaround:
ID 479670 If a licensing operation happens when the VCMP host and a guest have different blades as primary, then the status may show the incorrect number of downed links. Cosmetic. Workaround: Ensure that the host and guest have the same blades as primary.
ID 480686 On an active VIPRION or vCMP guest with a VLAN Group configuration, the CPU usage unexpectedly rises, and traffic flowing through the device may experience high latency and packet drops. A packet capture shows packets looping internally between VLAN members of the VLAN Group. This occurs when using a VLAN Group (in Translucent or Transparent mode) on VIPRION hardware (including vCMP guest of a VIPRION), and an IP address conflict exists between the BIG-IP and another device on the VLAN Group. Note: The device causing the IP conflict may be unrelated to packets that are found looping in a packet capture. This results in high CPU usage and potentially unresponsive GUI. Traffic flowing through the VLAN Group may experience high latency and packet drops. The Self IP on the affected VLAN becomes almost impossible to reach. Workaround: Disable vlangroup.flow.allocate db variable to prevent flow creation for vlangroup forwarded packets.
ID 481001 Software auto update settings are not synced between two devices in a sync group. Perform a full sync with systems that have different auto-update settings. This can lead to software auto update settings not being consistent across two devices. Workaround:
ID 481216 After an Early Server Response, the BIG-IP system might attempt to generate a fallback response if an error occurs. However, the response has already partially egressed, so this does not work correctly. Fallback configured or enabled by an iRule. An early server response triggers an error that leads to an Abort being raised. The Abort triggers a fallback response inappropriately. The server-side might read HTTP data structures after they have already been freed. A fallback can be generated on the server-side, leading to a use-after-free if the client side has already aborted.
ID 481082 After performing a full sync, the auto update settings of the target machine are reset to defaults. Perform a full sync with systems that have different auto update settings. Auto update settings can get out of sync, and be incorrect. Workaround: After a full sync, ensure that the auto update settings on both systems are set as desired.
ID 481089 After performing a full sync, sometimes the BIG-IP systems remain out of sync. A full sync must be performed. There must be more than one active connection to mcpd, and one of them must get disconnected before the sync completes. The BIG-IP systems remain out of sync even after a sync operation Workaround:
ID 481138 duplicate IS-IS routes in router IS-IS routing duplicate IS-IS routes in router Workaround:
ID 481162 The vs-index field on virtual servers should be the same on every blade, but is not. This applies on any chassis. Workaround:
ID 481647 The OSPF daemon might assert if receiving a Link Status (LS) Update header with a length greater than 255 bytes. This occurs when the LSA header length is greater than 255 bytes in length. OSPF daemon asserts and generates a core, which might cause a service outage. Workaround:
ID 481696 You might see a failover error message 'sod out of shmem' in /var/log/ltm. The conditions under which this occurs vary based on the configured shared memory usage. Failover might not function fully. System posts the message 'err sod[6300]: 01140003:3: Out of shmem, increment amount' in /etc/ha_table/ha_table.conf. Workaround: Manually modify /etc/ha_table/ha_table.conf as follows: Change this line: 'ha segment path: /sod table pages: 2' to this: 'ha segment path: /sod table pages: 4'. Save the file and reboot the system.
ID 482204 Attempts to modify the ssh daemon logging level have no effect. The log level is always "info" (the system default). "Modify sshd log-level. For example, even after the following operation, sshd will continue to log info-level messages. # tmsh modify /sys sshd {log-level error}" Users are unable to filter ssh logs. Workaround:
ID 483228 A race condition in the terminate handler of the icrd_child process causes it to crash and generate core. Intermittent. No functional impact. Workaround:
ID 483353 TMM may crash in HTTP compression in low-memory conditions when unable to initialize the compression provider. HTTP compression is configured and TMM is low on memory. TMM crashes and traffic outage may occur. Workaround: Remove HTTP compression from the virtual to avoid the issue.
ID 483539 "Due to the incorrect MSS value, TMM might core because based on the MSS value the outgoing packet attempts to use TSO, which is not correct. This can result in a crash with the following stack trace: #2 <signal handler called> #3 tcp_tso_pkt_cleanup at ../netinet/tcp_tso.c:136 #4 tcp_tso_split (orig_pkt=0x570001574680) at ../netinet/tcp_tso.c:487 #5 nexthop_tso_output (nexthop=<value optimized out>, orig_pkt=0xe) at ../net/nexthop.c:395 #6 flow_output (cf=0x5700010c0700, pkt=0x570001574680) at ../base/flow_table.c:1861 #7 bigproto_output (cf=0x5700010c0700, conn=0x218, pkt=0x570001574680) at ../modules/hudproxy/bigproto/bigproto.c:3035" A virtual using fastL4 where a SYN packet with options is received, but the SYN packet does not contain an MSS option. If this issue occurs, then TMM will core resulting in a failover/reboot of the system. Workaround:
ID 483953 When traffic has an apparent path MTU of less than TM.MinPathMTU, LTM will insert a route metric entry of TM.MinPathMTU. This entry does not benefit the eliciting endpoint in any way. Worse, the entry is to the detriment of other clients ("behind" the same address) which might benefit from a higher MTU. A low-MTU endpoint is present on network. LTM may enforce a suboptimal MTU. Workaround:
ID 484542 tmsh does not validate QinQ tag-mode and allows invalid values to be set. User sets QinQ tag-mode to non-'none' value on unsupported platform None Workaround:
ID 484683 The other Peer of HA-Pair can not show the summary of cert-chain by "tmsh run sys crypto check-cert verbose enabled" after config-sync. "1. Setup HA Pair 2. Import Certificate chain to one BIGIP 3. ""run config-sync"" to sync the Certificate chain to peer BIGIP." The other Peer of HA-Pair can not show the summary of cert-chain by "tmsh run sys crypto check-cert verbose enabled" after config-sync. Workaround: "Copy the cert-chain file to a place(such as /shared/tmp/), and update the cert-chain using: ********************************************************* root@(eng-3900A)(cfg-sync In Sync)(Standby)(/Common)(tmos)# modify sys file ssl-cert Cert-Chain_Browser_Serv.crt source-path file:/shared/tmp/Cert-Chain_Browser_Serv.crt_58761_1 *********************************************************"
ID 485189 TMM might crash and generate a core if unable to find persistence cookie. Although specific conditions for this issue are unknown, it is possibly due to having a virtual with cookie persistence enabled and iRules that disable persistence. System outage. Workaround:
ID 485232 After re-enabling a blade, it does not go active even though its mate blade is active. HA group scoring must be used, and the HA scoring must be weighted equally among peers. The peer must have its blades enabled. The standby blade does not take traffic. Workaround: Fail the system over to the peer by disabling its blades, then enable them and fail back (if desired).
ID 485327 "By default the tmsh cli global settings service value is name. That implies that for a user configuration, the ports are saved by their names and not port numbers." This occurs when upgrading. Loading a UCS configuration with port names fails on an upgrade if the port name is not present in /etc/services in the upgrade version. The failure message appears similar to the following: The requested value (*:hosts2-ns }) is invalid (<ip addr> | <member>) for 'dest' in 'monitor'. Workaround: Run the following tmsh command prior to saving the ucs file. (tmos)# tmsh cli global settings service number. The config will then load successfully on an upgrade.
ID 485432 When you change the management port's subnet, existing static routes with now topologically unreachable gateways will be removed. Routes exist on gateways that will not be on a local subnet after the mgmt port takes on a new network address configuration Services critical for operation such as NTP, SNMP, SMTP and Log Targets may become unreachable to the BIG-IP system although reconfiguring the mgmt port does not generate a warning. Workaround: Configure static routes with gateways that are within the local subnet of the mgmt ports addressing
ID 485702 If the SNMP default community (public) has been removed from the configuration, and a new version of the software is installed, the default community will be added to the new configuration. The bug is currently fixed in the BADGER (v12.0.0)release Workaround: After upgrading to versions >= 11.4.0, delete the default 'public' community again.
ID 485714 "The bigd process will go into a restart loop, with the following log message in /var/log/ltm: Fatal error: An unexpected failure occurred while performing an OpenSSL cryptography operation. Root error: 10219:error:0606506D:digital envelope routines:EVP_DecryptFinal_ex:wrong final block length:evp_enc.c:323:" This issue occurs when there is an encrypted password on a monitor. The bigd process will restart. Workaround: Enter the plaintext password in the Monitor UI page.
ID 486512 Forwarded auditing messages contain the incorrect nas-ip-address attribute. It should be the local IP of the box, instead it's some other random IP address. This seems to work fine when the BIG-IP is a VM. Only reproduces on hardware. Cannot pass certification because config auditing is not working properly (invalid NAS IP Address). Workaround:
ID 486722 The default config-sync timeout is 300 seconds. This time is not sufficient when configuration includes 1000s of FIPS keys. Config-sync operation times out and reports failure. FIPS HA setup and 1000s of FIPS keys in the configuration. config-sync fails Workaround: Follow steps in 'Fix Text' to increase timeout value.
ID 486735 The statistics for maximum connections can be higher than it should be. This occurs when the load disaggregated to the available TMMs in not even, so that different TMMs measure their individual maximum connections at significantly different times. The maximum connections appears greater than it should be. Workaround: Ensure the configuration matches the traffic so the load of connections is evenly distributed across all TMMs.
ID 487625 Manually corrupting the filestore will cause qkview to hang. Workaround:
ID 487660 LSN Translation failures in persistence mode when there is an SPDAG VLAN hash. Persistence mode set in LSN pool when there is an SPDAG VLAN hash. Translation failures. The system posts an error similar to the following: debug tmm9[25268]: 01670012:7: [0.9] Translation failed client 200.200.200.101,10096. Workaround: Over-provision the LSN pool.
ID 487795 Front panel port Ethernet TX pause is currently disabled for the following platforms: B4200, B4300, B2100, B2150, B2250, 5000-series, 7000-series, 10000-series, 11000-series, and 12250. This occurs on the B4200, B4300, B2100, B2150, B2250, 5000-series, 7000-series, 10000-series, 11000-series, and 12250 platforms. Front panel Ethernet TX pause flow-control non-functional. Workaround: None.
ID 488124 "What happens is during hsb receiving packet processing hsb_fast_rx(), the xfrag given by the receiving descriptor is not valid. This results in a seg fault and core dump. <13> Apr 27 14:50:34 slot1/CNCRCAGPLB04 notice panic: ../kern/xbuf.c:2273: Assertion ""valid xfrag"" failed. <13> Apr 27 14:50:36 slot1/CNCRCAGPLB04 notice panic: ../kern/xbuf.c:2273: Assertion ""valid xfrag"" failed. We have not been able to reproduce this failure in any conditions. We have tried to reproduce this on several platforms, including direct RMA equipment that showed this issue." unknown. This has happened across several platforms and blades at several customers over the years. Low impact so far. We generally see a failure like this 3-4 times a year across all platforms. Workaround:
ID 488462 Server-initiated banner protocols can stall connections. If 'verify accept' is set on the TCP profile, the virtual server contains a clientssl profile, and the server side sends a banner message, the connection might stall. This occurs when 'verify accept' is set on the TCP profile, and the server sends a banner message. The connection stalls. Workaround: Do not enable 'verify accept'.
ID 488581 'SSL::disable clientside' inside HTTP_REQUEST might cause tmm core with a SIGSEGV if crypto is in progress when the iRule makes the request. This occurs in iRules that contain 'SSL::disable clientside' inside HTTP_REQUEST and crypto is in progress when HTTP_REQUEST occurs. TMM dumps a core file and the system fails over. Workaround: Do not put 'SSL::disable clientside' inside HTTP_REQUEST.
ID 488876 In releases prior to 11.4.0, SSL persistence used very little memory. Beginning in version 11.4.0 and continuing, the amount of memory has increased. This occurs when SSL persistence is enabled. This results in less memory being available for other flows, and might eventually result in TMM being out of memory. Workaround:
ID 488921 BIGIP sends unnecessary gratuitous ARP's for its virtual IP's and self IP's When the virtual server status transitions from online to offline status or viceversa BIGIP sends out a large number of unwanted gratuitous ARP's if the the virtual server changes its status rapidly. If devices connected to BIGIP have rate limit's configured on them, they may start ignoring the ARP's sent by BIGIP and miss the critical gratuitous ARP's sent by BIGIP on a HA failover. This could break the BIGIP HA functionality. Workaround:
ID 489015 "An LTM request-log profile that references a non-existent pool can pass validation in 11.1, but fails beyond 11.2. This can cause a load fail when rolling forward the configuration. Other possible affected classes are: DNS Zone, iFile, SSL profile, and Auth configuration." Workaround:
ID 489113 "When affected versions of BIG-IP are running on VIPRION B2250 blades, the PVA status and statistics are not displayed correctly (missing entirely) from the user interface. For example: # guishell -c 'select name,has_pva,pva_version from platform' -------------------------------- | NAME | HAS_PVA | PVA_VERSION | -------------------------------- | A112 | false | | <<< incorrect -------------------------------- # tmsh show ltm virtual ------------------------------------------------------------------ Ltm::Virtual Server: vs1 ------------------------------------------------------------------ Status Availability : unknown State : enabled Reason : The children pool member(s) either don't have service checking enabled, or service check results are not available yet CMP : enabled CMP Mode : all-cpus Destination : 30.30.30.1:80 <<< missing 'PVA Acceleration' item" VIPRION B2250 blades running affected versions of BIG-IP. "PVA appears to be disabled/unavailable. PVA statistics are not available. PVA functionality is actually enabled and operating in the data plane." Workaround:
ID 489514 LTM sends FIN to client side SSL connection (proxy-buffer reached?) when the server side connection has already been closed "Exceed proxy buffer size on client side after the server side connection has already been closed Impact - download does not complete" when doing queries on very large amounts of data, the proxy buffer fills up, then the tcp filter buffer fills up and the data get truncated with an browser errors that it is unable to understand the code. The logs show a error of S>CShort record Unknown SSL content type XX", Workaround: "increase proxy buffer failover to newly activated LTM or reduce the query or directly connect to pool member"
ID 489732 With a 4300/4340 blade, 40 GB bundled interface (four 10 GB interfaces) connected to a Brocade switch, the interfaces remain down after a reboot. This occurs when connecting a 40 GB bundled interface on a 4300/4340 blade to a Brocade switch. Interfaces remain down, causing loss of connectivity. Workaround: Disable and then re-enable the affected interface on the BIG-IP system.
ID 489865 "The bd process on standalone ASM was coring frequently This is an LTM issue, related to the encryption of multiple cookies." "v1 Plugin infrastructure can only support headers up to 64K size 1. Attach the cookie decrypt / encrypt irule from the customer's bigip.conf. 2. Put up a simple netcat server that sends a response with a 60k cookie. Point a pool node to that server. 3. change the http profile setting to increase the max http header. The crash happened when sending a request. this is a memory corruption issue." standalone ASM, and the bd cores were resulting in frequent traffic disruptions Workaround: removed an iRule (/Common/iRULE-ENCRYPT-HTTP-COOKIES) from several virtual servers, which was effective in stabilizing the unit.
ID 490121 PVA current and maximum stats are incorrectly reported when using a fastL4 profile with a SERVER_CONNECTED iRule event. For each connection that is established, the current connection count is incremented twice and decremented only once when the connection is terminated. This leads to a lingering connection, which skews the stats. A fastL4 virtual with a SERVER_CONNECTED iRule event. The current and maximum PVA stats are incorrectly reported. Workaround:
ID 490139 Loading iRules from the iRules file deletes last few comment lines immediately preceding the closing bracket. This occurs when loading an iRule file from versions prior to 11.5.1. Although the comments are removed, this does not affect iRule functionality. Workaround: Put comments in places other than immediately above the closing bracket.
ID 490329 Front panel LED status of a SFP+ pluggable module interface may show link when only the RX fiber of LC duplex cable is connected. Workaround: Fully connect both RX and TX fibers of a LC duplex cable to a SFP+ pluggable module.
ID 490860 Fraud Protection Services does not support the Firefox web browser versions 15 and earlier. Workaround:
ID 491030 Sometimes when encrypting certain SSL records, the Nitrox crypto accelerator can hang with the LTM log message "request queue stuck". Certain SSL records. Nitrox crypto accelerator can hang. Workaround:
ID 491518 SSL [session id] persistence might prematurely close (FIN) a TCP connection before forwarding all data. SSL persistence must be in use. A slow client side (WAN) exacerbates the issue. Premature close of TCP connection and potential data loss. Workaround: Disable SSL persistence.
ID 491717 Running the command 'eud_log' on a BIG-IP 7000 series and 10000 series platform produces the following output: -- info: No EUD log found in /var/tmp. Searching boot volume -- info: No eud.log found on sda.dat.boot. This occurs on the 7000 series and 10000 series. This message indicates that eud.log file cannot be detected in the incorrect directory /var/tmp. However, the file does exist in the /var/log directory, which is the correct directory. Workaround:
ID 491771 "A proc exists and is called from a rule, and the proc contains a ""catch"" block with a parking command like those in sideband, table, session or RESOLV::lookup. Tmm cores with panic: TclExecuteByteCode execution failure: end stack top < start stack top" tmm cores Workaround: Move "catch" statement outside of proc into body of script.
ID 491791 Performing a GET on nonexistent pool members does not show an error. This occurs when using iControl REST with nonexistent pool members. The returned response typically indicates an almost-empty resource instead of a not-found error. Workaround: Use members GET for all members and iterate through the items returned to determine if a pool member exists.
ID 491894 A sync group may go red and log an sync error while a full sync is still in process. Unknown The state of the sync group goes red momentarily and a log is produced, however the sync eventually succeeds. Workaround:
ID 492329 In at least two releases (11.4.1-hf5 and em v3.1.1-hf3) customers have submitted cores that resulted from a double free. The stack trace is as reported in the bug, but it is not known how to reproduce the conditions that lead to this state. Unknown. "As stated in the bug: mcpd restarts, resulting in either a failover or an outage." Workaround:
ID 492422 HTTP request logging reports 200/OK response code before any response has been received. HTTP request logging enabled. Misleading messages in the logs. These messages are benign and can safely be ignored. Workaround:
ID 493117 After changing the netmask of an advertised virtual address, the address is no longer advertised. Must have an advertised virtual address, and change its netmask. tmrouted must be restarted whenever the netmask of an advertised virtual address is changed. Workaround:
ID 493558 TMM cores with 'sack scoreboard population counts valid' assert. The TMM core occurs due to lost-packet retransmitted packet value mismatch. This occurs when processing retransmitted packets configured for selective acknowledgement (SACK), when multipath TCP (MPTCP) and selective negative acknowledgement (SNACK) are enabled with a SNACK-supporting client. Traffic disruption might occur. Workaround: There are two possible workarounds: -- Disable MPTCP. -- Disable the SNACK option in the TCP profile.
ID 493807 TMM might crash when using PPTP with profile logging enabled. This occurs when the following conditions are met: -- PPTP-ALG with log profile enabled. -- CGNAT configured. TMM might crash, resulting in disruption to traffic. Workaround: Disable logging from the PPTP profile.
ID 493950 Virtual Server with unmatched context settings in a profile might block upgrade. This occurs when there is a virtual server configured with a TCP, UDP, or SCTP profile set with either (context clientside) or (context serverside), but without a corresponding profile with the other proxy side (serverside or clientside, respectively). Cannot upgrade and roll-forward a configuration, and the system might post the following error message: 01070734:3: Configuration error: Less than the required minimum number of profiles found on /Common/test-vip5: At least 1 Of but Not more than 1 Of (UDP Profile, TCP Profile, SCTP Profile) There are 2 workarounds: 1: Before upgrade, modify the existing configuration, by either removing the (context) line or by adding the corresponding context, and then saving the UCS file. 2: After a failed attempt to load the UCS file, manually modify the UCS file as described in workaround 1., and then load the file again.
ID 494019 System matches to previous Diameter Route Application ID after modifying the application ID value. This occurs after modifying the application ID value for a Diameter Route object. The Diameter Route might continue to match Diameter messages against the old application ID until tmm is restarted. Workaround: Always restart tmm after changing the value of application ID in a Diameter Route.
ID 494035 "We officially release session ticket feature in 11.4.0 although 11.3.0 includes partial of the session ticket code. We disable session ticket in SSL backend. That means, customers can enable session ticket from GUI, TMSH and iControl, but SSL will ignore it and always think session ticket is disabled." session ticket feature in 11.3.0 This could confuse customers, we should disable session ticket from user interface (GUI, TMSH, SNMP and iControl). Workaround:
ID 494120 iRule 'virtual' command allows for protocol mismatch. A virtual server with an iRule which leverages the 'virtual' command targeting a virtual server that differs in protocol. For example, a UDP virtual server targeting a TCP virtual server. tmm might crash with assert: 'Must be syncookie'. Traffic is interrupted. Workaround: This is the result of a misconfiguration. Modify iRules to ensure L4 protocols match between virtual servers.
ID 494322 If the flow inside a HTTP_REQUEST event raised by the explicit proxy is expired, the TMM may crash. The explicit proxy is configured for HTTP, and the HTTP_REQUEST iRule event is used. If state-changing commands are used within the HTTP_REQUEST event raised by the explicit proxy, they may not work correctly, and TMM might crash.
ID 494367 "HSB lockups can occur after a HiGig MAC reset on Whitethorne platforms. This is indicated by the following in the LTM log: Nov 16 10:05:34 bcm56xxd[8161]: 012c0015:6: Link: 4.1 is DOWN Nov 16 10:05:34 bcm56xxd[8161]: 012c0012:6: Reset HSBe2 (bus 1) HGM0 MAC completed on higig2 link 4.1 down event. Nov 16 10:05:35 bcm56xxd[8161]: 012c0015:6: Link: 4.1 is UP ... Nov 16 10:05:44 tmm2[13842]: 01230111:2: Interface 0.3: HSB DMA lockup on transmitter failure." It's unknown as to the condition that leads to this failure. An HSB lockup results in a NIC failsafe and reboot of the unit. Workaround:
ID 494452 When a response-adapt profile is applied to a virtual server, BIGIP FINs the connection to the server/client before NTLM authentication is fully negotiated, causing NTLM authentication to break. A virtual server configured for NTLM authentication uses a response-adapt profile. NTLM authentication does not work. Workaround:
ID 494732 Even if the first matching static route is no longer able to route traffic, the Router will continue to send traffic using this bad route rather than automatically selecting an alternate route. If the highest priority static route for a Diameter Router Profile is not able to pass traffic because the route's associated nodes are down, the Router continues to use the route. No Diameter traffic is passed for a Diameter Router Profile whose primary static route has no routable nodes. Workaround: "To switch to using one of the other static routes and get traffic passing again, edit the Diameter Router Profile so that the down route appears at the end of the list in the configuration. The order of this list determines the priority order of route selection. If a route is placed at the end of the list, it can only be selected if there are no other matching routes."
ID 494815 "Some iControl REST DELETE calls fail. These are the calls equivalent of the following tmsh commands (known ones) - tmsh delete ltm dns cache records <cache-type> type <record-type> cache <cache-name> tmsh delete ltm clientssl ocsp-stapling-responses clientssl-profile clientssl virtual <virtual> The equivalent iControl REST calls - # curl -sk -u <user>:<pwd> -X DELETE https://localhost/mgmt/tm/ltm/dns/cache/records/rrset?options=cache,<cache-name> fail with the following error - {""code"":400,""message"":""Query parameter options is invalid."",""errorStack"":[]}" always. Unable to delete certain config objects (most likely some records or cache entries that are not direct config objects). Workaround:
ID 494987 If `dont-insert-empty-fragments' is removed from the server ssl profile, the connection might hang and fail. dont-insert-empty-fragments is removed from the serverssl profile The server ssl connection can hang and fail. Workaround:
ID 495215 "Attempting to add a Device Management Peer results in either of the following errors: 01020036:3: The requested device (/device1) was not found. Or get_local_device: Exception caught in Management::urn:iControl:Management/Device::get_local_device() Exception: Common::OperationFailed" "This only occurs with the admin account in iControl SOAP after setting the active folder to one that is not partitioned (such as '/'): System.Session.set_active_folder('/')" The user is not able to add a peer device to the trust domain. Workaround: "Use an iControl SOAP client to call the following using the admin account: System.Session.set_active_folder('/Common')"
ID 495242 The system posts the following message in the mcpd log: Failed to unpublish LOIPC object. This is an intermittent issue that occurs on standby systems in High Availability configurations. In this case, the system is attempting to remove a file/directory that does not exist. Either it has already been removed or it was not created. The system posts the following error: err mcpd[7143]: 010716d6:3: Failed to unpublish LOIPC object for (loipc_lb-zoc_http.1417443578.297505208). Call to (shm_unlink) failed with errno (2) errstr (No such file or directory). This is a benign error that can be safely ignored. Workaround:
ID 495574 TMM restarts continuously. DB monitors configured System stops responding. System posts message: notice panic: FATAL: mmap of: /dev/mprov/tmm/tmm.4 length 1480589312 offset 4441767936 failed 12 (Cannot allocate memory). Workaround: Either kill the DB monitor java process or issue a bigstart restart.
ID 495588 Configuration fails with Syntax Error after upgrading from pre-11.5.0 releases. When upgrading from a pre-11.5.0 release to version 11.5.0 or later, the key/cert have an extra period in the name (for example mykey..key and mycert..crt). Beginning with version 11.5.0, multiple key/cert pairs are associated with one clientssl, so each key/cert pair has a name. During upgrade, the system provides a name for each key/cert, which can cause problems if the existing key/cert name contains a period character. Configuration load fails, and the system posts the alert: Syntax Error:(/config/bigip.conf at line: 12) one or more configuration identifiers must be provided. Workaround: Manually edit the bigip.conf to add a title for the cert-key-chain, and then run the command: tmsh load sys config.
ID 495862 Virtual monitor status becomes yellow and get connection limit alert when all pool members forced down. Virtual status reason displays as 'The pool member's connection limit has been reached'. When all pool members forced down and the pool member's connection limit has been reached. Invalid display of virtual status. Workaround:
ID 495875 tmm might experience an infinite loop when selecting an available node for load balancing under heavy traffic conditions. This occurs when connection limit is specified for nodes, and there is heavy traffic. This causes a 10-second tmm heartbeat failure and a SIGABRT in tmm. The device goes offline and traffic processing is disrupted. Workaround:
ID 496369 Performance degradation on some VE instances, but not on others. This occurs on VE instances that are set up for spanning NUMA domains. Performance is negatively impacted. Workaround: Ensure the hypervisor disables NUMA spanning on the VE guest. Specifically, restrict the VE instance to a set of cores with direct memory controller attachments. This is typically done via NUMA controls, which vary by hypervisor. For instructions on disabling NUMA spanning, see your hypervisor documentation.
ID 496788 MPI failures and a slow failover are observed when Cavium devices, which were attached and used by TMM, becomes unavailable. Workaround:
ID 497304 "When deleting an HTTP iApp, one sees errors similar to this in the ltm log, along with similar sync errors in the GUI: Oct 16 14:41:13 cr-ltm-mc err mcpd[6629]: 01070265:3: The HTTP Profile (/Common/http-test-farm1.app/http-test-farm1_http) cannot be deleted because it is in use by a sflow http data source (16). Oct 16 14:41:14 cr-ltm-mc err mcpd[6629]: 01071488:3: Remote transaction for device group /Common/HA_Group to commit id 895 6070871290648001573 /Common/cr-ltm-bb2.ns.uwaterloo.ca 0 failed with error 01070265:3: The HTTP Profile (/Common/http-test-farm1.app/http-test-farm1_http) cannot be deleted because it is in use by a sflow http data source (16).." Auto-sync must be enabled. HTTP iApp must have been reconfigured prior to deleting the iApp. Sync failure, requires sol13030 to clear. Unable to delete the iApp manually after the error occurs. Workaround: Do not use auto-sync.
ID 498839 NTPd crashes and fails to re-start when more than 1024 IPs are present in the system. Create ~1024 or more self IPs (the number of other IP addresses vary for each system and needs to be considered in the 1024 count) NTPd service not running causing time to go out of sync, probably inducing issues in HA setups. Workaround: "Run: tmsh modify sys ntp include 'interface listen <management interface linux name>' Like: tmsh modify sys ntp include 'interface listen eth0' to specify the interface ntpd should listen."
ID 498976 Local BIND is not answering queries for various zones while "rndc reload" is occuring. This can be triggered by sync_zones due to updates to Wide IPs or ZRD changes if 'Synchronize DNS Zone Files' is enabled. "Local BIND will not answer queries while 'rndc reload' is running. If a GTM config sync is also ocurring, the GTM can get into a state where all queries go unanswered until the GTM configuration loads and/or the BIND zone(s) load." Workaround: Move critical zones to DNS-Express.
ID 499260 tmsh command 'delete cm trust-domain all' intermittently hangs. This occurs when there is a non-local device that is used by the HA order in one of the traffic groups. Unable to delete trust domain. Pressing Ctrl + C shows: Unexpected Error: Could not reset trust-domain (error from devmgmtd): Error reading from server...' In the /var/log/ltm the system posts the message: 'err devmgmtd[7887]: 015a0000:3: -unknown- failed on -unknown-.devicegroup: 01071761:3: Cannot delete device (bigipsystem.test.com) from device group (/Common/sync-failover-1) because it is used by HA order on traffic group (/Common/traffic-group-2)'. Workaround: Retrying sometimes succeeds. Removing the ha-order traffic group also allows the operation to succeed.
ID 499430 On a standby unit with a vlangroup configured with multiple vlans and bridge_in_standby attribute set to false, it may still bridge network ingress packets across the vlangroup if those packet happen to match with host monitor traffic flows. Configure a vlangroup with multiple vlan members in HA pair and set vlangroup's brideg_in_standby attribute to false. Configure monitors to use non default (icmp, etc) monitor rules. This will result in a traffic bridging loop among active and standby unit. Those excessive traffic load will take down monitors on BIG/IP. Workaround:
ID 499694 When upgrading from v10.2.x to v11.5.1, node monitor name does not acquire full path or partition information. Similarly, creating a node with a monitor via TMSH, node monitor name does not show partition information; however, configuring a node via GUI does add partition information. Upgrade Cosmetic Workaround:
ID 499750 Sometimes, the BIG-IP system sends the _SHA256 cipher in the ClientHello message of TLS1.0. This occurs when using the _SHA256 cipher in clientssl and serverssl profiles. Depends on the peer implementation. Sometimes the Peer SSL responds with an Alert message and refuses to establish a connection. Workaround:
ID 500234 TMM cores when transitioning from standby to active. This might occur when the following conditions are met: -- An IPsec tunnel is enabled. -- The BIG-IP system is a member of an HA pair. -- The BIG-IP system transitions from standby to active. TMM core leading to outage. Workaround:
ID 500317 When using fastL4, connection might not be immediately removed from the connection table, taking up to 60 seconds until they are removed. This requires a fastL4 with loose-init enabled and loose-close disabled. Connections are not immediately removed from the connection table. This can result by impacting traffic by using up more memory on the unit. Workaround: Disable loose-init or enable loose-close.
ID 500365 There is a memory leak when using SIP in TCP/ClientSSL configurations. The leak occurs when the clientside flow is torn down in response to the SSL handshake not completing. Because the SSL handshake is not complete, the SIP handler cannot complete the operation as expected, which results in an error and a memory leak of the SIP handler. The tmm memory increases, which eventually requires restarting tmm as a workaround. Workaround: Although there is no workaround to prevents the issue, you can recover from the memory-leak condition by restarting tmm.
ID 500688 "After installing the hotfix for CVE-2014-8730 we do not accept incorrect padding. However, when SSL receives records with a wrong padding, it does not send out the bad_record_mac alert." SSL receives records with a wrong padding Workaround:
ID 501418 TMM route table does not use both ECMP routes for the default route. ECMP + OSPF Does not use both equal cost routes to route traffic Workaround:
ID 501516 When using a very large number of monitors, bigd may run out of file descriptors on a secondary blade when it is rebooted. A multi-bladed system with a large number of monitors configured. bigd cores and gets into a restart loop; monitors no longer work properly. Workaround: Reduce the number of monitors on the system.
ID 501517 Messages with "end_transaction message timeout on connection 0x5ea9a9c8 (user mcpd-primary)" in them in the ltm log after a secondary blade is inserted or restarted. A multi-bladed system with a very large configuration that takes more than a minute to transfer to secondary blades. mcpd's transaction does not complete and the configuration will not be loaded properly. Workaround:
ID 501670 mcpd cores with a stack trace similar to that listed in the main description. Perform a a config sync on a system with multiple blades and at least one peer, with mcpd debugging enabled. mcpd cores, resulting in an outage or a failover. Workaround: Disable mcpd debugging.
ID 501690 TMM crashes with a specific ASSERT-based backtrace, matching the one given below. Requires an LTM listener with an iRule that has a RESOLV::lookup command querying for a TXT record and receiving multiple RRs. Failover or site down, momentarily. Workaround:
ID 501961 "The clusterd daemon may log one or more 'blade X powered DOWN' messages, followed by one or more 'blade X powered up' messages approximately one second later, with no other messages logged indicating any other issues with the cluster members. Example messages: Dec 31 09:01:37 slot7/... warning clusterd[7569]: 013a0009:4: Blade 7: blade 5 powered DOWN. Dec 31 09:01:37 slot7/... warning clusterd[7569]: 013a0009:4: Blade 7: blade 6 powered DOWN. Dec 31 09:01:37 slot7/... warning clusterd[7569]: 013a0009:4: Blade 7: blade 7 powered DOWN. Dec 31 09:01:38 slot7/... notice clusterd[7569]: 013a0010:5: Blade 7: blade 5 powered up. Dec 31 09:01:38 slot7/... notice clusterd[7569]: 013a0010:5: Blade 7: blade 6 powered up. In this case, these messages indicate a transient loss of accurate blade power and/or presence reporting over the chassis management backplane, which was quickly restored. The BIG-IP cluster management daemon (clusterd) uses additional channels of communication to verify cluster member state, and does not take action affecting the cluster state in response to such transient conditions." "This may occur rarely and intermittently when affected versions of BIG-IP are running on VIPRION 4000-series blades in VIPRION 4000-series chassis: VIPRION B4100 (PB100), B4200 (PB200), or B4300 blades VIPRION C4400, C4480, or C4800 chassis" "In the absence of other messages indicating a change in the cluster or member status, these messages indicate a transient loss of accurate blade power and/or presence reporting over the chassis management backplane, which was quickly restored. The BIG-IP cluster management daemon (clusterd) does not take action affecting the cluster state in response to such transient conditions." 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

451602

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