Release Notes : BIG-IP Controller Release Note, version 3.3

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 3.3.0
Release Notes
Original Publication Date: 09/26/2000 Updated Date: 04/18/2019


These release notes cover changes since version 3.2.3  This release is a major release.  It contains significant new features.  This release applies to both global BIG-IP Controller releases and BIG-IP Controller releases that do not contain SSL cryptography technology (non-crypto). 


Installing the upgrade

You can apply this release to version 2.0 and later.  Do not apply previous PTFs; they are included in this installation.  If you are upgrading from a version released prior to BIG-IP Controller version 3.1, please review the section Upgrading from BIG-IP Controller versions released prior to version 3.1 before you install this upgrade.

Note:  The installation procedure has changed slightly from the one you used with previous versions of the software.  With this version, you need only untar the install script upgrade_install.  When you run the install script, the script untars and installs only the files required to upgrade your installation.  If the BIG-IP Controller you are upgrading has a solid state drive (SSD), you must use the new procedure.

Use the following process to install the software:

  1. Click here and follow the instructions for using the F5 Networks FTP site.
  2. Download bigipv33kit.f5.tar file to the /var/tmp/ directory on the BIG-IP Controller. 

    If you are using a non-crypto version restricted by cryptography export laws, you need to download the bigipv33nocryptokit.f5.tar.  To place FTP in passive mode, type pass from the command line before transferring the file. 
    • To install the global release of this software, type the following commands:

      cd /var/tmp
      tar -xvpf bigipv33kit.f5.tar upgrade_install

    • To install the non-crypto release of this software, type the following commands:

      cd /var/tmp
      tar -xvpf bigipv33nocryptokit.f5.tar upgrade_install

  3. From the root (/), enter the following command:


  4. Follow the on-screen instructions.

The installation automatically creates a backup of the following files in /var/save/backupyymmdd_hhmm/ on the BIG-IP Controller:


Note:  If you have made changes to a file in this list, you may need to edit that file and retype your modifications.

If you are upgrading a version of the BIG-IP Controller that does not contain SSL cryptography technology (non-crypto), you now have the option to configure either a Telnet or FTP server during the upgrade, or you can do the configuration at a later time.  The upgrade process prompts you to configure either Telnet or FTP if they have not been configured.  Follow the instructions on your screen. 

You can configure Telnet or FTP at a later time.  When you are ready to configure Telnet or FTP, type one of the following commands to start the appropriate configuration utility:



Note:  During an upgrade, you may see the error message "Bad interface name passed to the kernel" when the BIG-IP Controller starts to reboot.  This error is harmless.  It is a result of the unfamiliarity of the drivers with the new configuration files.  After the upgraded controller automatically reboots, the new drivers should correspond to the new configuration files correctly. 

The checksums for this release are available in a file called sums, which can be downloaded from the FTP site. 

What's new in this version


  • BIG-IP e-Commerce Controller
    This version of the BIG-IP Controller is available as the BIG-IP e-Commerce Controller.  You can use the BIG-IP e-Commerce Controller to process SSL connections to your network.  This controller contains a specific set of software and hardware features that accelerate SSL connections.
  • BIG-IP Cache Load Balancer
    This version of the BIG-IP Controller is available as the BIG-IP Cache Controller.  The BIG-IP Cache Controller version contains a specific set of features from the BIG-IP Controller that maximizes the efficiency of caches in your network.  In addition to the load balancing features available with this controller, this version of the controller has new rule syntax that provides the ability to redirect HTTP requests to caches in your network.  These features include:
    • Cacheable content determination
      This feature enables you to determine the type of content you cache on the basis of any combination of elements in the header of an HTTP request.
    • Content affinity
      This feature assures that the same cache serves the same content subset even when caches become temporarily unavailable or when caches are added to or deleted from the cache pool.
    • Hot content load balancing
      When configured, this feature identifies highly requested content and redirects these requests to a hot pool for load balancing.
    • Intelligent cache population
      When configured, this feature allows caches to retrieve content from other caches in addition to the origin web server.
  • Performance enhancements
    This version of the BIG-IP Controller includes internal performance enhancements.  These enhancements improve the overall performance of the BIG-IP Controller.  For additional information about these performance enhancements, see Additional Speed Enhancements for TCP Connections.

Configuring and using the updated software

The following configuration options are available with this release. 

Cache statement syntax

A cache statement may be either the only statement in a rule or it may be nested within an if statement.  The syntax of a cache statement is:

cache ( <expression> ) {
    origin_pool <pool_name>
    cache_pool <pool_name>
    [ hot_pool <pool_name> ]
    [ hot_threshold <hit_rate> ]
    [ cool_threshold <hit_rate> ]
    [ hit_period <seconds> ]
    [ content_hash_size <sets_in_content_hash> ]

The following table describes the new cache syntax:

Rule Syntax Description
origin_pool <pool_name> This required attribute specifies a pool of servers with all the content to which requests are load balanced when the requested content is not cacheable or when all the cache servers are unavailable or when you use a BIG-IP Controller to redirect a miss request from a cache.
cache_pool <pool_name> This required attribute specifies a pool of cache servers to which requests are directed to optimize cache performance.
hot_pool <pool_name> This optional attribute specifies a pool of cache servers that contain all content to which requests are load balanced when the requested content is frequently requested (hot).  If you specify any of following attributes in this table, the hot_pool attribute is required.
hot_threshold <hit_rate> This optional attribute specifies the minimum number of requests for content x that cause content x to change from cool to hot at the end of the period (hit_period).
cool_threshold <hit_rate> This optional attribute specifies the maximum number of requests for content x that cause content x to change from hot to cool at the end of the period.
hit_period <seconds> This optional attribute specifies the period in seconds over which to count requests for particular content before deciding whether to change the hot or cool state of the content.
content_hash_size <sets_in_content_hash> This optional attribute specifies the number subsets into which the content is divided when calculating whether content is hot or cool.  The requests for all content in the same subset are summed and a single hot or cool state is assigned to each subset.  This attribute should be within the same order of magnitude as the actual number of requests possible.  For example, if the entire site is composed of 500,000 pieces of content, a content_hash_size of 100,000 would be typical.

A cache statement returns either the origin pool, the hot pool, or the cache pool.  When the cache pool is selected, it is accompanied by the indicated node address and port.  When a rule returns both a pool and a node, the BIG-IP Controller does not do any additional load balancing or persistence processing.

An example of a rule containing a cache rule statement is:

rule my_rule {
    if ( http_host starts_with "dogfood" ) {
        cache ( http_uri ends_with "html" or http_uri ends_with "gif" ) {
        origin_pool origin_server
        cache_pool cache_servers
        hot_pool cache_servers
        hot_threshold 100
        cool_threshold 10
        hit_period 60
        content_hash_size 1024
    else {
        use ( catfood_servers )

Using a default SNAT if your origin server is external to the BIG-IP Controller
If your origin server is external to the BIG-IP Controller, you must configure a default SNAT, enable source translation on the external interface, and set the origin server node address to remote in addition to creating a cache rule.  This configuration allows source translation of non-cacheable requests directed to the origin server without causing other incoming traffic to be source translated.  To create a default SNAT, type the following command:

bigpipe snat map default to <snat ip>

Substitute the IP address of the default SNAT for <snat ip>.

To enable source translation on the external interface, type the following command:

bigpipe interface <ext_interface> source_translation enable

Substitute the name of the external interface for <ext_interface>.

To add the remote origin server to the BIG-IP Controller configuration, use the following command:

bigpipe node <origin_ip> remote

Substitute the IP address of the origin server for <origin_ip>.

Additional Speed Enhancements for TCP Connections

Additional enhancements are included in this release that speed packet flow for TCP connections when the packets are not fragmented.  In most configurations these software enhancements are automatically turned on and do not require any additional configuration.

However, you may want to turn off these enhancements for individual virtual servers that use IPFW rate filters.  With the speed enhancements on, IPFW only examines the first SYN packet in any given connection.  If you want to filter all packets, you should turn the speed enhancements off.  To do this, you must first set the global state of the system ON, and then you must turn the feature off for individual virtual servers that use IPFW rate filtering.  You can change the settings for these enhancements from the command line or in the Configuration utility.

Setting software acceleration controls from the command line
There are three global states you can set with the sysctl variable bigip.fastpath_active.  The default state is automatic or a value of 1.  The global states are:

0 = off
1 = automatic
2 = on

The additional speed enhancements are globally disabled if the sysctl variable bigip.fastpath_active is off (0) or if bigip.fastpath_active is set to automatic (1) and an IPFW rate filter exists in the configuration.

To provide the benefits of software acceleration for virtual servers that do not use rate filtering and turn off software acceleration for virtual servers that use IPFW rate filtering, you can set the sysctl variable bigip.fastpath_active to on (2) with the following command:

sysctl -w bigip.fastpath_active=2

After you set the sysctl variable, use the following bigpipe commands to disable software acceleration for virtual servers that use IPFW rate filtering:

bigpipe vip <ip>:<port> accelerate disable

You can use the following command to turn off software acceleration for a virtual server configured with IPFW rate filters when you define it from the command line:

bigpipe vip <ip>:<port> use pool the_pool accelerate disable

Setting software acceleration controls in the Configuration utility
You can set the sysctl variable bigip.fastpath_active from the BIG-IP System Control Variables page.  To do this, use the following procedure:

  1. In the navigation pane, click the BIG-IP Controller icon.
    The BIG-IP System Properties page opens.
  2. In the toolbar, click the Advanced Properties button.
    The Advanced Properties screen opens.
  3. In the Global Acceleration section, select the On box.
  4. Click the Apply button.

To turn off acceleration for a virtual server in the BIG-IP Controller version 3.3 release, simply check the Disable Acceleration box on the Virtual Servers Properties screen.  To do this use the following procedure:

  1. In the navigation pane, click Virtual Servers.
    The Virtual Servers page opens.
  2. In the Virtual Servers list, click the virtual server for which you want to disable acceleration.
    The Properties page for the virtual server you selected opens.
  3. In the Virtual Server Properties screen, check the Disable Acceleration box.
  4. Click the Apply button.

When acceleration is on, the bigpipe -s command does not show that acceleration is enabled.

Gateway Failsafe ping/timeout intervals

We recommend a Gateway Failsafe ping interval of 2 seconds with a timeout of 10 seconds.  If this interval is too small, you can enter any 1 to 5 ratio that works for you. 

Synchronize time between peer BIG-IP Controllers

It is helpful to synchronize the time between redundant BIG-IP Controllers so that you can compare an event on one BIG-IP Controller with an event that has happened on its peer.  After you synchronize the time, you can check the log files on both machines and compare event times.

First, set the time on one BIG-IP Controller.  Then, from the command line, type the following to synchronize the other controller:

bigpipe time sync

Packet Statistics

To minimize the performance hit on the BIG-IP Controller, packet statistics are only updated at connection termination.  Therefore, if you are watching real-time statistics, you will not see the numbers change until the connection is terminated.

Specifying key length with the genkey utility

Use the following syntax to specify the key length of the key created by the genkey utility:

genkey <server name> [<key size>]

The <server name> is the URL or server for which you generate the key.  The <key size> is the key length you specify for the key, such as 512 or 1024.  For example, if you want to create a 1024-bit key for the URL, you would use the following syntax:

genkey 1024

The key length is optional.  If you do not specify a key length, the key size defaults to 512 bits.  For more detailed information about using the genkey utility, see the BIG-IP Controller Administrator Guide, Generating a key and obtaining a certificate from the command line, page 4-7

Known issues

The following issues are known issues with the BIG-IP Controller, version 3.3:

Mirroring connections

Connections resulting from cookie persistence or late binding rules cannot be mirrored.

Using Internet Explorer 5.5 with this version of the Configuration utility

If you use Internet Explorer 5.5, there are certain instances that will cause a Security Information dialog box to open.  For example, if you navigate to the Tool Options page and select the color palette icon (to open the color palette and select a color).  The Security Information dialog box states:" This page contains both secure and nonsecure items. Do you want to display the nonsecure items?" The button choices are Yes, No, and More Information.  You should click Yes in response to this dialog box as this is an erroneous error message, your secure connection to your BIG-IP Controller is intact. 

If you select No, access will be blocked to other areas of the tool.  If this happens, restart Internet Explorer, reinitiate the https session to the BIG-IP, and click Yes to the security warning.  You should only have to answer Yes to this warning once per session.

Allowing TCP access on SNMP port 161

To allow TCP access on the SNMP port 161, it is necessary to type the following command:

bigpipe interface <interface_name> adminport open

You will also need to edit the /etc/rc.local file by adding -T TCP to the following:


# BIG/ip SNMP Agent
if [ -f /etc/snmpd.conf ]; then
     /sbin/bigsnmpd -c /etc/snmpd.conf -P /var/run/


# BIG/ip SNMP Agent
if [ -f /etc/snmpd.conf ]; then
     /sbin/bigsnmpd -c /etc/snmpd.conf -P /var/run/ -T TCP

We have added a fix for a problem in the UC Davis utilities that prevented TCP queries from working.

Issues with the SSL Accelerator feature

An SSL Accelerator connection has a fixed reap time of 300 seconds. An SSL Accelerator connection that targets a virtual server connection is terminated when the virtual server connection is terminated.  A virtual server connection targeted by an SSL Accelerator connection is terminated when the SSL Accelerator connection is terminated.

Restart the proxyd after overwriting keys and certificates
If you overwrite existing keys or certificates in the SSL gateway configuration in the Configuration utility or from the command line, you must restart the proxyd from the command line in order for the changes to take effect.  Restart the proxyd by typing the following command on both units:


Advisory message: Accepting host < ip address of other controller > key without checking

This message appears the first time you run the configsync command between two BIG-IP Controllers you have not synchronized before.  This warning advises you that no DNS or other authentication was performed to guarantee the identity of the remote system. 

Installing this upgrade on a system with limited disk space

Before you install this upgrade on a controller with limited disk space, such as a controller with an SSD (Solid State Disk) drive, we recommend that you note the following information:

  • No matter what version you are upgrading from, the /var filesystem needs about 48MB free to perform the upgrade.  If the controller has an SSD drive, you need to clear out most of the archived logs in /var/log to get this amount of free space. 
  • Controllers with SSD drives should only have / and /var filesystems.  You should have between 17 MB and 23 MB in the / to successfully perform the upgrade. 
  • If you have a controller with an SSD drive, remove the upgrade tarball from /var/tmp after you complete the upgrade. 

Interface selected inconsistently

Some versions of the BIG-IP Controller are not consistent in how they choose the interface for state mirroring and other controller-to-controller communication.  Newer versions ask you which interface to use.  This can result in two BIG-IP Controllers with different interface choices for state mirroring.  This can cause state mirroring to fail and make it impossible to enable active-active mode.  You can use the following command to check which interface is set on each BIG-IP Controller (sample output is also shown):

b1:/etc# bigdba -d - 2>&1 | grep -i statemirror.ipaddr
Local.Bigip.Statemirror.IPAddr = ""
b2:/etc# bigdba -d - 2>&1 | grep -i statemirror.ipaddr
Local.Bigip.Statemirror.IPAddr = ""

Make sure that the IP addresses shown are on the same internal subnet.  If they are not, then the BIG/db needs to be changed manually to correct the problem.  To fix the problem, follow this procedure:

  1. To open the database, run the command:

    bigdba /var/f5/bigdb/user.db

  2. Within the database, type the following commands:

    > Local.Bigip.Statemirror.IPAddr="<correct_ip_addr>"
    > quit

  3. After you are finished, reboot the BIG-IP Controller.

Persist mask default is

The simple persistence mask is < by default.  The mask may be reset to the < state by setting its value to either or

The default SNAT and NATs from the BIG-IP Controller versions 2.1.x

If your configuration contains a default SNAT and NATs, you receive an error as the configuration file is read by the BIG-IP Controller.  This configuration is not supported in BIG-IP Controller version 3.1.1.  To fix this error, you must remove either the default SNAT or the NATs from the /etc/bigip.conf file. 

Issues with the BIG-IP Controller NAT bounceback

The NAT bounceback feature allows a node on the internal network to access a virtual server and be load balanced to another set of internal servers (nodes).  In versions prior to 3.0, NAT bounceback is enabled automatically when you create a NAT or SNAT.  In BIG-IP Controller versions 3.0 and later, this feature is disabled by the upgrade process.  To avoid a possible site interruption when using NAT bounceback
After you apply the BIG-IP Controller version 3.0 upgrade (or later), follow these steps on the command line:
  1. First, turn on destination address processing for the internal interface with the following command:

    bigpipe interface exp1 dest enable

  2. Synchronize the configuration with the other BIG-IP Controller version 3.0 or later. 

    bigpipe configsync

Enable destination address processing on the internal interface with the Configuration utility

  1. In the navigation pane, click NICs.
    The Network Interface Cards screen opens.  You can view the current settings for each interface in the Network Interface Card table. 
  2. In the Network Interface Card table, click the name of the internal interface you want to configure.
    The Network Interface Card Properties screen opens.
  3. To enable destination processing for the interface, click the Enable Destination Processing check box.
  4. Click the Apply button.

After you configure destination processing on the internal interface, synchronize the configuration of the redundant BIG-IP Controller system.

  1. In the toolbar, click the Sync Configuration button.
    The Synchronize Configuration screen opens.
  2. Click the Synchronize button.

BIG-IP Controller, version 3.3, compatibility with the 3-DNS Controller

The BIG-IP Controller, version 3.3, is compatible with the 3-DNS Controller, version 2.x.  Previous versions of the 3-DNS Controller are not supported with this release.

Interface configuration

The /etc/bigip.interfaces file is being phased out.  Interface settings are now stored in BIG/db.

State mirroring in the BIG-IP Controller

In order for state mirroring to work properly after a configuration change, you must follow these general guidelines:
  1. Make your configuration changes.
  2. Synchronize the configuration between the two controllers.  You can run the bigpipe configsync all command, or use the Configuration utility Config Sync feature.

Certificate error with Netscape Navigator 4.61 and 4.7

Although it is very unlikely, you can receive the error "Netscape has encountered bad data from the server" when attempting to connect to the Configuration utility with Netscape Navigator versions 4.61 and 4.7.  This error may occur if you have a new BIG-IP Controller installed and a cached certificate is present in the copy of Netscape you use to access the Configuration utility.  If you see this error message, use this procedure to get a new certificate:
  1. Select the Netscape Security icon.
  2. Navigate to Certificates and then click Web Sites.
    Delete the existing certificate for the BIG-IP Controller.
  3. Connect to the BIG-IP Controller and accept the new certificate.

Using the browser back button is discouraged

The Configuration utility is a CGI application that does forms processing.  We strongly recommend you do not use the browser back button after clicking the Apply button multiple times.  This can, with supported versions of Netscape (4.5 and later), result in the display of historical data.  Clicking the Apply button at this point restores that historical data to the BIG-IP Controller.

Active-active unit recovery delay

The fail-over daemon (sod) now calculates a delay that is used to wait before an active unit returns an ID to a recovered unit.  This delay is based on timeout_node, timeout_svc, interface failsafe timeout, and gateway pinger timeout settings.  This delay might last up to several minutes.  This delay is not used in manual failback mode.

The pingnode alias option does not work with node port "any/0"

The pingnode alias option does not work if you assign the node port any/0 to nodes.

You cannot reset individual pool statistics from the command line

Currently, you cannot reset statistics for individual pools from the command line.

Upgrading from the BIG-IP Controller versions released prior to version 3.1

Warning:  Since this upgrade installs a new version of SSH, you must run the config_failover utility after you upgrade in order for the configuration synchronization utilities to work on existing redundant HA versions of the BIG-IP Controller.  If you upgrade a redundant LB version of the BIG-IP Controller, you must run the config_failover utility in order to set up the configuration synchronization options.  If you are upgrading from version 3.2.3 or if you are running a non-crypto version of BIG-IP Controller, you do not need to do this.

Changing F5 Support access
If you are upgrading a version of the BIG-IP Controller software released prior to version 3.1, after the BIG-IP Controller upgrade you are prompted to enable or disable F5 Support accounts on the BIG-IP Controller.  You can configure a new password for F5 Support accounts or disable the accounts.

Adding unit numbers
If you are upgrading a version of the BIG-IP Controller software released prior to version 3.1, and you have not configured a unit number for each controller in a redundant system, you are prompted to type in a unit number for the BIG-IP Controller.  If this is the first controller you are upgrading, you can use the default unit number 1.  If this is the second controller, type in 2 for the second unit.

Node list to pool conversion
If you are upgrading from BIG-IP Controller versions released prior to version 3.1, the bigip.conf file is converted to a new pool-based format.  Before the conversion takes place, the existing /etc/bigip.conf and /etc/bigd.conf are backed up in the /var/save/backupyymmdd_hhmm/ directory.  Any lists of nodes you have configured are converted into standard pool configurations.  After the conversion, these pool configurations are named using the following format:

    appgen_<vip IP.port>
The BIG-IP Controller derives the <vip IP.port> part of the name from the IP address and port combination of the original node list virtual server.  The new configuration is written to /etc/bigip.conf when either the bigpipe -s /etc/bigip.conf or bigpipe configsync are run from the command line, or when you use the Configuration utility to change the configuration.  To cause the Configuration utility to display an appgen_<vip IP.port> pool in the same manner as other pools, you can change the name of the pool so that it does not begin with appgen.  See, the BIG-IP Controller Administrator Guide, Chapter 6, Working with Advanced Persistence Options for more details.