Installing the Upgrade

About the BIG-IP 4.1.1 upgrade

This release note describes how to upgrade your BIG-IP to version 4.1.1.  You perform the upgrade using the BIG-IP 4.1.1 Upgrade CD.

Note:  If you need to perform a recovery of version 4.1.1 because your BIG-IP 4.1.1 software was inadvertently damaged, do not use the upgrade instructions in this release note. Instead, see SOL1493: Backing up and restoring BIG-IP or 3-DNS configuration files.

When upgrading to version 4.1.1, 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.1.1.  If your BIG-IP is currently running version 4.0 or higher, you can upgrade directly to version 4.1.1.  For detailed instructions, see Upgrading from version 4.0 or higher to version 4.1.1.
• Upgrading from pre-4.0 to version 4.1.1.  If your 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.  If your BIG-IP is running a pre-3.1 version, you must upgrade to version 3.3.1 first, and then upgrade to version 4.1.1.  For detailed instructions, see Upgrading from pre-4.0 to version 4.1.1.
  
  

  Note:  The BIG-IP 4.1.1 Upgrade CD ROM contains a special One Time Conversion Utility (OTCU) for converting your current configuration during the pre-4.0-to-4.1.1 upgrade.  OTCU parses the pre-4.0 configuration files and uses the data to create the 4.0 configuration database.  This conversion of the data is necessary because the configuration files, file locations, and file formats in 4.1.1 are different from those in pre-4.0 versions. 

---

Upgrading from version 4.0 or higher to version 4.1.1

The procedure to upgrade your BIG-IP to version 4.1.1 is as follows:

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 (ftp.f5.com).
4. If you are running the crypto version of the BIG-IP, download the file Upgrade-4.1-1BSD_OS-4.1.im from the /crypto/bigip/bigip411 directory.
   
   If you are running the non-crypto version of the BIG-IP, download the file UpgradeNocrypto-4.1-1BSD_OS-4.1.im from the /nocrypto/bigip/bigip411nocrypto 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.

---

Upgrading from pre-4.0 to version 4.1.1

If your BIG-IP is currently running version 3.1 or higher, you can upgrade directly to version 4.1.1, using the following procedure.

If you are running a pre-3.1 version of BIG-IP, you must first upgrade to version 3.3.1, and then upgrade to version 4.1.1.  The version 3.3.1 upgrade software is included on the BIG-IP 4.1.1 Upgrade CD ROM, and that upgrade is documented here as part of the version 4.1.1 upgrade procedure.

In general, the process of upgrading to BIG-IP version 4.1.1 requires you to do the following:

• Mount the BIG-IP 4.1.1 Upgrade CD
• Upgrade to version 3.3.1 (for pre-3.1 systems only)
• Save BIG-IP configuration data
• Install BIG-IP version 4.1.1
• Convert BIG-IP configuration data

The following sections describe how to perform these tasks.

Mount the BIG-IP 4.1.1 Upgrade CD

Assuming your hardware platform includes a CD ROM drive, insert the CD ROM in your BIG-IP Controller and mount it by typing the following commands:

mount -o suid /cdrom

Note:  If you receive an error when you attempt to mount the CD, try the following mount command.

mkdir /cdrom
mount -t cd9660 -o na,ro,nosuid,nodev /dev/sr0a /cdrom

Upgrade to version 3.3.1 (for pre-3.1 systems only)

If you are running a BIG-IP version earlier than version 3.1, use the following procedure.  Otherwise, skip this step and go directly to Save BIG-IP version configuration data.

1. Copy the upgrade tar file on the CD to the /var/tmp directory on your BIG-IP.  The name of the upgrade tar file differs depending on whether you are upgrading to the global release of version 3.3.1 (crypto), or the non-crypto version.

   If you are upgrading to the global (crypto) release, type:

   cp /cdrom/upgrade331/bigipv331kit.f5.tar /var/tmp

   If you are upgrading to the non-crypto release of version 3.3.1, type:

   cp /cdrom/upgrade331/bigipv331nocryptokit.f5.tar /var/tmp

2. Untar version 3.3.1. as follows.  If you are upgrading to the global (crypto) release, type:

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

   If you are upgrading to the non-crypto release, type:

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

3. Enter the following command:

   /var/tmp/upgrade_install

   This starts the actual upgrade to version 3.3.1.

4. Follow the on-screen instructions.  The upgrade automatically creates a backup, in /backupyymmdd_hhmm/, of the following files:

   /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

   If you made changes to a file on this list before this upgrade, you will need to edit that file and retype your modifications after the upgrade is complete.

   When upgrading a non-crypto version of the BIG-IP software, the upgrade process now prompts you to configure the Telnet and FTP programs, if they are not already configured.

5. Follow the instructions on your screen to configure the Telnet and FTP programs.  This is an essential step to enable you to back up the configuration tar files that are collected as part of the 4.1.1 upgrade. 

   Once the Telnet and FTP programs have been configured, the system automatically reboots.

   Note:  During the reboot, you might see the error message Bad interface name passed to the kernel.  This error is harmless.  It is a result of the unfamiliarity of the drivers with the new configuration files.  After the reboot is finished, the new drivers should correspond correctly to the new configuration files.

6. Verify that your version 3.3.1 system is fully functional.  If the system is not fully functional at this point, it will not be functional after upgrading to version 4.1.1.

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

7. Re-mount the CD ROM by typing the following:

   mount /cdrom

Save BIG-IP version 3.3.1 configuration data

Before you install BIG-IP version 4.1.1, you must preserve your version 3.3.1 configuration data.  This is to prevent loss of this data if, for any reason, the version 4.1.1 upgrade is not successful.

To save your version 3.3.1 configuration data, use the following procedure:

1. Collect and archive the version 3.3.1 configuration files, by typing the following:

   /cdrom/upgrade_config

   This script collects critical configuration data as well as user-created or modified text and binary files.  All files are then archived to /var/tmp/otcu/otcu.tar.gz and /var/tmp/otcu/bin_files.tar.gz.  The critical files archived are:

   /etc/bigip.conf
   /etc/bigd.conf
   /etc/bigip.license
   /etc/inetd.conf
   /etc/rc
   /etc/rc.sysctl
   /etc/rc.local
   /etc/master.passwd
   /etc/netstart
   /var/f5/httpd/conf/httpd.conf
   /var/f5/httpd/conf/mime.types
   /var/f5/httpd/ssl/certs
   /var/f5/httpd/ssl/private
   /var/f5/httpd/basicauth/users
   /var/f5/www/seeit/.users
   /var/f5/bigdb/user.txt
   /var/f5/bigdb/user.db
   /var/asr/gateway/certs
   /var/asr/gateway/private

2. Back up the archived configuration files to a remote location.  This is of critical importance.  The 4.1.1 installation program, when it is run, attempts to save the file /var/tmp/otcu/otcu.tar.gz on the BIG-IP hard drive.  If this file save is not successful, the remotely-stored file remains your only alternative source for the version 3.3.1 configuration data.

   For the global (crypto) version, you can copy the tar file to a remote host using SSH and scp, as follows:

   cd /var/tmp/otcu
   ssh <remote_host> mkdir <path_to_backup_dir>
   scp *.gz <remote_host>:<path_to_backup_dir>

For the non-crypto version, you can copy the tar file to a remote host using the Telnet and FTP programs, as follows:

1. Using Telnet, log into the remote host and create a backup directory:

   mkdir <path_to_backup_dir>

2. Using FTP, transfer the tar file to the remote backup directory:

   cd /var/tmp/otcu
   ftp <remote_host>
   ftp> mput *.gz <path_to_backup_dir>
   ftp> quit

Install BIG-IP version 4.1.1

In general, the process for installing BIG-IP version 4.1.1 requires you to perform three tasks:

• Reboot the system from the CD ROM drive
• Boot the system from the hard drive
• Convert the configuration data

Reboot the system from the CD ROM drive

If the BIG-IP has a CD ROM drive, reboot the system from the CD ROM drive, by typing reboot.

NOTE:   If your BIG-IP does not have a CD ROM drive, you must first use the BIG-IP Upgrade CD to establish a remote host as an installation server, and then network boot the system from the installation server.  For more information, see the Technical Note titled About the BIG-IP 4.1.1 network boot.

If the CD-ROM drive is the primary boot device, this causes the BIG-IP to boot from the CD.  If the CD-ROM drive is not the primary boot device, typing reboot causes the BIG-IP to initiate the boot from a different device (probably the hard drive), and you will need to interrupt it and and specify the CD-ROM drive as the boot device.  How you do this depends on your BIOS, but the following sequence is typical:

1. Type <ctrl> s. 
   This interrupts the boot sequence and places you in the Setup menu.
2. Once in the Setup menu, click ESC on the keyboard.
   The Select Boot Device menu opens.
3. In the Select Boot Device menu, select the CD-ROM drive as the boot device.

   The reboot from the CD installs BIG-IP version 4.1.1.  The process is complete when a message appears instructing you to remove the CD and press any key to reboot from the hard drive.

Boot the system from the hard drive

1. Remove the CD and press any key to reboot from the newly installed 4.1.1 system on the hard drive.
2. When you are prompted for a user name and password, enter root as the user name and default as the password.  The system logs you in and returns the prompt bigip_default:~#.

Convert the configuration data

use these steps to convert your configuration data to version 4.1.1:

1. Type the upgrade_config command with the -convert option, as follows:
   
   upgrade_config -convert
   
   This command unzips, de-tars, and converts the version 3.3.1 configuration files.  More specifically, it produces two versions of the configuration files, old (pre-4.1.1) and new (4.1.1).  All files are saved to their original paths with /var/tmp/otcu as the root.  The new files appear with the extension .new and may be examined in this location before being committed (copied to their working locations).
2. Type the upgrade_config command with the -commit option, as follows:
   
   upgrade_config -commit

   Note:   If you receive a message saying the configuration data cannot be retrieved, you will need to manually retrieve the data from the host where it was remotely stored, and return to the task Boot from the CD-ROM to install the software.  To retrieve the files, you can use the scp or ftp commands as follows:
   
   cd /var/tmp/otcu
   scp <remote_host>:/<path_to_backup_dir>/otcu.tar.gz
   
   or
   
   cd /var/tmp/otcu
   ftp <remote_host>
   ftp> get <path_to_backup_dir>/otcu.tar.gz
   ftp> quit

To copy any non-critical files to your updated system, you first need to use the gunzip and gtar commands on the file /var/tmp/otcu/non_crit_files.tar.gz, as follows:

cd /var/tmp/otcu
gunzip non_crit_files.tar.gz
gtar xvf non_crit_files.tar

Then manually copy the files to their separate locations.

---

Connecting to the IP Application Switch

This section describes how to connect to the BIG-IP® IP Application Switch^TM through either a null modem cable on the serial console, or a shielded ethernet cable on the administrative port.

Connecting with a null modem cable to the serial port

To connect through the serial port, you must have a DB9 null modem cable, and a vt100-capable terminal emulator available on a computer in close proximity to the IP Application Switch.  Use the following process to connect the IP Application Switch and the terminal emulator.

1. Connect the null modem cable to the IP Application Switch.  Use the DB9 port labeled Console on the IP Application Switch.
2. Connect the null modem cable to a serial port on the system with the terminal emulator.
3. Start the terminal emulator.  Set the emulator to 19200 baud and choose the correct serial device.
4. Turn on the IP Application switch.  It may take a moment for the terminal emulator to connect.
5. At the logon prompt, type the user name root with the password default.
6. From the command line, type config to run the First-Time Boot utility.

Configuring the IP Application Switch through the administrative interface

Use the following procedure to connect to the IP Application Switch through the administrative interface.  The administrative interface is a 10/100 port labeled MGMT.  You need a shielded Category 5 cable, and an administrative workstation with a 10/100 interface to connect to the IP Application Switch through the administrative port. You can configure the BIG-IP through the administrative interface with a web browser or with SSH.

1. Connect the shielded cable to the MGMT interface (3.1).
2. Connect the shielded cable to the 10/100 interface on the management workstation.
3. On the management workstation 10/100 interface, set up an IP alias of 192.168.1.1.  For more information on setting up an IP alias, consult your operating system documentation.
4. Turn on the IP Application Switch. Wait a few moments while the IP Application Switch boots.
5. Open a browser, or an SSH session, on the management workstation.
6. If you use a browser, connect to the following URL: https://192.168.1.245.
   If you use SSH, connect to the IP address 192.168.1.245.
7. At the logon prompt, type the user name root with the password default.
8. To configure the IP Application Switch from the browser, click the First-Time Boot utility link on the Configuration utility screen. To configure the IP Application Switch from SSH, type config.

New features and enhancements

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

Support for the IP Application Switch and the Server Appliance platforms

This release includes support for both the IP Application Switch and the Server Appliance hardware platforms.

SSL-to-server

This release includes an SSL-to-server feature. In some situations, your security needs may require you to encrypt traffic behind the virtual server. You can use this feature to re-encrypt traffic after it is processed by the BIG-IP. For more information about the SSL-to-server feature, see the BIG-IP Controller Reference Guide, version 4.1,  pages 3-61 to 3-63.

Enhanced Startup

This release includes enhancements that reduce the amount of time required to start the BIG-IP. In addition to booting more quickly, BIG-IP version 4.1.1 displays more relevant information on the terminal during boot up.  This information includes product identification, vendor identification, copyright notice, hardware configuration information, version information, and a login prompt.

 

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.  The purpose of the change is:

• To further reduce the need for separate UNIX utilities like netstart.
• To report statistics specifically for interfaces (netstat lumps interfaces, VLANS, and trunks).
• To enable other application interfaces, like iControl, to have access to this information.

For detailed information about enhanced interface statistics, see the BIG-IP Controller Reference Guide, version 4.1,  Displaying status for interfaces, page 2-4.

Health monitor enhancements

In this release, the WMI Data Collecting Agent (ISAPI) and the WMI Monitor Agent (WMIHttpAgent) have been enhanced to support WMI metrics for Windows Media Services.  For detailed information about the GetWinMediaInfo metrics and how to set them, see the BIG-IP Controller Reference Guide, version 4.1,  Configuring Windows Servers with WMI, pages 3-12 to 3-17.

Port mirroring

For the BIG-IP IP Application Switch only, you can copy traffic from any port or set of ports to a single, separate port.  This is called port mirroring.  The target port, called the mirror-to port, should have attached to it a sniffer device for debugging and monitoring. For detailed information about configuring port mirroring, see the BIG-IP Controller Reference Guide, version 4.1,  Port Mirroring, pages 2-22 to 2-23.

Spanning tree protocol support

For the BIG-IP IP Application Switch only, Spanning Tree Protocol (STP) is supported in this release. For more information about STP, see the BIG-IP Controller Reference Guide, version 4.1,  Spanning Tree Protocol (STP), pages 2-20 to 2-22.

Pool and rule support for Quality of Service (QoS)

The QoS standard is a means by which network equipment can identify and treat traffic differently based on an identifier.  As traffic enters the site, the QoS level can be set by the controller.  The BIG-IP can apply a rule and send the traffic to different pools of servers based on the Quality of Service level.

The BIG-IP can tag outbound traffic (the return packets based on an HTTP GET) based on the QoS value set in the pool.  That value is then inspected by upstream devices and given appropriate priority.  Based on a rule, the BIG-IP can examine incoming traffic to see if it has a particular QoS or ToS tag in the header. The BIG-IP can then make a rule-based load balancing decision based on that tag.

There are two main uses for this feature:

• Setting the QoS value on a packet based on which pool was selected for that packet.
  
  The following shows how to configure a pool for the first type of use. In this example, the QoS tag is set to 3 when sending packets to the client, and the tag is set to 4 when packets are sent to the server. 

  pool http_pool {
      link_qos to client 3
      link_qos to server 4
  }

• Making a load balancing decision based on the existing value within a packet.
  Use this syntax to configure a rule for this type of use:

  rule my_rule {
      if (link_qos > 2) {
          use (fast_pool)
      }     else {
          use (slow_pool)
      }
  }

Pool and rule support for IP Type-Of-Service (ToS)

Please see Pool and rule support for Quality of Service (QoS) for general information about this feature. 

There are two main uses for this feature:

• Setting the ip_tos (Type of Service) value on a packet based on which pool was selected for that packet.  This value is also called DiffServ.

  The following example shows how to configure a pool for the first type of use.  In this example, the ToS tag is set to 16 when sending packets to the client, and the tag is set to 16 when packets are sent to the server.

  pool http_pool {
      ip_tos to client 16
      ip_tos to server 16
  }

• Making a load balancing decision based on the existing value within a packet.

  The following example shows how to configure a rule for the second type of usage.

  rule my_rule {
      if (ip_tos == 16) {
          use (telnet_pool)
      }
      else {
          use (slow_pool)
      }
  }

Configurable protocol identifier for HTTP redirection

This release includes support for new syntax that allows you to configure a protocol identifier for the HTTP redirection feature. For example, if you want to specify an HTTPS site for www.yoursite.com, you would type fallback https://www.yoursite.com instead of the standard fallback syntax in the bigip.conf.

The following example shows default behavior for redirection to an HTTP URL:

fallback www.yoursite.com

The following example overrides the protocol identifier with an HTTPS prefix:

fallback https://www.yoursite.com

The following example overrides the protocol identifier with an FTP prefix:

fallback ftp://www.yoursite.com

Support for Session Initiation Protocol

This release of BIG-IP includes load-balancing support and Call-ID persistence for proxy servers that receive Session Initiation Protocol (SIP) messages sent through UDP. More specifically, this BIG-IP support provides a new SIP persistence type and the ability to display the contents of the SIP persistence hash table.

SIP is an application-layer protocol that manages sessions consisting of multiple participants. With SIP, applications can communicate with one another by exchanging messages through TCP or UDP. Examples of such applications are internet conferencing and telephony, or multimedia distribution.

Note:  While this release of BIG-IP supports SIP messages sent through UDP only, SIP messages sent through TCP will be supported at a later date.

Adding SIP Call-ID Persistence

SIP Call-ID persistence is a new type of persistence available for server pools. To add SIP Call-ID persistence to a server pool, you can specify the following:

• The name of the server pool (required).
• A timeout value for persistence records (optional). This timeout value allows the BIG-IP to free up resources associated with old SIP persistence entries, without having to test each inbound packet for one of the different types of SIP final messages. A default timeout value exists, which is usually 32 seconds. This timeout value is the window of time that a stateful proxy maintains state. If you change the timeout value, we recommend that the value be no lower than the default.

To add SIP Call-ID persistence, you can use either the Configuration utility or the bigpipe pool command.

To add SIP persistence using the Configuration utility, use the following procedure:

1. Start the Configuration utility.
2. Display the Pools screen.
3. Select a pool name.
4. Click the Persistence tab.
5. Click the button for SIP persistence.
6. Click the Apply button.

To add SIP persistence using the bigpipe pool command, specify the server pool name, the new SIP persistence attribute, and the SIP timeout value, as follows:

bigpipe pool <pool name> { persist_mode sip [sip_timeout <timeout>] }

Displaying the Contents of the Hash Table

To display the contents of the SIP persistence hash table, use the bigpipe command as follows:

bigpipe sip dump

Dynamic Connection Rebinding

Dynamic connection rebinding is a new feature for those virtual servers that are load balancing transparent devices such as firewalls or routers. Dynamic connection rebinding causes any connections that were made to a node address or service to be redirected to another node, if the original node transitions to a DOWN state. In this case, all connections to the failed node that were made through the virtual server are moved to a newly-selected node from the virtual server's pool. The new node is selected using the pool's load-balancing algorithm.

This feature does not apply to virtual servers for other types of devices because they usually involve application state between the client and server node, which cannot be recreated with a newly-selected node.

By default, dynamic connection rebinding is disabled.

To enable, disable, or show the status of dynamic connection rebinding, you can use either the Configuration utility or the bigpipe virtual command.

To manage dynamic connection rebinding using the Configuration utility, use the following procedure:

1. Start the Configuration utility.
2. Display the Virtual Servers screen.
3. Select the IP address for the virtual server. This displays the Properties page for that server.
4. Check the Enable Connection Rebind check box.
5. Click the Apply button.

You can also manage dynamic connection rebinding at the time that you add a virtual server. To do this, use the following procedure:

1. Start the Configuration utility.
2. Display the Virtual Servers screen.
3. Click the Add button on the top left of the screen.
4. Check the Enable Connection Rebind check box.

To manage dynamic connection rebinding using the bigpipe virtual command, type the following:

bigpipe virtual <ip>:<service> conn rebind enable
bigpipe virtual <ip>:<service> conn rebind disable
bigpipe virtual <ip>:<service> conn rebind show

List of reserved keywords

With this version of the BIG-IP software, there is a list of keywords that are reserved.  You cannot use any words in the list when you create configurations from the web-based Configuration utility, or from the command line.  For more information about the reserved keywords, see the list of reserved keywords.

Known issues

The following items are known issues in the current release.

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. (CR13788)

Netscape browser security messages
You may see browser security alert messages when you resize the Configuration utility window in Netscape browsers. (CR11933)

Netscape browser window resize
If you resize a wizard window in the Configuration utility window in Netscape browsers, you are returned to the opening page of the wizard. (CR13239)

Interface media settings
For best results, choose the Auto media setting. In some cases, devices configured for Auto media are incompatible and the proper duplex setting will not be negotiated between these devices. In these cases you may need to set the media settings to the same speed and duplex on both the BIG-IP and the corresponding switch or host. (CR16145)

Changing the static route on a node
If you change the static route to a node you are load balancing, you should reload the BIG-IP configuration. To reload the BIG-IP configuration, use the bigpipe load command. (CR15769)

Gateway fail-safe with active-active mode
Gateway fail-safe is not supported in active-active mode. (CR14880)

Cannot remove all monitors to create a monitorless state
A base ICMP monitor is always associated with each node. This monitor cannot be removed. (CR15512)

tcpdump shows no ICMP packets when pinging a virtual server
The tcpdump utility does not display ICMP packets when you ping a virtual server from a client. (CR16203)

Destination IP address and name of service required for transparent-mode monitors
When adding a monitor using transparent node, you must now specify the destination IP address and name of service. Otherwise, an error message is displayed. BIG-IP version 4.0 or 4.1 customers who are upgrading to version 4.1.1 might need to modify the bigip.conf file to add an entry for the destination IP address and name of service. This entry should be in the format dest <ip address:service>. (CR17506)

Hostname field in First-Time Boot utility
In the browser-based First-Time Boot utility, the Hostname field is currently limited to 32 characters. (CR17465)

Warning message displayed during upgrade
During an upgrade from the crypto version of BIG-IP 4.1 to the crypto version of BIG-IP 4.1.1, a warning message might be displayed, stating that the file /shlib/libOB.so cannot be opened. This message is harmless and should be ignored. (CR17546)

Default values in SSL proxy definition
When an SSL proxy is defined using the Configuration utility, the BIG-IP adds entries for the default values into the bigip.conf file. When an SSL proxy is defined using the command-line interface, no default values are entered into the file. (CR17464)

Adding SIP persistence when modifying a pool
You cannot add SIP persistence when using the modify keyword with the bigpipe pool command. (CR17493)

Permission error displays when using First-Time Boot utility
When you open the First-Time Boot utility from the Welcome screen, BIG-IP generates an error message if your password contains a semicolon. To eliminate the message, remove the semicolon from the password. (CR17352)

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

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 0.0.0.0:0 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 0.0.0.0 any_ip enable
   If you want to change the default timeout for this setting, use this syntax:
   bigpipe virtual 0.0.0.0 any_ip timeout <seconds>
   For example, if you want to change the default timeout to 5 seconds, type this command:
   bigpipe virtual 0.0.0.0 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.