Applies To:

Show Versions Show Versions

Archived Release Note: BIG-IP Controller Release Note, version 3.1
Release Note

Original Publication Date: 04/27/2000

This article has been archived, and is no longer maintained.

Summary:

These release notes cover changes since version 3.0. This release is recommended, but not mandatory, for all customers. It contains significant new features. This release applies to both BIG/ip HA and BIG/ip LB.

Contents:

- Installing the upgrade
- What's new in this version
- Configuring and using the new software
- Known issues

Installing the upgrade

You can apply this release to version 1.8.3 and later. Do not apply previous PTFs; they are already included in the current 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 bigipv31domkit.f5.tar file to the /var/tmp/ directory on the BIG/ip Controller.

    Customers who are using LB version of the BIG/ip Controller need to download the bigipv31lbdomkit.f5.tar. To place FTP in passive mode, type pass from the command line before transferring the file.

  3. Enter the following commands to install this software:

    cd /var/tmp
    tar -xpf bigipv31domkit.f5.tar (HA and HA+)
    tar -xpf bigipv31lbdomkit.f5.tar (LB)

  4. From the root, enter the following command:

    /var/tmp/upgrade_install

  5. 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, 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 that during the upgrade, 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 F5 Configuration utility to change the configuration. To cause the F5 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 LB 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.


What's new in this version

Enhancements

  • Adding an SSL Accelerator

    With this version of the BIG/ip Controller, you can configure the SSL Accelerator feature to act as a gateway for SSL traffic to your content servers. You can set up a gateway on the BIG/ip Controller that accepts HTTPS connections (HTTP over SSL).

    A key component of the SSL Accelerator feature is that the web server can retrieve the web page using an unencrypted HTTP request to the content server. In this way, the SSL gateway converts HTTP requests that are encrypted with SSL, to unencrypted requests. Unencrypting the request is necessary so that the header of the HTTP request can be processed and used to intelligently control how the request is handled. For information about adding an SSL gateway, see the BIG/ip Controller Administrator Guide, Chapter 4, Configuring the SSL Accelerator .

  • Using pool persistence
    With this version of the BIG/ip Controller, persistence settings are configured at the pool level instead of the virtual server level. A pool configured with persistence settings can be referenced by a rule. This simplifies and increases the granularity of persistence configuration. For information about using Pool Persistence, see the BIG/ip Controller Administrator Guide, Chapter 6, Working with Advanced Persistence Options .

  • HTTP header rule variable
    This version of the BIG/ip Controller supports a new rule variable that evaluates the string following a user specified HTTP header tag. Header tags are not case sensitive. For information about using this variable, see Using the HTTP header rule variable.

  • Contains rule operator
    This version of the BIG/ip Controller supports a new rule string operator that returns True if the right-hand operand is a substring of the left-hand operand. This operator requires less processing than the equivalent matches_regex operation. For information about using this variable, see Using the Contains rule operator.

  • New load balancing methods
    This version of the BIG/ip Controller supports the new observed_member and predictive_member load balancing methods. Like the node address observed and predictive methods, the new methods dynamically calculate which member to load balance connections to based on current connection count and inter-packet delta time. However, the new methods store load balancing state in the member "ripeness" element. This allows the new methods to load balance correctly even when multiple node servers have the same node address.

  • Enhancements to the F5 Configuration utility
    The web-based F5 Configuration utility for the BIG/ip Controller, version 3.1, contains the following enhancements:

    • SSL Accelerator:  Added support for the SSL Accelerator feature. To access the SSL Accelerator feature in the F5 Configuration utility, click the Proxies icon in the navigation pane.

    • Pool Persistence:  Persistence can now be configured for Pools, and thereby rules. The persistence settings previously were available on the Global Virtual Port Property Page, the Virtual Server Property Page, or the Virtual Servers Application Persistence Page. Now, all persistence values are located on the new Persistence Property page which can be accessed from the Pool Properties page or the Virtual Server Properties page (for appgen_ pools).

    • The bonfire compatibility mode toggle is gone. The BIG/ip Controller is always running in this mode.

    • A NIC Status field was added to the NIC list page. This field shows the whether the NIC is active, has no-carrier, or is not available.

    • Masks that are turned off show up as blank in the UI instead of as 255.255.255.255.


Configuring and using the new software

The following configuration options are available with this release of the BIG/ip Controller.

Using the HTTP header rule variable
You can apply the HTTP header variable with the following syntax in a rule:

http_header <header-tag-string>

For example, a rule with an http_host variable could also be written with an http_header variable:

if ( http_host starts_with "andrew" ) {
    use ( andrew_pool )
}
else {
    use ( main_pool )
}

Or you can use the following syntax:

if ( http_header "Host" starts_with "andrew" ) {
    use ( andrew_pool )
}
else {
    use ( main_pool )
}

Since the generalized http_header variable requires more processing to evaluate than specific variables like http_host, the http_header variable should only be used if a specific variable does not exist.

Using the Contains rule operator
You can apply the contains rule operator with the following syntax:

<variable_operand> contains <literal_string>

For example, a rule using this operator might look like this:

if ( http_host contains "drew" ) {
    use ( andrew_pool ) }
else {
    use ( main_pool )
}


Known issues

The following issues are known issues with the BIG/ip Controller, version 3.1:

Upgrading from a 3.1 BETA release

If you are upgrading from a 3.1 BETA release, the following lines need to be removed from the /etc/rc.local file. This does not affect you if you upgrade from a previous version of BIG/ip Controller, such as version 3.0 or earlier.

exi=`/bin/ps -a -x -o pid,command | grep "proxyd" | grep -v "grep"`
if [ "$exi""X" != "X" ]; then
echo "SSL Proxy started"
fi

Syntax error after upgrading from BETA 2

After you upgrade and you reboot, you may see the error:

"syntax error on line 545 /var/f5/httpd/conf/httpd.conf: invalid command ExtendedStatus perhaps misspelled or defined by a module not included in the server configuration."

If you see this error, you cannot connect to the web server on the BIG/ip Controller until you comment out the following line in the /var/f5/httpd/conf/httpd.conf file. To fix this problem, type a # sign in front of the line:

Extended status On

Issues with the SSL Proxy feature

Enable port 443
If you use the F5 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 SSL gateway
The SSL gateway included with this release does not have a monitor to automatically restart it if it should fail. If it does fail, you can restart it by typing the following command:

/sbin/checkd

Receiving an error when attempting to synchronize a configuration that includes an SSL gateway
The F5 Configuration utility and bigpipe configsync options do not copy certificates or keys for SSL gateway. If keys and certificates are not installed on both controllers, synchronizing the configuration through the Configuration utility fails with the message: "check SSH configuration" on an HA controller, or the message "Configuration synchronization error, please check web configuration" on an LB controller. In general, if the synchronization fails from the Configuration utility, repeat synchronization from the command line to view the error that is causing the failure. It is most likely that the configuration did not synchronize because the keys and certificates were not copied onto the peer BIG/ip Controller before you ran the configuration synchronization command.

Copying certificates and keys to a peer controller
In a redundant system, you must copy the keys and certificates to the other controller. You must do this before you use the configuration synchronization option from the F5 Configuration utility or from the command line. Copy the certificates from the following directory into the same directory on the peer BIG/ip Controller:

/var/asr/gateway/certs/

You can use the following command to copy the certificates over:

scp /var/asr/gateway/certs/<your_cert_file> root@<int_ip_addr_other_bigip>:/var/asr/gateway/certs/

Copy the keys from the following directory into the same directory on the peer BIG/ip Controller:

/var/asr/gateway/private/

You can use the following command to copy the certificates over:

scp /var/asr/gateway/private/<your_key_file> root@<int_ip_addr_other_bigip>:/var/asr/gateway/private/

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 (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. Run the command:

    bigdba /var/f5/bigdb/user.db

    This opens the database.

  2. Within the database, type the following commands:

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

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

  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 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.1, compatibility with the 3DNS Controller

The BIG/ip Controller, version 3.1, 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:

  1. Make your configuration changes.

  2. Synchronize the configuration between the two controllers. You can run the bigpipe configsync all command, or use the F5 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 F5 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 F5 Configuration utility. When 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 F5 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.

Random appearance of "zero" cookie expiration in certain situations

If the user adds a pool from the UI, one that has no persistence configured, a cookie expiration value of zero will be added to /etc/bigip.conf. For example, if the user adds pool "a_pool" with the members 10.10.10.1 and 10.10.10.2 in it, its entry in /etc/bigip.conf will look 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
}

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. It is possible that this delay might appear to be the controller hanging. This delay is not used in manual failback mode.

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.




Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)