Applies To:
Show VersionsBIG-IP versions 1.x - 4.x
- 3.2.0
Summary:
Contents:
Installing the upgrade
You can apply this release to version 2.0 and later. Do not apply previous PTFs; they are already included in the current installation.
Use the following process to install the software:
- Click here and follow the instructions for using the F5 Networks FTP site.
- Download bigipv32kit.f5.tar file to the /var/tmp/ directory on the BIG-IP Controller.
Customers who are using an international version restricted by cryptography export laws, need to download the bigipv32nocryptokit.f5.tar. To place FTP in passive mode, type pass from the command line before transferring the file.- Type the following commands to install the global release of this software:
cd /var/tmp
tar -xvpf bigipv32kit.f5.tar upgrade_install - Type the following commands to install the non-crypto release of this software:
cd /var/tmp
tar -xvpf bigipv32nocryptokit.f5.tar upgrade_install
- Type the following commands to install the global release of this software:
- From the root (/), enter the following command:
/var/tmp/upgrade_install
- 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_install. When you run the install script, the script untars and installs only the files required to upgrade your installation.
The installation automatically creates a backup of the following files 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 a file in the following list, you may need to edit that file and retype your modifications:
/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 are ugrading 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:
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, Nodelist Virtual Server and Persistence Backward Compatibility, in the see the BIG-IP Controller Administrator Guide, Chapter 6, Working with Advanced Persistence Options for more details.
Customers upgrading versions of the BIG-IP Controller now have the option of configuring either a Telnet or FTP server during the upgrade, or you can do the configuration at a later time. During the upgrade process, you are prompted to configure either Telnet or FTP if they have not been configured. Follow the instructions.
If you choose to configure Telnet or FTP at a later time, type the appropriate command:
config_telnetd
config_ftpd
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.
If 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.
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 new in this version
Enhancements
- BIG-IP Fire Guard
This version of the BIG-IP Controller is available as the BIG-IP Fire Guard firewall load balancer. The BIG-IP Fire Guard version contains a specific set of features from the BIG-IP Controller for load balancing firewalls in your network. For more information, see the BIG-IP Controller Administrator Guide, Chapter 8, Using Firewall Load Balancing . - RADIUS server support
This version of the BIG-IP Controller provides a feature that allows you to use a RADIUS server on your network to authenticate users attempting to access the controller with SSH. This allows you to use the RADIUS server as a central repository of users that can access the BIG-IP Controller for administrative purposes. For more information, see the BIG-IP Controller Administrator Guide, Configuring RADIUS authentication . - Improved fastest load balancing
This version of the BIG-IP Controller contains new fastest mode server load balancing algorithms. The new algorithms use improved metrics to determine server response times in Fastest, Predictive, and Observed load balancing modes. For more information, see the BIG-IP Controller Reference Guide, BIG-IP System Control Variables . - Improved behavior of forwarding virtual servers and default SNAT
With this version of the BIG-IP Controller, the default SNAT ignores a new connection with a destination that matches a forwarding virtual server. This causes outbound connections to use either a forwarding virtual server or the default SNAT depending on the destination of the packet that initiates the connection. For more information, see the BIG-IP Controller Reference Guide, BIG-IP System Control Variables . - BIG-IP LB and LB+ versions support SSH
The BIG-IP Controller LB and LB+ versions now support SSH. Note that with this upgrade, you must run the config_failover utility after you upgrade in order for the configuration synchronization utilities to work on existing LB and LB+ redundant BIG-IP Controllers. - Added SSH 2.0
This version of the This version of the BIG/ip Controller upgrades the version of SSH to version 2.0. Note that with this upgrade, you must run the config_failover utility after you upgrade redundant controllers in order for the configuration synchronization utilities to work.
Fixes
- CR 8619: Problem with large HTTP posts through SSL gateway
Fixed a problem that could prevent posting forms larger than 2048 bytes through the SSL gateway.
Known issues
The following issues are known issues with the BIG-IP Controller, version 3.2:
Issues with IEEE 802.1q VLAN Trunks
In an active/standby configuration, when IEEE 802.1q VLAN Trunks are used, certain actions may interfere with normal operation. These are:
- Performing a configsync from the active unit to the standby unit
- Deleting an IP alias on the standby unit
For this reason, Version 3.2 is Not Recommended for installations that require IEEE 802.1q VLAN Trunks.
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. Type the following command to enable this port from the command line:
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 affect. Restart the proxyd by typing the following command on both units:
proxyd
Advisory message: Accepting host < ip address of other BIG-IP > 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 the following:
- 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 23MB 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 example, 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:
- Run the command:
bigdba /var/f5/bigdb/user.db
This opens the database. - Within the database, type the following commands:
> Local.Bigip.Statemirror.IPAddr="<correct_ip_addr>"
> quit - 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 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 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:- First, turn on destination address processing on the internal interface with the following command:
bigpipe interface exp1 dest enable
- 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 Configuration utility, follow these steps:
Enable destination address processing on the internal interface with the Configuration utility
- 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. - In the Network Interface Card table, click the name of the internal interface you want to configure.
The Network Interface Card Properties screen opens. - To enable destination processing for the interface, click the Enable Destination Processing check box.
- Click the Apply button.
After you configure destination processing on the internal interface, synchronize the configuration of the redundant BIG-IP Controller system.
- In the navigation pane, click the BIG-IP logo.
The BIG-IP Properties screen opens. - In the toolbar, click the Sync Configuration button.
The Synchronize Configuration screen opens. - Click the Synchronize button.
BIG-IP Controller, version 3.2, compatibility with the 3DNS Controller
The BIG-IP Controller, version 3.2, is compatible with the 3DNS Controller, version 2.x. Previous versions of the 3DNS 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 BIG-IP Controller
In order for state mirroring to work properly after a configuration change, follow these general guidelines:- Make your configuration changes.
- 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
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. It is very unlikely you will see this error. 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. When you see this error message, use this procedure to get a new certificate:- Select the Netscape Security icon.
- Navigate to Certificates and then click Web Sites.
Delete the existing certificate for the BIG-IP Controller. - 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 which does "forms processing". Using the browser back button is generally discouraged after multiple "Apply" operations have been completed. This can, with supported versions of Netscape (4.5 and later), result in the display of historical data. Hitting another "Apply" at this point would restore 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. It is possible that this delay might last a number of 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. 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 your nodes.
You cannot reset individual pool statistics from command line
Currently, you cannot reset statistics for individual pools from the command line.