Installing the upgrade

To apply this upgrade, you need the BIG-IP Controller 4.0 Upgrade CD-ROM.  You can apply this upgrade to version 3.3.1 and later.  If you are upgrading a version released before 3.3.1, you must first upgrade to version 3.3.1.  The upgrade process on the CD-ROM detects which version of the BIG-IP Controller software you are using.  If an upgrade to a 3.3.1 version is required, version 3.3.1 is installed and then the 4.0 version of the software is installed.  Do not apply previous PTFs; they are included in this installation.  If you use the GLOBAL-SITE Controller in conjunction with the BIG-IP Controller do not upgrade to version 4.0. 

For detailed information about installing the upgrade from the BIG-IP Controller 4.0 Upgrade CD-ROM, see the technical note BIG-IP Controller version 4.0 Installation and Configuration Upgrade.

New features and enhancements

3-DNS on the BIG-IP Controller
If you purchase the 3-DNS module with this release of the BIG-IP Controller, you can combine on one controller, the full wide-area load balancing functionality of the 3-DNS Controller with the local-area load balancing functionality of the BIG-IP Controller on one controller.  An advantage you gain with this configuration is the combined configuration requires less rack space.  For more information, see the 3-DNS on the BIG-IP Controller section.

OneConnect^TM content switching with HTTP KeepAlives
There are two major benefits of the BIG-IP Controller OneConnect feature.

• Using the KeepAlive functionality on your Web servers
  With the new support for HTTP 1.1 Persistent Connections, or KeepAlives, added in this release, you can change settings on your web servers to take advantage of this feature.

  For more information, see the HTTP Keep-Alive Support.

• Aggregating client requests by configuring a SNAT for inbound traffic
  Another benefit of this feature is client aggregation.  You can aggregate client connections by configuring a SNAT for inbound requests.  This reduces the number of connections from the BIG-IP Controller to back-end servers and from clients to the BIG-IP Controller.

Support for one IP network configuration with layer 2 forwarding
The layer 2 forwarding functionality in this release provides the ability to bridge packets between VLANs on the same IP network by creating a VLAN group.  For more information, see the BIG-IP Reference Guide, VLAN group.

HTTP Redirect pool property
The HTTP redirect feature adds the ability to redirect clients to another site or server or to a 3-DNS Controller when the members of a pool they were destined for are not available.  For more information, see the BIG-IP Reference Guide, HTTP Redirect (specifying a fallback host).

Load balance any IP protocol
The load balance any IP protocol feature provides the ability to load balance IP protocols other than TCP or UDP.  This means that you can load balance VPN client connections across a number of VPNs, eliminating the possibility of a single point of failure.  For more information about configuring any IP load balancing, see the BIG-IP Administrator Guide, Using IPSEC with VPN Gateways.

Link aggregation and link fail-over
The link aggregation feature provides the ability to combine multiple Ethernet links into a single trunk.  This allows you to increase available bandwidth incrementally and improve link reliability.  For more information, see the BIG-IP Reference Guide, Link aggregation and fail-over.

Support for Quality of Service and Type of Service
The BIG-IP Controller can load balance traffic based on Quality of Service or Type of Service.  The controller can also set the QoS and ToS field on outbound traffic if it is not already defined.  Differentiation in service levels can set your web system or service offering apart from your competition. The BIG-IP Controller further enhances website differentiation by supporting the Quality-of-Service (QoS) and Type-of-Service (ToS) standard.  With QoS and ToS your site can recognize and provide differing levels of service.  The BIG-IP Controller can direct traffic that has been identified by the policy manager with different priorities.  These priorities can then be sent to the appropriate resources.  In the reverse, the controller can set the priority identifier on the traffic from specific web resources.  The policy manager then can manage this traffic.  In either case, your business resources can be appropriately matched to your business requirements.  For more information about configuring load balancing based on Quality of Service and Type of Service, see the Pool and rule support for Quality of Service (QoS) and Pool and rule support for IP Type-Of-Service (ToS).

On-the-fly content converter
The on-the-fly content converter provides a simplified method of converting URLs to ARLs that point to the Akamai Freeflow Network^TM.  For more information, see the BIG-IP Reference Guide, Configuring a content converter.

SNAT automap feature
The SNAT automap feature provides the ability to automatically map a SNAT to a BIG-IP Controller VLAN or self IP address.  This simplifies the ability to load balance multiple internet ISPs.  For more information, see the BIG-IP Reference Guide, Enabling and disabling SNAT automapping.

Site configuration wizards
This release includes several configuration wizards that simplify the configuration of the BIG-IP Controller.  These wizards include the Basic Site Configuration wizard and the Secure Site Configuration wizard.  Wizards are only available on the BIG-IP HA Controller, the BIG-IP HA+, the BIG-IP Enterprise, and the BIG-IP LoadBalancer Controller.  For more information, see the Web-based Configuration utility enhancements section.

Health monitors
Simplified the process of creating and associating health monitors (EAVs and ECVs) with network devices.  This release contains predefined templates that you can use to define many different types of monitors.  You can associate a monitor with a single node or many nodes.  For more information, see the BIG-IP Reference Guide, Monitors.

Performance monitors
You can use a performance monitor to gather statistics and make load balancing decisions with the Dynamic Ratio load balancing method.  You can implement Dynamic Ratio load balancing on Windows RealNetworks RealServer platforms, Windows platforms equipped with Windows Management Instrumentation (WMI), and on platforms that support simple network management protocol (SNMP).  For more information, see the BIG-IP Reference Guide, Configuring servers and the BIG-IP Controller for Dynamic Ratio load balancing.

Default IP address configuration
The BIG-IP Controller ships with a default configuration that allows you to configure the controller remotely by command line or from a web-based user interface.  The default configuration provides an RFC 1918 IP address on the default internal VLAN.  You can connect to the default IP address and log on to the controller with the default user name and password.  This provides the ability to run the First-Time Boot utility from a remote SSH client or remotely from a browser.  For more information, see the BIG-IP Installation Guide, Accessing the controller through the default IP address configuration.

Setting the MAC masquerade address
The MAC masquerade address is now set for a VLAN, not an interface as in previous versions of the BIG-IP Controller.  The MAC address for a VLAN is the MAC address of the first interface to be mapped to the VLAN, typically 4.1 for external and 5.1 for internal.  For more information on setting the MAC Masquerade, please refer to the VLAN section of the BIG-IP Reference Guide, Configuring the BIG-IP Controller, or the VLAN section of BIG-IP Reference Guide, bigpipe Command Reference.

Web-based Configuration utility enhancements
This release includes a number of improvements to the web-based Configuration utility.  There are new wizards for tasks such as adding virtual servers, rules, and monitors.  A new tab-style navigation system simplifies navigation in the utility.  In addition to the wizards for completing simple tasks, this release includes several configuration wizards that simplify creating a configuration for the BIG-IP Controller.  These wizards include the Basic Site Configuration wizard, the Secure Site Configuration wizard, and the Active-Active Configuration wizard.

Configuring and using the new software

This section contains information about new features that have not been documented in the manuals.

Using the BIG-IP Controller with the 3-DNS module
The BIG-IP Controller with the 3-DNS module features an integrated home screen.  When you connect to the controller with a browser, the first page you see is the BIG-IP Controller with 3-DNS module home screen.  The Configuration utility section of the home screen includes the following links.

• Configure your BIG-IP Controller using the Configuration utility
  Click this link to open the Configuration utility for the BIG-IP Controller software.
• Configure your 3-DNS Controller using the Configuration utility
  Click this link to open the Configuration utility for the 3-DNS module.
• First-Time Boot utility
  Click this link if you want to run the web-based First-Time Boot utility again.

The On-Line Documentation section of the home screen includes links to the following documentation.

• BIG-IP Controller documentation
  This section includes links to the BIG-IP Installation Guide, BIG-IP Administrator Guide, and BIG-IP Reference Guide.  In addition to the links to the guides, there is a link to the release notes.
• 3-DNS module documentation
  This section includes links to the 3-DNS Administrator Guide and the 3-DNS Reference Guide.  In addition to the links to the guides, there are links to the release notes and man pages.

Setting up fail-over for a BIG-IP Controller with the 3-DNS module installed
You can set the controller to fail over if the 3-DNS service stops running. To do this, you must set the Common.Bigip.Failover.On3dnsfail key to 1. When you set this key to 1, the BIG-IP Controller fails over when the 3-DNS service (3dnsd) is stopped, typically by issuing the 3ndc stop command.  This setting applies only to a redundant pair of BIG-IP Controllers, each running the 3-DNS module, and having the shared interface address registered with InterNIC.

Changing feature sets with the combined product version of the BIG-IP Controller
The BIG-IP Controller Load Balancer, FireGuard, and Cache Load Balancer feature sets are now on a single platform.  You can select which feature set you want to use when you run the First-Time Boot utility.  You can change the feature set at a later date by rerunning the First-Time Boot utility and selecting a different feature set.  It is important to note that you must reconfigure the controller if you change the feature set.

Configuring network SNATs
You can now specify a SNAT where the original address is a network.  For example, if you want to configure a SNAT translation to 192.168.2.45 for all addresses in the Class C network 192.168.1, type the following commands.

snat map 192.168.1.0 to 192.168.2.45
snat 192.168.1.0 netmask 255.255.255.0

The netmask for an original address is applicable only when it specifies a network when combined with the original address.  In other words, if the netmask specified for the original address results in the host portion of the original address being all zeros, then the netmask is saved; otherwise it is ignored.

Support for IEEE 802.1p Quality of Service (QoS) and Type of Service (ToS)
The BIG-IP Controller can load balance traffic based on the Quality-of-Service (QoS), or Type-of-Service (ToS) field.  The BIG-IP Controller also has the ability to set the QoS or ToS field, on outbound traffic, if it is not already defined.

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 Controller can apply a rule and send the traffic to different pools of servers based on the Quality of Service level.

The BIG-IP Controller 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 controller can examine incoming traffic to see if it has a particular QoS or ToS tag in the header. The controller can then make a rule-based load balancing decision based on that tag.

There are two main usages 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 usage. In this example, the QoS tag will be set to 3 when sending packets to the client, and the tag will be 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 based on the existing value within a packet.

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

  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 usages 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 shows how to configure a pool for the first type of usage.  In this example, the ToS tag will be set to 16 when sending packets to the client, and the tag will be 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 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)
      }
  }

Using the else if construction in rules
The rule syntax on the BIG-IP Controller now supports else if constructions.  In many cases, this simplifies the syntax you are required to type to create a rule.  For example, the following rule contains the new else if syntax.

pool gif_pool {member 10.0.3.20:80 member 10.0.3.21:80 }
pool http_pool {member 10.0.3.22:80 member 10.0.3.23:80 }
pool avi_pool {member 10.0.3.24:80 member 10.0.3.25:80 }
pool main_pool {member 10.0.3.26:80 member 10.0.3.27:80}

rule content_rule {
   if ( http_uri ends_with ".gif" ) {
      use (gif_pool)
   }
   else if ( http_uri ends_with ".html" ) {
      use (http_pool)
   }
   else if ( http_uri ends_with ".avi" ) {
      use (avi_pool)
   }
   else {
   use (main_pool)
   }
}

This is an example of how you might have created the same rule with the old syntax:

rule <rule_name> {
   if ( <expr1> ) {
      use (pool1)
   }
   else {
   if ( <expr2> ) {
         use (pool2)
      }
      else {
         if ( <expr3> ) {
            use (pool3)
         }
      }
   }
}

Information vital to users of previous versions of the BIG-IP Controller software

This section explains how new features change the way you configure the BIG-IP Controller software.

File system reorganization

The BIG-IP Controller file system has been reorganized in order to put the most commonly used configuration files into a separate partition, /config.  Additionally, a new file system feature has been implemented in order to increase the resilience of the BIG-IP Controller in the unlikely event of failure.  All file systems are read-only by default, and automatically switched to read-write when writes are performed.  This substantially improves the robustness of the BIG-IP Controller, and its resistance to corruption from catastrophic events such as power failure.

Startup changes

You can see two distinct differences during initial startup of the BIG-IP Controller.  The first is after initial installation, you will note that running the First-Time Boot utility is no longer required to connect remotely to the controller.  A new default controller configuration discussed in these release notes makes this possible. 

The login after initial installation is user name: root and password: default.

The second primary change is that you can start and stop the BIG-IP Controller daemons with the bigstart utility.  See the bigstart man page for more information on starting and stopping daemons.

Automatic last hop feature

In previous versions of the BIG-IP Controller, you could specify a pool of devices for which you wanted the BIG-IP Controller to maintain last hop information.  With this version of the BIG-IP Controller, the last hop feature is turned on automatically.  You can turn this feature off globally if you want to create independent last hop pools with the same behavior as the previous versions of the software.

Split configuration files

In previous versions of the BIG-IP Controller, low level and high level configuration information was stored in one file, the bigip.conf.  In this version of the BIG-IP Controller, the low level configuration and the high level configuration information is kept in separate configuration files.  The bigip_base.conf file contains basic network connectivity configuration data, which includes interfaces, VLANs, and self IP address configuration information.  The base configuration file is loaded first, and can be loaded and saved independently.  The bigip.conf file contains all of the remaining configuration information for the BIG-IP Controller, which includes virtual server, node, SNAT, NAT, pool, rule, proxy, monitor, monitor association, and global value configuration data.

Command line changes

As part of the split of the configuration files into a base file and a high level file, the behavior of the bigpipe save and bigpipe load commands has changed from previous versions of the BIG-IP Controller.  In previous versions, you could type the command bigpipe -s to store the entire configuration to a file, usually /etc/bigip.conf.  In version 4.0, the command bigpipe save stores the high level configuration, typically to /config/bigip.conf.  You can use a new command, bigpipe base save, to store the low level configuration, typically to /config/bigip_base.conf.

• New bigpipe save commands
  When the command bigpipe save is issued, bigpipe first copies the file /config/bigip.conf to /config/bigip.conf.bak, and then stores the current high level configuration to /config/bigip.conf.

  Similarly, when the command bigpipe base save is issued, bigpipe first copies the file /config/bigip_base.conf to /config/bigip_base.conf.bak, and then stores the current low level configuration to /config/bigip_base.conf.

  To reduce the risk of losing network connectivity if there is a problem when loading /config/bigip_base.conf, a known good low level configuration is stored in the file /config/default_base.conf.  The bigpipe base save command creates the default_base.conf file if it does not exist.

  As with the old -s command, you can specify a file name or '-' for standard output for both the bigpipe save and bigpipe base save commands.

• New bigpipe load command
  The command bigpipe load resets both the high level and low level configuration, loads the low level configuration from /config/bigip_base.conf, and then loads the high level configuration from /config/bigip.conf. As with the previous -f command, you can specify a file name to load.  There is no base load command.  To load just the low level configuration, use the command b load /config/bigip_base.conf. If there is a problem when loading the bigip_base.conf file, bigpipe automatically loads the low level configuration from /config/default_base.conf.
• New bigpipe merge command
  The command bigpipe merge <file> replaces the previously used -l command. Use bigpipe merge to add to the currently running BIG-IP Controller configuration. As with the old -l command, the low or high level configuration are not reset.
• New bigpipe list command
  The command bigpipe list replaces the previously used bigpipe -s command (with no file name).  The bigpipe list command writes the current high level configuration to standard output.  The command bigpipe base list writes the current low level configuration to standard output.

New BIG-IP Global Variables

Previous versions of the BIG-IP Controller used sysctl to modify many global system properties.  In version 4.0, these variables are now accessed using the bigpipe global command instead of sysctl.

Synchronizing configurations for upgrades only

After you have upgraded both controllers in a redundant system, you must run the config_remote utility on both controllers before you can synchronize their configurations. The config_remote utility prompts you to configure connections between BIG-IP Controllers.

HTTP Keep-Alive Support

With the new support for HTTP 1.1 Persistent Connections, or KeepAlives, added in this release of the BIG-IP Controller, you can change settings on your web servers to take advantage of this feature. Prior to BIG-IP Controller version 4.0, if you wanted to use content switching features such as HTTP rules or cookie persistence, you had to disable HTTP KeepAlives on the web server in order to assure proper operation.  The reason for this was that each TCP connection from the client could only retrieve content from one server, because only the first request for content within the TCP connection was examined to see which server is required.  With this version of the BIG-IP Controller, all requests for content are examined, even multiple requests within the same TCP connection.  This means that you are no longer restricted to disabling KeepAlives on your servers and can enable it if you want to use this feature.  Typically, you will see a significant increase in network efficiency when you enable KeepAlives.

Layer 2 forwarding

The layer 2 forwarding features in the BIG-IP Controller allow you to configure the same network on multiple VLANs with the BIG-IP Controller intelligently forwarding traffic between them.  This means you can install a controller in a network without segmenting it into two separate IP networks.

Bridging with VLANs

The bridging functionality supported by the BIG-IP Controller allows you to configure a BIG-IP Controller with multiple interfaces to function like a layer 2 switch.  This functionality allows the BIG-IP Controller to interoperate with other VLAN aware switches.  These features also reduce the number of networks needed to configure a BIG-IP Controller with multiple interfaces.

HTTP redirect pool property

With this new feature, if all web servers in a pool are unavailable, the BIG-IP Controller can redirect clients to another site.  This could either be a site being controlled by a wide-area load balancer, such as the 3DNS Controller, or a separate pool of web servers either on the same BIG-IP Controller, or at a completely different location altogether.  The exact mechanism used is a 302 Object Found redirection.

Load balance any IP protocol

With this new feature, you can now load balance IP protocols other than TCP and UDP, through both translating and non-translating virtual IPs.  A typical use of such a feature would be to load balance multiple VPN gateways in an IPSEC VPN sandwich, using non-translating VIPs.  One important point to note is that although address translation of such protocols may optionally be activated, some protocols (such as IPSEC AH mode) rely on the IP headers remaining unchanged.  In such cases, non-translating network virtual servers should be used.  By default this functionality is disabled on a virtual server, but may be enabled through the web-based Configuration utility or bigpipe.

Link aggregation and fail-over

With link aggregation and fail-over, the BIG-IP Controller now provides high availability and load balances at every layer of the OSI model.  This feature, compatible with other link aggregation protocols, allows you to set up predefined trunks of interfaces to act as one interface.  Network traffic is load balanced across these links, in effect removing the interface's constraints as a limiting factor on the BIG-IP Controller.  Additionally, when an interface fails at the physical layer (for example when the peer port loses carrier), network traffic is seamlessly rebalanced over the remaining links in the group, without interruption.  Use of this feature requires you to have a link-aggregation capable switch or peer.

SNAT automap feature

With this version of the BIG-IP Controller, you can automatically configure secure network address translation (SNAT) on a VLAN.  In previous versions of the BIG-IP Controller, SNATs were configured to be performed on a set of IP addresses or all addresses (in the case of a default SNAT).

When you enable this feature on a VLAN, any connection coming from that VLAN will go through a SNAT.  For example, by enabling SNAT automap on the internal VLAN, a SNAT is performed on any connection made from that VLAN.  Before you enable SNAT automap, you must configure a floating self IP address for the SNAT address.  The controller uses the floating self IP address as the translation address for traffic, and it must be configured to enable SNAT automap.

Monitor configuration enhancements

With this version of the BIG-IP Controller, you configure node checks, ECV service checks, and EAV service checks in an entirely new way.  In past releases the type of check, the address to check, and the send and receive strings were all contained in the file /etc/bigd.conf.  One line in the file was required for each address to be checked.  The timeout period and check interval were specified separately on a per service port basis.  In this release, the tping_svc, timeout_svc, tping_node, and timeout_node commands are not supported.  Their function is now accomplished through using monitor templates.  The monitor information is now stored in the file /config/bigip.conf.

In this release the monitor template contains the type of check, any send and receive strings and the check interval and timeout period.  Servers or services that are to be checked using a monitor template are simply listed in a command associating them with the monitor template.  Basic monitor templates from which all user defined monitor templates must derive are supplied with the BIG-IP Controller.  You can use some of the supplied monitors directly, while you can only use others as a basis to create your own monitor templates.

Node checking using aliases, that is, the state of nodes a, b, and c, depends on the state of node d is now done with monitors.  The address to check is placed in the monitor template and the nodes that are to depend on that address are associated with the monitor template.  You can also alias service port checks in this manner.  The alias command of prior releases is no longer supported.

As in the past, you can supply external monitoring programs.  In this release you can pass arguments to those programs using the environment as well as using the command line interface that prior releases use.

Default controller configuration

After installation, the controller boots into a default configuration that provides network and web access.  One of two IP addresses is assigned based on IP networks found and whether any IP conflicts are discovered.  These two addresses are 192.168.1.245 and 192.168.245.245.  Passwords are set to default for the root account and for a web account that also uses the user name root.  Both of these passwords should be changed as soon as possible.  You can use either the terminal based or web based First Time Boot utility to complete the basic configuration which includes setting new passwords.

The First-Time Boot utility (config) has been changed to accommodate VLAN configuration.  For classic BIG-IP Controllers (that is controllers with two interface cards) this adds a bit of complexity to the setup.  You will set the IP addresses and attributes on the VLAN and assign an interface card to that VLAN.  The two VLANs are typically named external and internal and typically correspond to the exp0 and exp1 interfaces on previous versions of the software.

Configuration utility enhancements

The ability to save and restore configurations and to synchronize a redundant controller configuration has been completely redesigned.  Configurations are saved in User Configuration Sets (UCS) and the transport mechanism to redundant controller uses a CORBA connection.  The UCS contains all files that are considered to be configuration files along with the information on how to restore them.  The actual contents of a UCS is specified in the database and is user extensible.  For more information see the description in the users guide for the bigpipe config command.  You must perform basic configuration of each controller prior to attempting a synchronization operation.

List of reserved keywords

With this version of the BIG-IP Controller, 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.

Supported browsers for the Configuration utility

As of this release, the supported browser versions for the BIG-IP Controller are:

• Netscape Communicator 4.7x
• Internet Explorer 4.02 and greater

Service checks

With this release of the BIG-IP Controller, you no longer set service checks from the Global Node Port Properties screen.  To configure service checks, click Monitor in the navigation pane.  For more information on service checks, see the online help and the BIG-IP Reference Guide for Monitors.

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.

Known issues

The following items are known issues in the current release.  For additional issues discovered after the release of this version of the software, please connect to the technical support web site (tech.f5.com) with the following URL (/home/relnotes.html).