7

Working with Advanced Redundant System Features

Introducing advanced redundant system options

In addition to the simple redundant features available on the BIG-IP Controller, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a BIG-IP Controller experiences a problem. These advanced redundant system options include:

• Mirroring connection and persistence information
• Gateway fail-safe
• Network-based fail-over
• Setting a specific BIG-IP Controller to be the active controller
• Setting up active-active redundant controllers

Mirroring connection and persistence information

When the fail-over process puts the active controller duties onto a standby controller, the connection capability of your site returns so quickly that it has little chance to be missed. By preparing a redundant system for the possibility of fail-over, you effectively maintain your site's reliability and availability in advance. But fail-over alone is not enough to preserve the connections and transactions on your servers at the moment of fail-over; they would be dropped as the active controller goes down unless you have enabled mirroring.

The mirror feature on BIG-IP Controllers is a specialized, ongoing communication between the active and standby controllers that duplicates the active controller's real-time connection or persistence information state on the standby controller. If mirroring has been enabled, fail-over can be seamless to such an extent that file transfers can proceed uninterrupted, customers making orders can complete transactions without interruption, and your servers can generally continue with whatever they were doing at the time of fail-over.

The mirror feature is intended for use with long-lived connections, such as FTP, Chat, and Telnet sessions. Mirroring is also effective for persistence information.

Warning: If you attempt to mirror all connections, the performance of the BIG-IP Controller may degrade.

Commands for mirroring

Table 7.1 contains the commands that support mirroring capabilities. For complete descriptions, syntax, and usage examples, see the BIG-IP Controller Reference Guide, BIG/pipe Command Reference.

Mirroring command in BIG/pipe

BIG/pipe command	Options
bigpipe mirror	Options for global mirroring
bigpipe vip mirror	Options for mirroring connection and persistence information on a virtual server.
bigpipe snat mirror	Options for mirroring secure NAT connections

Global mirroring on the BIG-IP Controller redundant system

You should enable mirroring on a redundant system at the global level before you can set mirroring of any specific types of connections or information. However, you can set specific types of mirroring and then enable global mirroring to begin mirroring. The syntax of the command for setting global mirroring is:

  bigpipe mirror enable | disable | show

To enable mirroring on a redundant system, use the following command:

  bigpipe mirror enable

To disable mirroring on a redundant system, use the following command:

  bigpipe mirror disable

To show the current status of mirroring on a redundant system, use the following command:

  bigpipe mirror show

Mirroring virtual server state

Mirroring provides seamless recovery for current connections, persistence information, SSL persistence, or sticky persistence when a BIG-IP Controller fails. When you use the mirroring feature, the standby controller maintains the same state information as the active controller. Transactions such as FTP file transfers continue as though uninterrupted.

Since mirroring is not intended to be used for all connections and persistence, it must be specifically enabled for each virtual server.

To control mirroring for a virtual server, use the bigpipe vip mirror command to enable or disable mirroring of persistence information, or connections, or both. The syntax of the command is:

  bigpipe vip <virt addr>:<port> mirror [ persist | conn ] \
  enable | disable    
 

Use persist to mirror persistence information for the virtual server. Use conn to mirror connection information for the virtual server. To display the current mirroring setting for a virtual server, use the following syntax:

  bigpipe vip <virt addr>:<port> mirror [ persist | conn ] show

If you do not specify either persist, for persistent information, or conn, for connection information, the BIG-IP Controller assumes that you want to display both types of information.

Mirroring SNAT connections

SNAT connections are mirrored only if specifically enabled. You can enable SNAT connection mirroring by specific node address, and also by enabling mirroring on the default SNAT address. Use the following syntax to enable SNAT connection mirroring on a specific address:

  bigpipe snat <node addr> [...<node addr>] mirror enable | disable

In the following example, the enable option turns on SNAT connection mirroring to the standby controller for SNAT connections originating from 192.168.225.100.

  bigpipe snat 192.168.225.100 mirror enable

Use the following syntax to enable SNAT connection mirroring the default SNAT address:

  bigpipe snat default mirror enable | disable

Using gateway fail-safe

Fail-safe features on the BIG-IP Controller provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active controller and the gateway router, protecting the system from a loss of the internet connection by triggering a fail-over when the gateway is unreachable for a specified duration.

You can configure gateway fail-safe in the Configuration utility or in BIG/db. If you configure gateway fail-safe in BIG/db, you can toggle it on and off with bigpipe commands.

Adding a gateway fail-safe check

When you can set up a gateway fail-safe check using the Configuration utility, you need to provide the following information:

• Name or IP address of the router (only one gateway can be configured for fail-safe)
• Time interval (seconds) between pings sent to the router
• Time-out period (seconds) to wait for replies before proceeding with fail-over

To configure gateway fail-safe in the Configuration utility

1. In the navigation pane, click the BIG-IP logo.
   The BIG-IP System Properties screen opens.
2. In the Gateway Fail-safe section of the screen, make the following entries:

   · Click the Enabled box.

   · In the Router box, type the IP address of the router you want to ping.

   · In the Ping (seconds) box, type the interval, in seconds, you want the BIG-IP Controller to wait before it pings the router.

   · In the Timeout (seconds) box, type the timeout value, in seconds. If the router does not respond to the ping within the number of seconds specified, the gateway is marked down.

3. Click the Apply button.

To configure gateway fail-safe in BIG/db

To enable gateway fail-safe in BIG/db, you need to change the settings of three specific BIG/db database keys using the bigdba utility. The keys set the following values:

• The IP address of the router
• The ping interval
• The timeout period

  To set these keys, type this command to open the BIG/db database:

  bigdba

  To set the IP address of the router, type the following entry, where <gateway IP> is the IP address, or host name, of the router you want to ping:

  Local.Bigip.GatewayPinger.Ipaddr=<gateway IP>

  To set the ping interval, type the following entry, where <seconds> is the number of seconds you want the BIG-IP Controller to wait before pinging the router:

  Local.Bigip.GatewayPinger.Pinginterval=<seconds>

  To set the timeout, type the following entry, where <seconds> is the number of seconds you want the BIG-IP Controller to wait before marking the router down:

  Local.Bigip.GatewayPinger.Timeout=<seconds>

  To close bigdba and save your changes, type this command and press the Enter key:

  quit

  For more information about BIG/db and using bigdba, see Working with the BIG/db database, on page 10-27.

Note: After you make these changes, you must restart bigd to activate the gateway pinger.

Enabling gateway fail-safe

Gateway fail-safe monitoring can be toggled on or off from the command line using the bigpipe gateway command.

For example, arm the gateway fail-safe using the following command:

  bigpipe gateway failsafe arm 

To disarm fail-safe on the gateway, enter the following command:

  bigpipe gateway failsafe disarm

To see the current fail-safe status for the gateway, enter the following command:

  bigpipe gateway failsafe show

Gateway fail-safe messages

The destination for gateway fail-safe messages is set in the standard syslog configuration (/etc/syslog.conf), which directs these messages to the file /var/log/bigd. Each message is also written to the BIG-IP Controller console (/dev/console).

Using network-based fail-over

Network-based fail-over allows you to configure your redundant BIG-IP Controller to use the network to determine the status of the active controller. Network-based fail-over can be used in addition to, or instead of, hard-wired fail-over.

To configure network fail-over in the Configuration utility

1. In the navigation pane, click the BIG-IP logo.
   The BIG-IP System Properties screen opens.
2. In the Redundant Configuration section of the screen,
   click the Network Failover Enabled box.
3. Click the Apply button.

To Configure network-based fail-over in BIG/db

To enable network-based fail-over, you need to change the settings of specific BIG/db database keys using the bigdba utility. To enable network-based fail-over, the Common.Sys.Failover.Network key must be set to one (1). To set this value to one, type this command to open the BIG/db database:

bigdba

At the bigdba prompt, type the following entry:

Common.Sys.Failover.Network=1

To close bigdba and save your changes, type this command and press the Enter key:

quit

Other keys are available to lengthen the delay to detect the fail-over condition on the standby controller, and to lengthen the heart beat interval from the active unit. To change the time required for the standby unit to notice a failure in the active unit, set the following value using the bigdba utility (the default is three seconds):

Common.Bigip.Cluster.StandbyTimeoutSec=<value>

To change the heart beat interval from the active BIG-IP Controller, change the following value using bigdba (the default is one second):

Common.Bigip.Cluster.ActiveKeepAliveSec=<value>

For more information about BIG/db and using bigdba, see Using bigdba, on page 10-27.

Setting a specific BIG-IP Controller to be the preferred active unit

Setting a preferred active controller means overlaying the basic behavior of a BIG-IP Controller with a preference toward being active. A controller that is set as the active controller becomes active whenever the two controllers negotiate for active status.

To clarify how this differs from default behavior, contrast the basic behavior of a BIG-IP Controller in the following description. Each of the two BIG-IP Controllers in a redundant system has a built-in tendency to try to become the active controller. Each system attempts to become the active controller at boot time; if you boot two BIG-IP Controllers at the same time, the one that becomes the active controller is the one that boots up first. In a redundant configuration, if the BIG-IP Controllers are not configured with a preference for being the active or standby controller, either controller can become the active controller by becoming active first.

The active or standby preference for the BIG-IP Controller is defined by setting the appropriate startup parameters for sod (the switch over daemon) in /etc/rc.local. For more details on sod startup and functioning, see the BIG-IP Controller Reference Guide, System Utilities.

The following example shows how to set the controller to standby:

  echo " sod.";    /usr/sbin/sod -force_slave 2> /dev/null

A controller that prefers to be standby can still become the active controller if it does not detect an active controller.

This example shows how to set a controller to active:

  echo " sod.";    /usr/sbin/sod -force_master 2> /dev/null

A controller that prefers to be active can still serve as the standby controller when it is on a live redundant system that already has an active controller. For example, if an active controller that preferred to be active failed over and was taken out of service for repair, it could then go back into service as the standby controller until the next time the redundant system needed an active controller, for example, at reboot.

Setting up active-active redundant controllers

You can use the active-active feature to simultaneously load balance traffic for different virtual addresses on redundant BIG-IP Controllers. Performance improves when both BIG-IP Controllers are in active service at the same time. In active-active mode, you configure virtual servers to be served by one of the two controllers. If one controller fails, the remaining BIG-IP Controller assumes the virtual servers of the failed machine. For this configuration to work, each controller has its own unit ID number. Each virtual server, NAT, or SNAT you create includes a unit number designation that determines which active controller handles its connections.

Note: If you do not want to use this feature, redundant BIG-IP Controllers operate in active/standby mode by default.

Warning: MAC masquerading is not supported in active-active mode.

Configuring an active-active system

The default mode for BIG-IP Controller redundant systems is active/standby. You must take several steps in order to use active-active mode on the redundant BIG-IP Controller system. Details follow this brief list.

1. Configure an additional shared IP alias on the internal interface for each unit. You must have two shared aliases for the redundant system.
2. Set the routing configuration on the servers load balanced by the active-active BIG-IP Controller system.
3. Make sure the BIG/db key Local.Bigip.Failover.UnitId is 1 for one of the controllers, and 2 for the other.
4. Enable active-active mode by setting the BIG/db key Common.Bigip.Failover.ActiveMode to 1.
5. Define the virtual servers, NATs, and/or SNATs to run on either unit 2 or on unit 1.
6. Update the fail-over daemon (/sbin/sod) with the configuration changes made in BIG/db.
7. Synchronize the configuration.
8. Transition from active/standby to active-active.

Note: We recommend making all of these configuration changes on one controller and then synchronizing the configuration.

Step 1: Configure an additional shared IP alias

When you configure a redundant system, you enter a shared IP alias. In active/standby mode, this shared IP alias runs on the active controller. You can determine if you already have a shared IP alias by running the bigpipe interface command. If you have one, it is probably configured as belonging to unit one.

In an active-active configuration, each BIG-IP Controller must have a shared IP alias on the internal, source processing, interface. This is the address to which the servers behind the BIG-IP Controller route traffic. Since you already have a shared IP alias for one controller, add a shared IP alias for the other controller by using the bigpipe ipalias command. For example:

  bigpipe ipalias exp1 172.20.10.2 netmask 
255.255.0.0 unit 2

If you do not have a shared IP alias for unit 1, add one using this command. To view the IP aliases for the controller, type the bigpipe interface command on the command line.

If the BIG-IP Controller fails over, its shared IP address is assumed by the remaining unit and the servers continue routing through the same IP address.

You can configure additional shared IP aliases on an external, destination processing, interface of each BIG-IP Controller, as well. This makes it possible for routers to route to a virtual server using vip noarp mode.

To configure the additional shared IP alias in the Configuration utility

1. In the navigation pane, click NICs.
   The Network Interface Cards screen opens.
2. On the Network Interface Cards screen, click the name of the interface you want to configure.
   The Network Interface Card properties screen opens. You must choose an internal (source processing) interface.
3. In the Redundant Configuration section, check for a Unit 1 Alias and a Unit 2 Alias.
4. If one of the unit aliases is not present, type in an alias for the unit.
5. Click the Apply button.

   Repeat this procedure on the other controller or use the Sync Configuration option in the toolbar of the BIG-IP System Properties page. Note that these settings should be identical on both controllers.

Step 2: Configuring servers for active-active

The active-active feature causes some restrictions on the servers behind the BIG-IP Controllers. The servers must be logically segregated to accept connections from one BIG-IP Controller or the other. To do this, set the default route to the BIG-IP Controller IP alias (see Step 1) from which it accepts connections. In the case of a fail-over, the surviving BIG-IP Controller assumes the internal IP alias of the failed machine, providing each server a default route.

Step 3: Check the BIG-IP Controller unit number

Using the bigdba utility, check the value of the BIG/db key Local.Bigip.Failover.UnitId. This value should be 1 for one of the controllers, and 2 for the other.

Each BIG-IP Controller in an active-active configuration requires a unit number: either a 1 or a 2. The First-Time Boot utility allows a user to specify a unit number for each BIG-IP Controller. In an active-active configuration, specify the unit number when you configure virtual addresses, NATs, and SNATs.

Note: You can only set this value directly in BIG/db. It cannot be set in the Configuration utility.

To check the BIG-IP Controller unit number in the Configuration utility

Follow this procedure on each BIG-IP Controller in a redundant system to check the BIG-IP Controller unit number with the Configuration utility:

1. Open the Configuration utility.
2. In the navigation pane, check the description next to the BIG-IP logo.
   The status of the controller is Active and the unit number is either 1 or 2.

Step 4: Active-active BIG/db configuration parameters

To enable active-active, you must set the Common.Bigip.Failover.ActiveMode key to one (1). To set this value to one, follow these steps:

Type the following command to open the BIG/db database:

  bigdba 

At the bigdba prompt, type the following entry:

  Common.Bigip.Failover.ActiveMode=1 

Type quit to exit BIG/db and save the configuration.

The default for this entry is off and fail-over runs in active/standby mode.

To enable active-active in the Configuration utility

Perform this procedure on the active controller first. After the active box is enabled, follow this procedure on the standby controller. After you perform this feature on the standby controller, wait 30 seconds and click the Refresh button (Microsoft Internet Explorer) or Reload button (Netscape Navigator) on the browser for both controllers.

1. In the navigation pane, click the BIG-IP logo.
2. The BIG-IP Controller System Properties screen opens.
3. Click the Active-Active Mode Enabled check box.
4. Click the Apply button.

Step 5: Virtual address configuration

Both BIG-IP Controllers must have the exact same configuration file (/etc/bigip.conf). When a virtual server is defined, it must be defined with a unit number that specifies which BIG-IP Controller handles connections for the virtual server. Each BIG-IP Controller has a unit number, 1 or 2, and serves the virtual servers with corresponding unit numbers. If one of the BIG-IP Controllers fails over, the remaining BIG-IP Controller processes the connections for virtual servers for both units.

Defining virtual servers, NATs, and SNATs on active-active controllers

Use the following commands to define virtual servers, NATs, and SNATs on active-active controllers:

  bigpipe vip <virt addr>:<port> define [unit <1|2>] 
 <node addr>:<port>   
 

  bigpipe nat <internal_ip> to <external_ip> ... [unit <1|2>]

  bigpipe snat map <orig_ip> to <trans_ip> ... [unit <1|2>]

Note: If not specified, the unit number defaults to 1.

Each BIG-IP Controller in an active-active configuration requires a unit number: either a 1 or a 2. Use the First-Time Boot utility to specify a unit number for each BIG-IP Controller. If you do not specify a unit number, the unit number for the virtual server defaults to 1.

Note: You must specify the unit number when defining virtual servers, NATs, and SNATs. You cannot add the unit number at a later time without redefining the virtual server, NAT, or SNAT.

To define virtual servers, NATs, and SNATs on active-active controllers in the Configuration utility

The following example illustrates the unit ID number in a virtual server definition. Although the steps to create a NAT or SNAT are slightly different, the unit ID number serves the same purpose.

1. In the navigation pane, click Virtual Servers.
   The Virtual Servers screen opens.
2. In the toolbar, click the Add Virtual Server button.
3. Type in the address, netmask, and port for the virtual server.
4. Click the Unit ID list. Select the unit number for the virtual server.
5. The connections served by this virtual server are managed by the controller assigned this unit ID.
6. Complete the Resources section of the screen. For more information about individual settings, refer to the online help.
7. Click the Apply button.

Step 6: Update the fail-over daemon (/sbin/sod) with the configuration changes made in BIG/db

Active-active mode is implemented by the fail-over daemon (/sbin/sod). If you change a BIG/db key that affects the fail-over daemon (keys that contain the word Failover) the fail-over daemon needs to be updated with the change. To update the fail-over daemon, type the following command:

  bigpipe failover init

Step 7: Synchronize the configuration

After you complete steps 1 through 5 on each controller in the active-active system, synchronize the configurations on the controllers with the Configuration utility, or from the command line.

To synchronize the configuration in the Configuration utility

1. In the navigation pane, click the BIG-IP logo.
   The BIG-IP Properties screen opens.
2. In the toolbar, click the Sync Configuration button.
   The Synchronize Configuration screen opens.
3. Click the Synchronize button.

To synchronize the configuration from the command line

To synchronize the configuration between two controllers from the command line, use the following command:

  bigpipe configsync all

Step 8: Transition from active/standby to active-active

To transition from active/standby to active-active, type the following command on the active BIG-IP Controller:

  bigpipe failover standby

This command puts the active BIG-IP Controller into partial active-active mode. To complete the transition, type in the following command on the other BIG-IP Controller which now considers itself the active unit.

  bigpipe failover standby

Now both units are in active-active mode.

Note: This step is not required if you enable active-active in the Configuration utility. The transition is made during Step 4: Active- active BIG/db configuration parameters, on page 7-13.

Active-active system fail-over

Before a failure in an active-active installation, one BIG-IP Controller is servicing all requests for virtual servers configured on unit 1, and the other BIG-IP Controller is servicing all requests for virtual servers configured on unit 2. If one of the BIG-IP Controllers fails, the remaining BIG-IP Controller handles all requests for virtual servers configured to run on unit 1 and also those configured to run on unit 2. In other words, the surviving BIG-IP Controller is acting as both units 1 and 2.

If the BIG-IP Controller that failed reboots, it re-assumes connections for the unit number with which it was configured. The BIG-IP Controller that was running as both units stops accepting connections for the unit number that has resumed service. Both machines are now active.

When the unit that was running both unit numbers surrenders a unit number to the rebooted machine, all connections are lost that are now supposed to run on the rebooted machine. (The connections are lost unless they were mirrored connections.)

Disabling automatic fail back

In some cases, you may not want connections to automatically fail back. The fact that a machine has resumed operation may not be reason enough to disrupt connections that are running on the BIG-IP Controller serving as both units. Note that because of addressing issues, it is not possible to slowly drain away connections from the machine that was running as both units, giving new requests to the recently rebooted machine.

To disable automatic fail back, set the BIG/db key Common.Bigip.Failover.ManFailBack to 1. When you set this key to 1, a BIG-IP Controller running as both units does not surrender a unit number to a rebooted peer until it receives the bigpipe failover failback command. By default, this key is not set.

Taking an active-active controller out of service

You can use the bigpipe failover standby command to place an active controller in standby mode. In active-active mode, type the following command to place a one of the active controllers in standby mode:

  bigpipe failover standby

This command causes the BIG-IP Controller to surrender its unit number to its peer. That is, its peer now becomes both units 1 and 2, the BIG-IP Controller appears out of service from a fail-over perspective, it has no unit numbers. You can make any changes, such as configuration changes, before causing the machine to resume normal operation.

Placing an active-active controller back in service if automatic failback is disabled

If the Common.Bigip.Failover.ManFailBack key is set to 0 (off), normal operation is restored when you issue a bigpipe failover failback command on the controller with no unit number.

In active-active mode, type the following command to place a standby controller back in service:

  bigpipe failover failback

This command causes the BIG-IP Controller to resume its unit number. That is, the peer now relinquishes the unit number of the controller that has resumed service.

However, if the Common.Bigip.Failover.ManFailBack key is set to 1 (on), normal operations are restored when you issue a bigpipe failover failback command on the controller running with both unit numbers.

Additional active-active BIG/db configuration parameters

There are several new BIG/db parameters for active-active mode.

Common.Bigip.Failover.ActiveMode
Set this BIG/db parameter to 1 to enable active-active mode. The default setting is off, and redundant systems run in active/standby mode.

Local.Bigip.Failover.UnitId
This is the default unit number of the BIG-IP Controller. This value is set by the First-Time Boot utility or when you upgrade your controllers to this version of the BIG-IP Controller.

Common.Bigip.Failover.ManFailBack
This is set to 1 so that manual intervention is required (the bigpipe failover failback command is issued) before a BIG-IP Controller running both unit numbers surrenders a unit number to its peer. This feature is off by default, fail-back is automatic. For more details, see the section Active-active system fail-over, on page 7-16.

Common.Bigip.Failover.NoSyncTime
Set this to 1 if you do not want to synchronize the time of the two BIG-IP Controllers. Normally, their time is synchronized. For some cases, this is not desirable, for example, if you are running ntpd.

Common.Bigip.Failover.AwaitPeerDeadDelay
The BIG-IP Controller checks to see that its peer is still alive at this rate (in seconds). The default value for this parameter is one second.

Common.Bigip.Failover.AwaitPeerAliveDelay
Check status of a peer BIG-IP Controller while waiting for it to come to life with this frequency (in seconds). The default value of this parameter is three seconds.

Common.Bigip.Failover.DbgFile
If a file name is specified, the fail-over daemon logs state change information in this file. This value is not set by default.

Common.Bigip.Failover.PrintPeerState
Causes the fail-over daemon to periodically write the state of its connections to its peer (hard-wired and/or network) to the log file Common.Bigip.Failover.DbgFile.

Additional commands for displaying active vs. mirrored data

The dump commands explicitly show those connections (and other objects) that are active on the BIG-IP Controller, and those that are standby connections for the peer BIG-IP Controller. In prior versions of the BIG-IP Controller, one controller is the active unit and the other is the standby. When the bigpipe conn dump command is issued on the active unit, each of the connections shown is active. Similarly, when the bigpipe conn dump command is issued on the standby unit, it is clear that each of the connections listed is a standby connection. These standby connections are created by mirroring the active connections on the standby unit.

In an active-active installation, each unit can be considered a standby for its peer BIG-IP Controller. By default, the dump command only shows items that are active on the given unit. To see standby items you must use the mirror qualifier. You can use the following commands with the mirror option:

  bigpipe conn dump [mirror]

  bigpipe vip persist dump [mirror]

  bigpipe sticky dump [mirror]

Also, the bigpipe snat show command output has been modified to show whether a connection listed is an active connection or a mirror connection.

New active-active bigpipe commands

Several new commands have been added to bigpipe to reflect new or changed functionality.

  bigpipe failover init

This command causes the fail-over daemon (/sbin/sod) to read the BIG/db database and refresh its parameters.

bigpipe failover failback

After a bigpipe failover standby command is issued, issue this command to allow the BIG-IP Controller to resume normal operation. If manual fail back is enabled, this command causes a BIG-IP Controller that is running as both units to release a unit number to its peer unit when the peer becomes active. You can use the following commands to view the unit number on the controller you are logged into:

  bigpipe unit [show]

To view the unit number, or numbers, of the peer BIG-IP Controllers in a redundant system, type the following command:

  bigpipe unit peer [show]

Running mixed versions of BIG-IP Controller software in active-active mode

The BIG-IP Controller provides the option to install a new version of the BIG-IP Controller software on one BIG-IP Controller, while the other BIG-IP Controller runs a previous production version of the software. This allows you to fail back and forth between the two units, testing the new software yet having the ability to return to the prior installation.

This is possible with the new fail-over software in version 3.1, whether using active-active mode or active/standby mode. However, there are some exceptions:

State mirroring is not compatible between the version 3.0 and prior versions of the software. Network fail-over is also not compatible.

If you are running the BIG-IP Controller version 3.1 in active-active mode, you should assign unit two to the BIG-IP Controller running version 3.1.

Returning an active-active installation to active/standby mode

Returning to active/standby mode from active-active mode is relatively simple in that only a few things need be undone.

1. Enable active/standby mode by setting the BIG/db key Common.Bigip.Failover.ActiveMode to 0.
2. Update the fail-over daemon with the change by typing bigpipe failover init.
3. To synchronize the configuration, type the command bigpipe configsync all.
4. Since each BIG-IP Controller is an active unit, type the command bigpipe failover standby on each controller. This transitions each controller into active/standby mode.

   When in active/standby mode, the active BIG-IP Controller runs all objects (virtual servers, SNATs and NATs) that are defined to run on unit 1 or unit 2. It is not necessary to redefine virtual servers, SNATS, or NATs when you transition from active-active mode to active/standby mode.