Release Notes : BIG-IP Controller PTF note, version 3.2 PTF-01

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 3.2 PTF-01
Release Notes
Original Publication Date: 07/06/2000 Updated Date: 04/18/2019

Summary:

This product temporary fix (PTF) provides fixes for BIG-IP Controller, version 3.2, and it is recommended only for those customers who want the enhancements and fixes listed below. The PTF includes all fixes released since version 3.2, including fixes originally released in prior PTFs.

Contents:

Installing the PTF

Apply the PTF to BIG-IP Controller version 3.2 using the following process:

  1. Click here and follow the instructions for using the F5 Networks FTP site.

    Use FTP in passive mode from the BIG-IP Controller to download the file. To place FTP in passive mode, type pass from the command line before transferring the file.

  2. Download the bigip3.2ptf-1kit.tar file to the /var/tmp/ directory on the target BIG-IP Controller.

  3. Enter the following commands to install this PTF:

    cd /var/tmp
    tar -xvpf bigip3.2ptf-1kit.tar upgrade_ptf

  4. Run the following commands:

    cd /
    var/tmp/upgrade_ptf

  5. Follow the on-screen instructions.

Note:  Note that 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_ptf. When you run the install script, the script untars and installs only the files required to upgrade your installation.

The install automatically creates a backup of the /etc/syslog.conf file in /var/save/backupyymmdd_hhmm/ on the BIG-IP Controller and removes any old files that are no longer used. If you have made changes to the /etc/syslog.conf file, you may need to edit that file and retype your modifications.

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

Once you have installed the PTF software, please refer to the Configuring and using the updated software.


What's fixed in this PTF

  • CR 8955:   NAT originating address check uses incorrect netmask
    Fixed a problem that could cause the NAT address to reject valid original NAT addresses if the netmask for the translated NAT address is different from the original address.
  • CR 8945:  A security update is available for BIND
    This version of the BIG-IP Controller contains version 8.2.2, p15, of BIND. This version includes fixes for known security problems.
  • CR 8843:  The genkey command line utility creates 512 byte keys only
    Added the ability to create 512 bit or 1024 bit keys with the genkey utility. For more information about how to create different size keys with genkey, see Specifying key length with the genkey utility.
  • CR 8774:  Disabled nodes should accept cookie and SSL persistent connections
    Fixed a problem with the bigpipe <node ip>:<port> disable that would cause persisting SSL and cookie connections to be rejected when a node was disabled with this command.
  • CR 8768:  Cannot add a large number of members to a pool without degrading performance
    Fixed a problem that degraded BIG-IP Controller performance if you added a large number of members to a pool.
  • CR 8735:  Running configsync can disrupt VLAN configuration
    Fixed a problem that could cause VLAN configurations to fail after you run the configuration synchronization utilities.
  • CR 8687:  Logical OR vertical bar (|) not supported in match_regex rules
    Added support for the Logical OR vertical bar (|) to rules using the binary operator matches_regex. For example, you can now use syntax such as "\.(gif|jpg)" in a rule.
  • CR 8676:  Active FTP can fail intermittently through a SNAT
    Fixed a problem that could cause active FTP data connections through a SNAT to fail.
  • CR 8658:  Cookie request is inserted if HTTP request is corrupted
    Fixed a problem that could allow the BIG-IP Controller to insert a cookie request in http requests that are corrupted. Now, if the BIG-IP cannot parse the HTTP header from the client, it does not insert a cookie in the response header from the server.
  • CR 8653:  FTP through SNAT can fail
    Fixed a problem that could cause an FTP connection to fail if a packet was resent when connecting through a SNAT.
  • CR 8291:  Active-active cross-over bounceback not working
    Fixed a problem that could prevent you from using the cross-over bounceback configuration in active-active mode. The cross-over bounceback configuration allows you to set up a NAT for a node on one BIG-IP Controller and allow it to connect to a virtual server on the other BIG-IP Controller.
  • CR 7261:  Gateway failsafe should fail over multiple times
    Fixed a problem that could prevent gateway failsafe from failing over multiple times if both gateways are down at once.
  • CR 7031:  Base persistence on pre-translation (pre-snat) address (bounceback/snat+vip)
    Fixed a problem that could prevent client connections from persisting to the correct node if they passed through a SNAT or NAT, and then through a virtual server. For example, this might happen in a configuration with SNAT bounceback or virtual server/SNAT combination.

Configuring and using the updated software

The following configuration options are available with this PTF.

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 store.myurl.com, you would use the following syntax:

genkey store.myurl.com 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 Administrator Guide, Generating a key and obtaining a certificate from the command line, page 4-7.

Configuring a network virtual server

You can configure a network virtual server with this release. A network virtual server is a virtual server that handles a whole network range, instead of just one IP address, or all IP addresses (wildcard virtual servers). For example, the following virtual server handles all traffic addresses in the 192.168.1.0 network:

bigpipe vip 192.168.1.0:0 none {
    netmask 255.255.255.0 broadcast 192.168.1.255
    use pool ingress_firewalls
}

Note:  Network virtual servers should be assigned to interface none.

A network virtual server is a virtual server that has no bits set in the host portion of the IP address. In other words, the host portion is zero. You must specify a network mask to indicate which portion of the address is the network address and which portion is the host address. In the previous example, since the network mask is 255.255.255.0, the network portion of the address is 192.168.1 and the host portion is .0. The previous example would direct all traffic destined to the subnet 192.168.1.0/24 through BIG-IP Controller to the ingress_firewalls pool.

Another way you can use this feature is to create a catch-all webserver for an entire subnet. For example, you could create the following network virtual server:

bigpipe vip 192.168.1.0:http none {
    netmask 255.255.255.0 broadcast 192.168.1.255
    use pool default_webservers
}

This configuration directs a web connection destined to any address within the subnet 192.168.1.0/24 to the default_webservers pool.


Known issues

Issues with the BIG-IP 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 on 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

If you configure the BIG-IP Controller with the F5 Configuration utility, follow these steps:

Enable destination address processing on the internal interface with the F5 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 this 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 navigation pane, click the BIG-IP logo.
    The BIG-IP Properties screen opens.
  2. In the toolbar, click the Sync Configuration button.
    The Synchronize Configuration screen opens.
  3. Click the Synchronize button.