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

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 4.2.0
Release Notes
Original Publication Date: 01/08/2003 Updated Date: 04/18/2019


This release note documents version 4.2 of the BIG-IP software.  This release supports both the IP Application Switch(tm) platform and the BIG-IP(R) Controller platform.


Minimum system requirements

This section describes the minimum system requirements for this release.

Minimum system requirements for BIG-IP
      Pentium II 266MHz
      64MB RAM

Minimum system requirements for BIG-IP with the 3-DNS module
      Pentium II 266MHz
      512MB RAM
      166MB disk space

About the BIG-IP 4.2 upgrade

This release note describes how to upgrade the BIG-IP to version 4.2. 

If you install the version 4.2 upgrade im package, we strongly recommend that you install version 4.2 PTF-01. Version 4.2 PTF-01 contains important updates to the SSL Accelerator features in addition to several other performance enhancements. If you use the CD image to install the full system, the enhancements in version 4.2 PTF-01 are installed automatically.

When upgrading to version 4.2, you can choose from two different procedures, based on the version of BIG-IP that you are currently running. These upgrade procedures are:

  • Upgrading from version 4.0 or higher to version 4.2.  If your BIG-IP is currently running version 4.0 or higher, you can upgrade directly to version 4.2.  For detailed instructions, see Upgrading from version 4.0 or higher to version 4.2.
  • Upgrading from pre-4.0 to version 4.1.1  If the BIG-IP is currently running version 3.1 or higher, up to and including version 3.3.1, you can upgrade directly to version 4.1.1. After you upgrade to version 4.1.1, you can follow the instructions for upgrading from version 4.0 or higher to version 4.2.  For detailed instructions, see Upgrading from a pre-4.0 version of BIG-IP .

[ Top ]

Installing the Upgrade

Upgrading from version 4.0 or higher to version 4.2

The procedure to upgrade your BIG-IP 5000 or BIG-IP 2000 to version 4.2 is as follows. If you are upgrading a controller platform, you can skip the steps for creating a memory file system, and copy the im package into the /var/tmp directory.

If you are upgrading a BIG-IP redundant system, you should synchronize the configuration before you install the upgrade. Synchronizing mixed versions of the BIG-IP software is not supported.

On the BIG-IP, copy the im package from the F5 Networks, Inc. FTP site and run it, as follows:

  1. Create a memory file system, by typing the following:

    mount_mfs -s 200000 /mnt

  2. Type the following command:

    cd /mnt

  3. Connect to the FTP site (

  4. If you are running the crypto version of the BIG-IP, download the file from the /crypto/bigip/bigip42ptf1 directory.

    If you are running the non-crypto version of the BIG-IP, download the file from the /nocrypto/bigip/bigip42nocrypto directory.

  5. On the BIG-IP, run the im upgrade script, using the file name from the previous step as an argument:

    im /mnt/<file name>

    When the the im script is finished, the BIG-IP reboots automatically.

[ Top ]

New features and enhancements

This section describes new features and enhancements included in this release of the BIG-IP software.

Support for the Controller and IP Application Switch platforms

This release includes support for both the BIG-IP Controller and the IP Application Switch(tm) hardware platforms.

The Setup utility

This release includes a new Setup utility for initially configuring your BIG-IP system.  The Setup utility replaces the web-based and console-based First-Time Boot utility. For more information, see the BIG-IP Reference Guide Chapter 2, Using The Setup Utility.

Enhanced pools support

This release contains several new attributes that you can assign to load-balancing pools.  These new attributes include support for Session Initiation Protocol (SIP) Call-ID persistence, enhanced ability to redirect HTTP requests, the ability to insert client IP addresses into HTTP requests, and the ability to set specific Quality of Service (QoS) and Type of Service (ToS) levels within a packet.  Furthermore, this release allows you to configure a pool to automatically disable a SNAT or NAT connection, or to bypass the load balancing of a connection by automatically forwarding the connection, using IP routing.  In addition to using these new pool attributes, you can also specify a pool of multiple default gateways, used for handling administrative traffic such as SSH, Telnet, FTP, and HTTPS connections.  For more information, see Pools  in the BIG-IP Reference Guide.

New global variable for failover traffic

A new global variable open_failover_ports is included in this release.  The new variable allows you to restrict network failover traffic on specific VLANs. For more information, see the BIG-IP Reference Guide Chapter 7, bigpipe Command Reference.

Enhanced rules support

With this release comes a number of new variables and operators to enhance the ways that you can select pools for load balancing.  Using rule statements, you can now select pools based on such criteria as the IP protocol of a packet, TCP/UDP port numbers, and QoS and ToS levels.  A rule can also now balance traffic based on whether the client IP address is a member of a specific class.  For SSL Accelerator proxies, you can use rules to rewrite HTTP redirection to ensure that traffic remains on an SSL-secured channel. For more information, see Rules  in the BIG-IP Reference Guide.

Enhanced support for virtual servers

This release contains a number of enhancements to the BIG-IP virtual server.  First, you can now define multiple wildcard virtual servers instead of a single wildcard virtual server only.  Second, you can configure an option known as dynamic connection rebinding, designed for those virtual servers that are load balancing transparent devices such as firewalls or routers.  Dynamic connection rebinding causes any connections to a node address or service to be redirected to another node if the original node transitions to a DOWN state.  Last, you can prevent a virtual server from sending a TCP reset when a connection is timed out. For more information, see Virtual Servers in the BIG-IP Reference Guide.

SSL Accelerator proxy enhancements

This release includes several important enhancements to the SSL Accelerator proxy.  For example, you can now configure options such as specifying ways for an SSL proxy to manage client certificates, inserting headers into HTTP requests, specifying ciphers and protocol versions, and configuring SSL session cache size and timeout values. 
This release also supports the SSL-to-Server option, which allows you to re-encrypt traffic after it has been decrypted by the BIG-IP.  This feature has been enhanced in this release to further ensure the security of SSL connections between the proxy and the server.  For a complete description of all new SSL Accelerator proxy options, see the Proxies  section in Chapter 4 of the BIG-IP Reference Guide.

Support for a FIPS 140-1 level 3 certified SSL hardware security module

BIG-IP Controller platforms now support a FIPS 140-1-certified hardware security module (HSM).  This hardware option is specifically designed for processing SSL traffic within environments that require FIPS 140-1 Level 3 compliant solutions.  For more information, see Configuring FIPS 140 Security World on the BIG-IP  in the Documentation section of the Software and Documentation CD.

Enhanced support for Secure Network Address Translations (SNATs)

In previous releases, BIG-IP allowed you to automatically map VLANs to translation IP addresses during SNAT creation.  In this release, you can now use this automapping feature not only for VLANs, but for one or more individual IP addresses.  For more information, see the BIG-IP Reference Guide, Address Translation: NATs, SNATs, and IP Forwarding.

Enhanced interface statistics

This release features enhanced statistics for BIG-IP interfaces.  The following state information and statistics are now available: MTU, Speed, MAC address, packets in, errors in, packets out, errors out, collisions, dropped packets, bits in, bits out.  Previously available on the IP Application Switch, this feature is new for the BIG-IP Controller platform.  For more information, see the BIG-IP Reference Guide Chapter 11, Monitoring and Administration.

Health monitor enhancements

In addition to the standard SNMP health monitor template included in BIG-IP, this release now includes a second SNMP template, which allows users to collect data on elements other than CPU, disk, and memory usage.  For more information, see Configuring SNMP Servers and Health Monitors in the BIG-IP Reference Guide.

Support for LDAP and RADIUS logins

With this release, BIG-IP can now authenticate SSH users by way of an LDAP or a RADIUS server.  For information on configuring this feature, see Configuring RADIUS or LDAP login support in the BIG-IP Reference Guide.

Enhanced system logging

System logging in this release provides more detailed information, such as up or down status for nodes.  For more information, see the BIG-IP Reference Guide Chapter 11, Monitoring and Administration.

Web-based Configuration utility enhancements

This release includes a number of improvements to the web-based Configuration utility.  All new features for this release are supported by the Configuration utility.

BIG-IP now uses OpenSSH

This release converts the existing SSH daemon and configuration to OpenSSH. OpenSSH is installed by default. If you have customized the previous version of SSH on the BIG-IP, your changes may be overwritten when you install this upgrade. Also, you should check /etc/hosts.allow to make sure that the security settings are appropriate.

[ Top ]

Configuring and using the new software

This section provides information about both required and optional configuration changes.

Required configuration changes

The current release has no required configuration changes

Optional configuration changes

New interfaces and associated methods for iControl

There are a number of new interfaces and associated methods for iControl.

New interfaces and associated methods:

  • ITCMNetworking::VLAN
  • ITCMNetworking::SelfIP
  • ITCMNetworking::Interfaces
  • ITCMNetworking::Trunk
  • ITCMNetworking::SpanningTree
  • ITCMNetworking::PortMirror

New methods for existing interfaces:

  • LocalLBGlobal.idl
  • LocalLBNAT.idl
  • LocalLBNode.idl
  • LocalLBPool.idl
          new MSRDP persistence mode support
  • LocalLBProxy.idl
  • LocalLBSNAT.idl
  • LocalLBVirtualServer.idl

Mapping existing bigdb keys which are now obsolete

In this release of BIG-IP, many of the proxy-related common bigdb keys have been made obsolete, in order to provide those same features on a per-proxy basis. As a result, the proxy attributes to which these keys apply must now be configured either through the bigpipe proxy and bigpipe global commands, or through the Configuration utility Proxies and System screens.

If you are upgrading to BIG-IP version 4.2 from a previous release, BIG-IP does not automatically map your existing bigdb key configurations to the new proxy attributes. You must therefore use the bigpipe command or the Configuration utility to reconfigure any proxy attributes that you previously configured with the bigdb keys.

The following table shows, for each obsolete bigdb key, the corresponding bigpipe command line and Configuration utility attributes that replace that key.

Per-proxy attributes (b proxy command or Proxies screen)

bigdb Key b Proxy Attribute Configuration Utility Attribute
Common.Bigip.Proxy.InsertClientCert [clientssl] client cert insert Insert Certificate
Common.Bigip.Proxy.InsertClientCipher [clientssl] cipher insert Insert Cipher
Common.Bigip.Proxy.AddHTTPHeader [clientssl] header insert Insert HTTP Header String
Common.Bigip.Proxy.CipherList [clientssl] ciphers Client Cipher List String
Common.Bigip.Proxy.SSLVersion [clientssl] invalid Client-side Connections Do Not Use These SSL Versions
Common.Bigip.Proxy.RequestClientCert [clientssl] client cert Client Certificate
Common.Bigip.Proxy.RequireValidClientCert [clientssl] client cert Client Certificate
Common.Bigip.Proxy.VerifyClientOnce [clientssl] authenticate Client Authenticate
Common.Bigip.Proxy.VerifyClientDepth [clientssl] authenticate depth Client Authenticate Depth
Common.Bigip.Proxy.RewriteRedirects redirects rewrite Rewrite Redirects
Common.Bigip.Proxy.ClientSessionCacheTimeout [clientssl] cache timeout Client Session Cache Timeout

Global attributes (b global command or System Admin screen)

bigdb Keys b global Attribute Configuration Utility Attribute
Common.Bigip.Proxy.ServerSessionCacheTimeout sslproxy serverssl cache timeout Server SSL Session Cache Timeout
Common.Bigip.Proxy.FailoverOnHardwareFailure sslproxy failover Failover on SSL Accelerator Failure
Common.Bigip.Proxy.SSLUncleanShutdown sslproxy unclean shutdown Unclean Shutdown Of All SSL Connections
Common.Bigip.Proxy.AllowImproperSSLResume sslproxy strict resume Do Not Resume Uncleanly Shutdown SSL Connections
Common.Bigip.Proxy.AkamaiConfigFile sslproxy akamaizer filename [Not available]

Wildcard forwarding virtual server

If you are currently using IP forwarding, for BIG-IP version 4.0 and higher we strongly recommend that you use a wildcard forwarding virtual server instead of or in addition to IP forwarding. With the additional features in BIG-IP 4.x, using a wildcard forwarding virtual server is faster than using IP forwarding. A wildcard forwarding virtual server also allows you to get statistics on the exact amount of traffic flowing through the system.

If you want to configure a wildcard forwarding virtual server to handle IP forwarded traffic, use the following procedure on your 4.x system. You can perform this procedure on-the-fly without causing any interruption of service.

  1. To set up timeouts type the following commands:
    bigpipe service 0 tcp enable
    bigpipe service 0 timeout tcp 30
    bigpipe service 0 udp enable
    bigpipe service 0 timeout udp 30

  2. Set up a wildcard forwarding virtual server by typing the following command:
    bigpipe virtual forward

  3. If you want to allow protocols other than TCP and UDP through the forwarding virtual server, use the following command. The default timeout is 15 seconds.
    bigpipe virtual any_ip enable
    If you want to change the default timeout for this setting, use this syntax:
    bigpipe virtual any_ip timeout <seconds>
    For example, if you want to change the default timeout to 5 seconds, type this command:
    bigpipe virtual any_ip timeout 5

  4. To save your new configuration, type:
    bigpipe save

For more information on wildcard forwarding virtual servers, see the BIG-IP Administrator Guide.

[ Top ]

Documentation updates

The following procedures and table in the BIG-IP Reference Guide have been updated.


To specify the Trusted CA file and Trusted CA path using the Configuration utility


The following procedure updates page 4-104 in the BIG-IP Reference Guide.

  1. In the navigation pane, click Proxies.
  2. Click the Add button.
  3. In the boxes Client Trusted CA File and Client Trusted CA Path, or Server Trusted CA File and Server Trusted CA Path, either select the name of a Trusted CAs file and path from the box, or type the name of a Trusted CA file or path.
  4. If you want to ensure that each certificate has a link to its corresponding file, check the Generate Symbolic Links for Client Trusted CAs Path check box. This step should be taken when specifying any of the path attributes.
  5. Click Done.



To specify the Trusted CA file and Trusted CA path from the command line


The following procedure updates page 4-104 in the BIG-IP Reference Guide.

To specify the Trusted CA file and Trusted CA path from the command line, type the bigpipe proxy command, using the appropriate arguments, as follows:

b proxy <ip>:<service> [clientssl] ca file <clientside CA file name>
b proxy <ip>:<service> [clientssl] ca path <clientside CA path name>
b proxy <ip>:<service> serverssl ca file <serverside CA file name>
b proxy <ip>:<service> serverssl ca path <serverside CA path name>

Symbolic links should be generated when specifying path attributes. To do this from the command line, type following bigpipe commands for each unique path, using the appropriate arguments, as follows:

cd <path name>
make -f /config/bigconfig/ssl.crt/Makefile

Required formats of client certificate headers

The following table shows the client certificate headers that the SSL proxy can insert into a client request. For each header, the required format, description, and keyword is shown. This table updates table 4.18, on page 4-98, of the BIG-IP Reference Guide.

Header Name Required Format Description
Certificate status SSLClientCertStatus: [status] The status of the client certificate. The value of [status] can be "NoClientCert", "OK", or "Error". If status is "NoClientCert", only this header is inserted into the request. If status is "Error", the error is followed by a numeric error code.
Certificate version SSLClientCertVersion: [version] The version of the certificate.
Certificate serial number SSLClientCertSerialNumber: [serial] The serial number of the certificate.
Signature algorithm of the certificate SSLClientCertSignatureAlgorithm: [alg] The signature algorithm of the certificate.
Issuer of the certificate SSLClientCertIssuer: [issuer] The issuer of the certificate.
Certificate validity dates SSLClientCertNotValidBefore: [before]
SSLClientCertNotValidAfter: [after]
The validity dates for the certificate. The certificate is not valid before or after the dates represented by [before] and [after], respectively.
Certificate subject SSLClientCertSubject: [subject] The subject of the certificate.
Public key of the subject SSLClientCertSubjectPublicKey: [key] The type of public key type. The allowed types are "RSA ([size] bit)", "DSA", or "Unkown public key".
The certificate itself SSLClientCert: [cert] The actual client certificate.
MD5 hash of the certificate SSLClientCertHash: [hash] The MD5 hash of the client certificate.

[ Top ]

Known issues

The following items are known issues in the current release.

Fan and temperature monitoring with SNMP
SNMP queries for fan speed, CPU temperature, and power supply status are functional for certain platforms. Currently, fan and temperature monitoring is supported only for the following platforms:

520 and 540

For these platforms, automatic periodic monitoring is not automatically enabled. You can enable periodic monitoring by uncommenting the line in /config/crontab which runs system_check every two minutes. However, the system_check script does affect performance. Fan and temperature SNMP monitoring are not supported in the following platforms with this version of the BIG-IP software:

Changing active-active failback values (CR22715)
In active-active configurations, we recommend that you do not change the default failback value of 60 seconds. If you change this value, failback may not work as designed.

Shell interpreted characters in monitors
Monitors cannot pass shell interpreted characters, such as &, <, and > in parameters.

Port mirroring on the IP Application Switch  (CR18435)
Ports not configured in a VLAN will not be mirrored on the IP Application Switch.

proxy_arp does not fail over on VLAN group  (CR18928)
When the BIG-IP goes from active to standby and MAC masquerading is not being used, layer 2 forwarding VLAN groups will continue to forward packets until the packets source arp cache times out.

Sequence number tracking  (CR19392)
Out of order packets to a delayed binding VIP may cause sequence number tracking may become desynced.

Permissions of .crt files (SSL proxy)  (CR19438)
In certain situations, CA files (.crt) or chain files (.chain) may fail to load because of file permission problems. These errors are presented in the /var/log/proxyd log file. If this situation arises, adjust the file permissions of the problematic file so that they are set to at least 440 (owner read, group read).

TCP 4-way close  (CR19591)
TCP 4-way close is not properly detected in all cases when packets are dropped or sent out of order by an upstream device.

Resets from a virtual server to a proxy  (CR19667)
A reset from a virtual server due to a denial (such as port not enabled) does not have last hop routing support. This means a RST from a virtual server to a proxy may go from the external interface to the client instead of through the proxy.

Setting active-active mode using the web-based Configuration utility  (CR19794)
With network failover enabled you will not be able to configure active-active mode using the Configuration utility. When you have network failover enabled, use the command line interface to set active-active mode.

syslog pinger requires changes for increased resilience  (CR19874)
If you define, delete, and then re-define a monitor without deleting the changes to /etc/syslog.conf, the monitor will may not function properly.

[ Top ]