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 bigipv21domkit.f5.tar file to the /var/tmp/ directory on the BIG/ip Controller.
   
   Customers with International versions of the BIG/ip Controller need to download the bigipv21intlkit.f5.tar. Customers who are using LB versions of the BIG/ip Controller need to download the bigipv21lbdomkit.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 bigipv21hadomkit.f5.tar (Domestic HA and HA+)
   tar -xpf bigipv21lbdomkit.f5.tar (Domestic LB)
   tar -xpf bigipv21intlkit.f5.tar (International HA/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

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:

config_telnetd

config_ftpd

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.

---

What's new in this version

Enhancements

• Increased BIG/ip Controller throughput
  The BIG/ip Controller can now handle a greater number of connection requests than previous versions.
• Secure network address translation (SNAT)
  Secure NAT (SNAT) provides clients with a secure outbound connection to servers external to the BIG/ip Controller or on an internal server array through a load balanced virtual server. SNAT connection requests can come only from IP addresses recognized by a BIG/ip Controller. For information about configuring SNAT, see Defining a secure network address translation (SNAT), page 4-26, in the BIG/ip Controller Administrator Guide.
• Support for 802.1q VLAN trunk mode
  You can configure an internal interface to run in IEEE 802.1q VLAN trunk mode, and make it a member of multiple VLANs. For information about configuring 802.1q VLANS, see Setting up 802.1q VLAN trunk mode, page 5-52, in the BIG/ip Controller Administrator Guide.
• Using gateway fail-safe
  Gateway fail-safe provides the ability to configure the BIG/ip Controller to fail over when a specified gateway is unreachable. For information about configuring gateway fail-safe, see Using gateway fail-safe, page 5-23, in the BIG/ip Controller Administrator Guide.
• Mirroring connection information for fail-over
  Mirroring provides seamless fail-over of client connections and persistence information from an active BIG/ip Controller to a standby controller. For information about configuring mirroring, see Mirroring connection and persistence information, page 5-20, in the BIG/ip Controller Administrator Guide.
• Network-based fail-over
  Network-based fail-over allows you to configure a redundant BIG/ip Controller to use a network connection to determine the status of the active controller. Network-based fail-over can be used in addition to hardware fail-over. For information about configuring network-based fail-over, see Using network-based fail-over, page 5-25, in the BIG/ip Controller Administrator Guide.

• Support for wildcard ports
  Wildcard ports are now available in the standard BIG/ip Controller configuration. For information about configuring wildcard ports, see A note about wildcard ports, page 4-10, in the BIG/ip Controller Administrator Guide.

• ECV through transparent nodes
  New ECV syntax has been designed to facilitate performing ECV with transparent nodes. With it, you can test whether a transparent node is functioning properly by retrieving content through it. For information about configuring ECV through transparent nodes, see Configuring ECV for transparent nodes, page 5-3, in the BIG/ip Controller Administrator Guide.

• Destination address affinity
  You can optimize a proxy server array with destination address affinity (also called sticky persistence). Destination address affinity directs requests for a destination to the proxy server configured to cache a specified IP range. For information about configuring destination address affinity, see Using destination address affinity (sticky persistence), page 5-14, in the BIG/ip Controller Administrator Guide.
• HTTP cookie persistence
  A new HTTP cookie persistence option is available on the BIG/ip Controller. HTTP cookie persistence uses information stored in an HTTP cookie to maintain persistent connections. For information about configuring HTTP cookie persistence, see Using HTTP cookie persistence, page 5-12, in the BIG/ip Controller Administrator Guide.
• Updated the Perl package
  We have upgraded the BIG/ip Controller to Perl version 5.005.

• Incorporated the latest version of BIND
  We have upgraded the BIG/ip Controller to BIND 8.
• Added support for traceroute to a NAT
  You can now use the traceroute command to view hops to an external address of a NAT.
• The log files in /var/log/httpd are configured to rotate
  You can now configure the web server log files to rotate. This enhancement applies to any Apache web server variant.

Fixes

• Loading large configurations
  It is no longer necessary to stop the bigd process when loading a large configuration. The bigpipe -f command no longer hangs the BIG/ip Controller when loading a large configuration.
• 535: Interaction between fastest LB mode and node disable
  Fastest load balancing mode no longer permanently excludes nodes from service if the server experiences a one-time lapse in response time.
• 538: Added linger/nolinger pipe modes to syslogd
  The linger/nolinger mode of syslog will close the pipe and terminate the external program after a message is written. Use two vertical bars (||), followed by the command to which the selected messages are piped. This is the same as a single vertical bar, except that the pipe is closed after every message. Note that duplicate messages are suppressed in this mode just like in other modes. This mode should not be used for facilities that cause a lot of messages. Creating a process and pipe for each message can consume a lot of resources.
• 678: Possible problem when using rate filtering and GateD at same time
  Fixed a possible problem that would cause a crash when using rate filtering and GateD at same the time.
• 909: Add default timeout values to F5 Configuration utility statistics screens
  Provides the ability to set the default timeout values for the Refresh Interval on all statistics pages.
• 910: Not returning the ifTable.PhysAddr to SNMP management system
  Added the ability to use SNMP management system to get the physical address for an interface.
• 943: SNMP: sysObjectID
  Changed the sysObjectID to the F5 Networks enterprise registered number.
• 944: SNMP: ifLastChange is not maintained
  Added the Last changed column to the interfaces table. This is a standard MIB-II variable.
• 969: SSL proxy vulnerable to connection flood attack
  The SSL proxy has been strengthened to resist connection flood attack.
• 1090: The SSL session ID reaper does not allow VIP granularity
  Added the ability to reset the special ssl timeout to different times for different VIPs.
• 1151: The checktrap.pl script is sending 65,000 SNMP traps
  Removed the unknown regular expression from the default snmptrap.conf configuration file.
• 1181: SNMP: Rewrite of checktrap.pl
  Updated the checktrap.pl script to work more efficiently.
• 1182: SNMP: Update snmptrap.conf defaults
  Added descriptions and basic configuration examples to the snmptrap.conf file.
• 1183: SNMP: Install UCDavis Man Pages
  Added man pages for snmpd.1, snmptrap.1, and snmpd.conf.5 to the file system.
• 1186: SNMP: Review Current Indexing schemes for the F5 Networks vendor MIB
  Added a new indexing scheme to the F5 Networks vendor MIB.
• 1704: BIG/pipe segmentation fault problem
  When collecting statistics on the BIG/ip Controller, a bigpipe node command generated a segmentation fault error message.

---

Configuring and using the new software

Some of the enhancements provided in this release require special configuration. Please refer to the sections below for more information about additional configuration.

Running config_failover for redundant domestic HA and HA+ systems

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:

• The utility verifies that the AllowHosts entry in the /etc/sshd_config file includes the IP address of the other controller in the redundant configuration.
• The utility runs the ssh-keygen command which creates the security keys for the controller.
• The utility shares the keys with the other controller in the redundant system.

To run the config_failover utility, type the following command from the command line:

config_failover

After you run the utility, you can run bigpipe configsync or use the F5 Configuration utility to synchronize the controllers.

---

Enabling or disabling IEEE 802.1q VLAN tags in the F5 Configuration utility

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.

1. In the navigation pane, select NICs.
   The Network Interface Cards screen opens.
2. In the Network Interface Cards list, select the internal NIC for which you want to enable VLAN tags.
   The Network Interface Card Properties screen opens.
3. In the Network Interface Card Properties screen, the Enable VLANs check box is displayed.
4. Click the Enable VLANs check box to enable the VLAN tags for the interface. Clear the check box to disable VLAN tags on the interface.
5. Click the Apply button.

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.

---

Using the F5 Configuration utility to set up ECV through transparent nodes

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:

1. In the navigation pane, click Nodes.
   The Node screen opens.
2. In the Node list, click the node you want to configure.
   The Node Properties screen opens.
3. In the Port box, click the port for which you want to enable the service check.
   The Global Node Port Properties screen opens.
4. In the Frequency (seconds) box, type in the interval (in seconds) at which the BIG/ip Controller performs a service check on the node.
5. In the Timeout (seconds) box, type in the time limit (in seconds) that a node has to respond to a service check issued by the BIG/ip Controller.
6. Click the Apply button.

After you configure the frequency and timeout settings for the port, set the specific settings for the transparent node:

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Node list, click the node you want to configure.
   The Node Properties screen opens.
3. In the Service Check Extended section, click the ECV button to enable ECV.
4. In the Type list, select Transparent.
   By default, the list is set to Transparent.
5. In the Dest-IP:Dest-Port/url box, you must type the destination IP address of the node you are checking on the other side of the transparent device. The port number/port name argument is optional. The URL entry is also optional.
6. In the Receive String (optional) box, you can type an ECV check receive string. The receive string is optional.
7. Click the Apply button.

---

To set the system control variable bigip.max_sticky_entries

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

1. In the navigation pane, click the BIG/ip logo.
   The BIG/ip System Properties screen opens.
2. In the tool bar, click Advanced Properties.
   The BIG/ip System Control Variables screen opens.
3. In the Maximum Number of Sticky Entries box, type the maximum number of sticky entries you want to allow to accumulate on the BIG/ip Controller. This variable defaults to 2048.
4. Click the Apply button.

Note:  In order to prevent sticky entries from clumping on one server, use a static load balancing mode, such as Round Robin.

---

Changes to wildcard virtual servers

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.

Administering users and the upgrade process

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.

---

Features not supported in the LB version of the BIG/ip Controller

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.

Cookie Persistence
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.

bigd/bigdnode
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.

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

---

Using the EAV pingers bundled with the BIG/ip Controller

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 user@company.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 "bigip@internal.net"

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

1. In the navigation pane, click Nodes.
   The Node Properties screen opens.
2. In the Extended section, click the EAV box to enable EAV service checking. The service check frequency and service check timeout must be set in order to access this option.
3. In the Type list, select the pinger you want to use. The External Program Path is automatically filled in when you select a pinger from the list.
4. In the External Program Arguments box, type in the arguments required for the pinger you selected. The specific arguments you must use for each pinger are documented in the following section.
5. Click the Apply button.

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 user@company.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:

alice alices_password
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 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:

bigip@internal.net

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:

comp.lang.java
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.

---

Changes to the BIG/ip Controller version 2.1 SNMP MIB

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.

Old	New
ready(2)	ready(1)
maintenance(1)	maintenance(2)

This change corrected an error in the interpretation of this status:

virtualAddress.virtualAddressTable.virtualAddressEntry.virtualStatus
virtualServer.virtualServerTable.virtualServerEntry.virtualServerStatus
vaddress.vaddressTable.vaddressEntry.vaddressStatus

The second change to the vendor MIB changes the status of several entries. The states for the following entries have been expanded.

Old	New
up(1)	up(1)
down(2)	down(2)
testing(3)	invalid(3)
	maintenance(4)
	unchecked(5)
	unknown(6)

These expanded status modes apply to the following status entries:

ndaddr.ndaddrTable.ndaddrEntry.ndaddrStatus
member.memberTable.memberEntry.memberStatus

---

Known issues

The following issues are known issues with the BIG/ip Controller version 2.1.

Using the F5 Configuration utility with Netscape Navigator 4.61

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:

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.

Synchronizing redundant configurations

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 and the F5 Configuration utility

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.

Browser versions compatible with the F5 Configuration utility

The following browser versions are compatible with the F5 Configuration utility:

• Netscape versions 4.05 and later
• Internet Explorer version 4.0 and later

Upgrading from BIG/ip Controller version 1.8.3 to version 2.1

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.

---

Errata to the BIG/ip Controller Administrator Guide 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/."

Configsync
The following information updates the configsync sections of the BIG/ip Administrator Guide.

• The BIG/ip Controller Administrator Guide version 2.1, pages B-7 and 4-43, states that /etc/netstart is copied when running configsync with the -all flag. In fact, this file is not copied when you run configsync.
• The configsync command copies across rc.sysctl and the F5 Configuration utility user databases.

VLAN tags
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.

SNMP figure
The following example replaces Figure 7.2, on page 7-7, of the BIG/ip Controller Administrator Guide version 2.1:

# Default traps. .1.3.6.1.4.1.3375.1.1.110.2.6 (ROOT LOGIN) ROOT LOGIN
.1.3.6.1.4.1.3375.1.1.110.2.5 (denial) REQUEST DENIAL
.1.3.6.1.4.1.3375.1.1.110.2.4 (BIG/ip Reset) SYSTEM RESET
.1.3.6.1.4.1.3375.1.1.110.2.3 (Service detected UP) SERVICE UP
.1.3.6.1.4.1.3375.1.1.110.2.2 (Service detected DOWN) SERVICE DOWN
#.1.3.6.1.4.1.3375.1.1.110.2.1 (error) Unknown Error
#.1.3.6.1.4.1.3375.1.1.110.2.1 (failure) Unknown Failure

---

---