Original Publication Date: 09/30/1999
These release notes cover changes since version 2.0.4. This release is recommended, but not mandatory, for all customers. It contains significant new features. This release applies to both US and International versions of BIG/ip HA and BIG/ip LB.
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:
tar -xpf bigipv21hadomkit.f5.tar (Domestic HA and HA+)
tar -xpf bigipv21lbdomkit.f5.tar (Domestic LB)
tar -xpf bigipv21intlkit.f5.tar (International HA/LB)
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:
Customers upgrading LB or International versions of the BIG/ip Controller now have the opportunity to configure either a Telnet or FTP server during the upgrade, or 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, enter the appropriate command:
During the final step in an International upgrade, you are prompted for the type of system you are upgrading: single or redundant. If you choose redundant, you are prompted to type in the user ID and password for accessing the BIG/ip web server. This information is used when synchronizing configurations (configsync).
The checksums for this release are available in a file called sums, which can be downloaded from the FTP site.
Some of the enhancements provided in this release require special configuration. Please refer to the sections below for more information about additional configuration.
Before you can use bigpipe configsync or the F5 Configuration utility to synchronize domestic HA and HA+ BIG/ip Controllers, you must first run the config_failover utility. In previous versions of the BIG/ip Controller, a number of files were configured manually. The config_failover utility automates these tasks:
To run the config_failover utility, type the following command from the command line:
After you run the utility, you can run bigpipe configsync or use the F5 Configuration utility to synchronize the controllers.
Note: For information about configuring 802.1q VLANS from the command line and by editing configuration files, see Setting up 802.1q VLAN trunk mode, page 5-52, in the BIG/ip Controller Administrator Guide.
Note: You can only enable or disable VLAN tags in the F5 Configuration utility. VLAN tags must be configured by adding VLAN tag values to the /etc/netstart file (and the /etc/bigip.interfaces file for redundant configurations). The F5 Configuration utility can only enable or disable VLAN tags that have been configured in those files.
Note: For information about configuring ECV through transparent nodes from the command line, see Configuring ECV for transparent nodes, page 5-3, in the BIG/ip Controller Administrator Guide.
New ECV syntax facilitates using ECV with transparent nodes. With it, you can test whether a transparent node is functioning properly by retrieving content through it. You can enable this feature in the F5 Configuration utility or from the command line. This section describes how to enable this feature from the F5 Configuration utility.
Note: You must have at least one wildcard virtual server configured in order to configure ECV through a transparent node.
Note: You must enable Transparent Node mode on the BIG/ip Controller in order to use this option. See Activating Transparent Node mode, page 4-6, in the BIG/ip Controller Administrator Guide.
To set up ECV through a transparent node using the F5 Configuration utility
There are two procedures required to set up ECV through a transparent node. First, set up the frequency and timeout for the port:
After you configure the frequency and timeout settings for the port, set the specific settings for the transparent node:
If you use destination address affinity, you must set a limit on the maximum number of sticky entries that can accumulate on a server.
Set the system control (/etc/rc.sysctl) variable bigip.max_sticky_entries to the maximum number of sticky entries you want to allow to accumulate on the BIG/ip Controller. When the maximum number is reached, the BIG/ip Controller stops accumulating sticky persistence entries. By default, this variable is set to 2048.
Note: For information about configuring destination address affinity (sticky persistence) from the command line, see Using destination address affinity (sticky persistence), page 5-14, in the BIG/ip Controller Administrator Guide.
To set the system control variable bigip.max_sticky_entries in the F5 Configuration utility
Note: In order to prevent sticky entries from clumping on one server, use a static load balancing mode, such as Round Robin.
There has been a significant change in the way Wildcard VIPs are declared in order to allow port translations. In the past, when a wildcard VIP was defined, the port on the node was considered the service check port, not the translation port. For example:
bigpipe vip 0.0.0.0:0 define 10.1.1.1:80 10.1.1.2:80
In the above declaration, the routers 10.1.1.1 and 10.1.1.2 are service checked on port 80 to determine if they are up or down. In versions prior to 2.1, for wildcard vips only, this port was not considered the port to translate to, and the idea of translating all incoming ports to 80 on the node was not available.
Starting with version 2.1, the port on the node controls whether translation is enabled. So, if you want the port to stay the same (no translation), the port on the node should be declared as port zero:
bigpipe vip 0.0.0.0:0 define 10.1.1.1:0 10.1.1.2:0
Service checking wildcard virtual servers
Service checking these nodes requires a new entry in the /etc/bigd.conf file. For example, using the last example, the entry would look like:
simple 10.1.1.1:0 80
Note that the node is a port zero (:0) node now, and so the service check intervals need to be declared for port zero. For example, in the /etc/bigip.conf file, the settings might look like this:
tping_svc 0 5
timeout_svc 0 16
Retaining your existing configuration
In the event that you have many wildcard virtual servers configured, and you want to retain your settings, you can retain the old behavior by setting the sysctl variable bonfire_compatibility_mode:
sysctl -w bonfire_compatibility_mode=1
You must also add this entry to the /etc/rc.sysctl file in order to retain the setting after rebooting the BIG/ip Controller.
New with version 2.1 is the concept of User Administration via the F5 Configuration utility. The tool can give users full, partial, or read-only access to the BIG/ip Controller.
A BIG/ip Controller that has been upgraded to version 2.1 could possibly have more than one or two users (other than admin and support) located in the /var/f5/httpd/basicauth/users file. The upgrade process, as well as the reconfig-httpd utility, makes these additional users read-only users.
If you want to promote those existing users to full or partial access privileges, the web-admin account holder can navigate to the User Administration page of the F5 Configuration utility and add the users in again with the appropriate access level.
SSL Session ID Persistence
The LB version of the BIG/ip Controller does not support SSL session ID persistence. You cannot use the special ssl variation of the bigpipe vip command on the LB version of the BIG/ip Controller.
The LB version of the BIG/ip Controller does not support Cookie Persistence. You cannot use the special cookie variation of the virtual server command on the LB version of the BIG/ip Controller.
Load balancing modes
The LB version of the BIG/ip Controller does not support Observed, Priority, or Predictive load balancing modes.
The LB version of the BIG/ip Controller does not support ECV, EAV, or gateway fail-safe. You cannot use the active, ssl, reverse, external, or transparent keywords in the /etc/bigd.conf file on the LB version of the BIG/ip Controller.
Note: The only keyword allowed in the /etc/bigd.conf file is simple, which you can use to configure simple ping for wildcard ports.
The LB version of the BIG/ip Controller does not include SSH. If skipping over the SSH configuration, the First-Time Boot utility offers to configure daemons for Telnet and FTP. The configsync option on the LB version of the BIG/ip Controller uses HTTP (international) or HTTPS (domestic).
The LB version of the BIG/ip Controller includes daemons for Telnet and FTP, in order to support configuration without SSH. These daemons are started by inetd and support TCP Wrappers for host access control.
Filtering and Rate Shaping
The LB version of the BIG/ip Controller does not support IP filtering, rate filtering, or rate shaping.
The sample pingers provided with the BIG/ip Controller all use the same preliminary scheme as the EAV pingers from previous versions of the BIG/ip Controller. The only changes required are the supplementary arguments specific to the protocol. These sample pingers do not use the port argument at this time.
The FTP pinger
The FTP pinger requires three arguments: a full path to the file on any given server, a user name, and a password. Here are example bigd.conf entries:
external 10.0.0.57:21 /usr/local/lib/pingers/FTP_pinger "/pub/demo/file.txt anonymous email@example.com"
external 10.0.0.62:21 /usr/local/lib/pingers/FTP_pinger "/pub/spool/incoming.doc carol carols_password"
The FTP pinger attempts to download the specified file to the /var/tmp directory. A successful retrieval of any file with the name indicated is considered a successful ping.
The POP3 pinger
The POP3_pinger for Post Office Protocol requires only two arguments, a user name and a password. This check is considered successful if it successfully connects to the server, logs in as the indicated user, and logs out again. Here are example bigd.conf entries:
external 10.0.0.57:109 /usr/local/lib/pingers/POP3_pinger "alice alices_password"
external 10.0.0.57:109 /usr/local/lib/pingers/POP3_pinger "bob bobs_password"
The SMTP pinger
The SMTP_pinger for mail transport servers requires only one argument, a string identifying the server from which the EAV is originating. This is an extremely simple pinger that checks only that the server is up and responding to commands. It counts a success if the mail server it is connecting to responds to the standard SMTP HELO and QUIT commands. Here is an example bigd.conf entry:
external 10.0.0.57:25 /usr/local/lib/pingers/SMTP_pinger "firstname.lastname@example.org"
The NNTP pinger
The NNTP_pinger for Usenet News requires only one argument, a newsgroup name to check for presence. If the NNTP server being queried requires authentication, the username and password can be provided as additional arguments. This pinger counts a success if it successfully retrieves a newsgroup identification line from the server. Here are example bigd.conf entries, the second showing the optional login parameters:
external 10.0.0.57:119 /usr/local/lib/pingers/NNTP_pinger "comp.lang.java"
external 10.0.0.62:119 /usr/local/lib/pingers/NNTP_pinger "local.chat username password"
The SQL pinger
The SQL_pinger for SQL requires five arguments: an IP address, port, database, user, and password. The service check performs an SQL login to the specified SQL database. If the login is successful, the service is considered up. Here is an example bigd.conf entry for the SQL pinger:
external 192.168.1.1:1433 /usr/local/lib/pingers/SQL_pinger "database user1 password"
To configure bundled EAV pingers in the F5 Configuration utility
Entering external program arguments in the F5 Configuration utility
Each bundled pinger requires specific external program arguments. The entries required by the F5 Configuration utility are described in this section.
The FTP pinger
The FTP pinger requires three arguments: a full path to the file on any given server, a user name, and a password:
/pub/demo/file.txt anonymous email@example.com
/pub/spool/incoming.doc carol carols_password
The FTP pinger attempts to download the file indicated to the /var/tmp directory. A successful retrieval of any file with the name indicated is considered a successful ping.
The POP3 pinger
The POP3_pinger for Post Office Protocol requires only two arguments, a user name and a password. It does not check content on the server and is considered successful if a connection to the server is established, the indicated user logs in, and then logs out again. Here are the arguments required:
The SMTP pinger
The SMTP_pinger for mail transport servers requires only one argument: a string identifying the server from which the EAV is originating. This pinger checks only that the server is up and responding to commands. This pinger is considered successful if the mail server responds to the standard SMTP HELO and QUIT commands. Here is the argument required:
The NNTP pinger
The NNTP_pinger for Usenet News requires only the newsgroup name for which you want to check. If the NNTP server being queried requires authentication, you can provide the user name and password as additional arguments. This pinger is considered successful if it successfully retrieves a newsgroup identification line from the server. Here are example arguments, the second showing the optional login parameters:
local.chat username password
The SQL pinger
The SQL_pinger for SQL requires three arguments: database, user, and password. The service check performs an SQL login to the specified SQL database. If the login is successful, the service is considered up. Here is an example argument for the SQL pinger:
database user1 password
Modifying the sample scripts
These pingers are simple Perl scripts which can be easily modified. A very complex example could be one using the SMTP pinger to send an email into a network and, later, using the POP3 pinger to retrieve it. All of the sample scripts conform to the Perl Networking Library standards.
The vendor MIB included with the BIG/ip Controller version 2.1 contains the following two changes.
The first change to the vendor MIB changes the ready status and maintenance status. The following table describes these changes.
This change corrected an error in the interpretation of this status:
The second change to the vendor MIB changes the status of several entries. The states for the following entries have been expanded.
These expanded status modes apply to the following status entries:
The following issues are known issues with the BIG/ip Controller version 2.1.
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 version 4.61. When you see this error message, use this procedure to get a new certificate:
Gateway pingers and configsync
The gateway pinger entry in the bigd.conf is overwritten when you run the bigpipe configsync all command, or if you sync the configuration from the F5 Configuration utility. If you sync the configuration on a redundant system running gateway fail-safe, you must manually restore the gateway pinger entry in the bigd.conf file with a text editor.
VLAN tags and configsync
The VLAN configurations (enable, disable) must match on redundant systems in order to run configsync with the F5 Configuration utility or run the bigpipe configsync all command.
Auth_compose entries in /etc/bigd.conf cannot be set up or viewed in the F5 Configuration utility. If you are creating entries in the /etc/bigd.conf with the auth_compose script, you need to use the command line utility. The auth_compose entries are not displayed in the F5 Configuration utility.
The following browser versions are compatible with the F5 Configuration utility:
You should use gtar instead of tar to unpack the upgrade tarball if you upgrade from BIG/ip Controller version 1.8.3 to version 2.1.
This section errata to the BIG/ip Controller Administrator Guide.
Additional acknowledgement for the BIG/ip Controller version 2.1
"This product includes software developed by the Apache Group for use in the Apache HTTP server project http://www.apache.org/."
The following information updates the configsync sections of the BIG/ip Administrator Guide.
The section Using ifconfig to add another VLAN, on page 5-54, should contain the following information:
You can also use the ifconfig command to define multiple, different VLAN tagged networks on the same interface. For example, use the following command to add a new VLAN tagged network on the same interface:
ifconfig exp1 add <address> netmask <mask> broadcast <address> vlan <tag>
Note that the BIG/ip Controller allows one VLAN tag per network. In a redundant configuration, you need to add a new shared address on the newly added network with the identical VLAN tag ID in the bigip.interfaces file. For information on how to add this shared IP address, see Adding VLAN tag definitions to /etc/bigip.interfaces, on page 5-53.
The following example replaces Figure 7.2, on page 7-7, of the BIG/ip Controller Administrator Guide version 2.1:
# Default traps. .184.108.40.206.4.1.33220.127.116.11.2.6 (ROOT LOGIN) ROOT LOGIN
.18.104.22.168.4.1.3322.214.171.124.2.5 (denial) REQUEST DENIAL
.126.96.36.199.4.1.33188.8.131.52.2.4 (BIG/ip Reset) SYSTEM RESET
.184.108.40.206.4.1.33220.127.116.11.2.3 (Service detected UP) SERVICE UP
.18.104.22.168.4.1.3322.214.171.124.2.2 (Service detected DOWN) SERVICE DOWN
#.126.96.36.199.4.1.33188.8.131.52.2.1 (error) Unknown Error
#.184.108.40.206.4.1.33220.127.116.11.2.1 (failure) Unknown Failure