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. 

Use the following process to install the software:

1. Click here and follow the instructions for using the F5 Networks FTP site.
2. Download bigipv323kit.f5.tar file to the /var/tmp/ directory on the BIG-IP Controller. 
   
   If you are using an international version restricted by cryptography export laws, you need to download the bigipv323nocryptokit.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 bigipv323kit.f5.tar upgrade_install

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

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

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

   /var/tmp/upgrade_install

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:

/etc/rc.local
/etc/rc.sysctl
/etc/syslog.conf
/etc/daily
/etc/snmpd.conf
/etc/snmptrap.conf
/etc/bigip.conf
/etc/bigd.conf
/etc/daily.local

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, 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:

config_telnetd

config_ftpd

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. 

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. 

---

What's fixed in this version

• CR 8955:   NAT originating address check uses incorrect netmask
  NAT addresses no longer 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 of BIND includes fixes for known security problems. 
• CR 8843:  The genkey command line utility creates 512 byte keys only
  You now have 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
  Persisting SSL and cookie connections are now accepted after you use the bigpipe <node ip>:<port> disable command to disable a node. 
• CR 8768:  Cannot add a large number of members to a pool without degrading performance
  You can now add a large number of members to a pool without degrading performance. 
• CR 8735:  Running configsync can disrupt VLAN configuration
  VLAN configurations no longer 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 that use 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
  Active FTP data connections can now connect through a SNAT. 
• CR 8658:  Cookie request is inserted if HTTP request is corrupted
  If the BIG-IP Controller 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
  FTP connections are successful even if a packet was resent when connecting through a SNAT. 
• CR 8619:  Problem with large HTTP posts through SSL gateway
  Forms larger than 2048 bytes can now post through the SSL gateway. 
• CR 8291:  Active-active cross-over bounceback not working
  You can now use 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
  Gateway failsafe now fails over multiple times even if both gateways are down at once. 
• CR 7031:  Base persistence on pre-translation (pre-snat) address (bounceback/snat+vip)
  Client connections now persist 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 release. 

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 Controller Administrator Guide, Generating a key and obtaining a certificate from the command line . 

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 the 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

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

Issues with the SSL Accelerator feature

Enable port 443
If you use the Configuration utility to configure the SSL Accelerator feature, you must enable the port 443 from the command line.  To enable this port from the command line, type the following command:

bigpipe port 443 enable

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:

proxyd

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. 

Appearance of zero cookie expiration in certain situations

You may see a zero cookie expiration setting in certain situations if the persist mode is set to none.  For instance, if you add a pool from the Configuration utility, one that has no persistence configured, a cookie expiration value of zero may be added to /etc/bigip.conf.  For example, if you add a pool "a_pool" with the members 10.10.10.1 and 10.10.10.2 in it, its entry in /etc/bigip.conf looks like:

pool a_pool {
   lb_method round_robin
   persist_mode none
   cookie_expiration 0d 00:00:00
   member 10.10.10.1:http ratio 1 priority 1
   member 10.10.10.2:http ratio 1 priority 1
}

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 the user 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 = "10.65.1.1"
b2:/etc# bigdba -d - 2>&1 | grep -i statemirror.ipaddr
Local.Bigip.Statemirror.IPAddr = "10.65.1.3"

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 0.0.0.0

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

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 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.

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

The BIG-IP Controller, version 3.2.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 unlikey, 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.

Incorrect error message appears if you add a member definition with a port 0

When you add a member to a pool and the member has a zero port, the Configuration utility displays a warning that wildcard ports are being phased out.  This warning should not appear and you can ignore it.  The warning message was to indicate that simple service checks are being phased out.

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

The pingnode alias option does not work if you assign the node port any 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

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. 

---

---