6

Configuring a Redundant System

• Introduction
• Synchronizing configurations between units
• Configuring fail-safe settings
• Mirroring connection information
• Using gateway fail-safe
• Using network-based fail-over
• Setting a specific BIG-IP to be the preferred active unit
• Setting up active-active redundant BIG-IP units

Introduction

A BIG-IP redundant system consists of two identically configured BIG-IP units, only one of which is active at a given time (unless a special active-active configuration is chosen). The inactive unit serves as a standby which becomes active only in case of failure of the active system, a process called failover.

BIG-IP redundant systems have special settings that you need to configure, such as VLAN fail-safe settings. One convenient aspect of configuring a redundant system is that once you have configured one of the BIG-IP units, you can simply copy the configuration to the other BIG-IP in the system by using the configuration synchronization feature.

There are two basic aspects about working with redundant systems:

• Synchronizing configurations between two BIG-IP units
• Configuring fail-safe settings for the VLANs

  In addition to the simple redundant features available on the BIG-IP, several advanced redundant features are available. Advanced redundant system features provide additional assurance that your content is available if a BIG-IP 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 to be the active unit
• Setting up active-active redundant systems

  The attributes you can configure for a redundant systems are shown in Table 6.1.

  The attributes you can configure for redundant systems

  Attributes	Description
  Synchronizing configurations	This feature allows you to configure one BIG-IP and then synchronize the configuration with the other BIG-IP.
  Fail-safe for VLANs	Fail-safe for VLANs provides the ability to cause a BIG-IP to fail over if a VLAN is no longer generating traffic.
  Mirroring connections and persistence information	You can mirror connection and/or persistence information between redundant units. This enables you to provide seamless fail-over of client connections.
  Gateway fail-safe	This feature allows you to fail-over between two gateway routers.
  Network-based fail-over	You can configure the BIG-IP to use the network to determine the status of the active unit.
  Setting a dominant BIG-IP	You can set up one unit in a pair to be the dominant active BIG-IP. The unit you set up as the dominant BIG-IP will always attempt to be active.
  Active-active configuration	The default mode for a BIG-IP redundant system is Active/Standby. However, you can configure both units to run in active mode.

Synchronizing configurations between units

Once you complete the initial configuration on the first unit in the system, you can synchronize the configurations between the active unit and the standby unit. When you synchronize a configuration, the following configuration files are copied to the other BIG-IP:

• The common BIG/db keys
• All files in /config (except bigip_base.conf)

If you use command line utilities to set configuration options, be sure to save the current configuration to the file before you use the configuration synchronization feature. (Alternately, if you want to test the memory version on the standby unit first, use bigpipe config sync running.)

Use the following bigpipe command to save the current configuration:

b save

Note: The BIG-IP software creates a file named /usr/local/ucs/cs_backup.ucs prior to installing a configuration file (UCS) from a remote machine.

To synchronize the configuration using the Configuration utility

1. In the navigation pane, click System.
   The Network Map screen opens.
2. Click the Redundant Properties tab.
   The Redundant Properties screen opens.
3. Click the Synchronize Configuration button.

To synchronize the configuration from the command line

Synchronize the configuration from the command line using the bigpipe config sync command. Use the bigpipe config sync command without the all option to synchronize only the boot configuration file /config/bigip.conf.

The bigpipe config sync all command synchronizes the following configuration files:

• The common BIG/db keys
• All files in /config (except bigip_base.conf)

The config sync running command synchronizes the running version of /config/bigip.conf, which is the image that resides in memory as the system runs. This file is written only to memory on the standby unit, it is not saved.

Configuring fail-safe settings

For maximum reliability, the BIG-IP supports failure detection on both internal and external VLANs. When you arm the fail-safe option on a VLAN, the BIG-IP monitors network traffic going through the VLAN. If the BIG-IP detects a loss of traffic on an VLAN when half of the fail-safe timeout has elapsed, it attempts to generate traffic. A VLAN attempts to generate network traffic by issuing ARP requests to nodes accessible through the VLAN. Also, an ARP request is generated for the default route if the default router is accessible from the VLAN. Any traffic through the VLAN, including a response to the ARP requests, averts a fail-over.

If the BIG-IP does not receive traffic on the VLAN before the timer expires, it initiates a fail-over, switches control to the standby unit, and reboots.

Warning: You should arm the fail-safe option on a VLAN only after the BIG-IP is in a stable production environment. Otherwise, routine network changes may cause fail-over unnecessarily.

Arming or disarming fail-safe on a VLAN

Each interface card installed on the BIG-IP is typically mapped to a different VLAN, which you need to know when you set the fail-safe option on a particular VLAN. You can view VLAN names in the Configuration utility, or you can use the bigpipe vlan show command to view VLAN names from the command line.

To arm or disarm fail-safe on an interface using the Configuration utility

1. In the navigation pane, click Network.
   The VLANs list opens and displays all VLANs.
2. Select a VLAN name.
   The VLAN Properties screen opens.
3. To arm fail-safe, check Arm Failsafe.
4. To disarm fail-safe, clear the Arm Failsafe box.
5. If you are arming fail-safe, in the Timeout box, type the maximum time allowed for a loss of network traffic before a fail-over occurs.
6. Click the Apply button.

To arm or disarm fail-safe on a VLAN from the command line

To look up the names of the existing VLANs, use the bigpipe vlan command with the show keyword:

b vlan show

To arm fail-safe on a particular VLAN, use the bigpipe vlan command with the failsafe arm keyword:

b vlan <vlan_name> timeout <seconds>

b vlan <vlan_name> failsafe arm

For example, you have an external VLAN named vlan1 and an internal VLAN named vlan2. To arm the fail-safe option on both cards with a timeout of 30 seconds, you need to issue the following commands:

b vlan vlan1 timeout 30

b vlan vlan2 timeout 30

b vlan vlan1 failsafe arm

b vlan vlan2 failsafe arm

To disarm fail-safe on a particular VLAN, use the bigpipe vlan command with the failsafe arm keyword:

b vlan <vlan_name> failsafe disarm

Mirroring connection information

When the fail-over process puts the active BIG-IP duties onto a standby unit, the connection capability of your site returns so quickly that you have little chance to see it. 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 unit goes down unless you have enabled mirroring.

The mirror feature on BIG-IP units is the ongoing communication between the active and standby units that duplicates the active unit's real-time connection information state on the standby unit. If you have enabled mirroring, fail-over can be so seamless 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 HTTP persistence connections.

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

Commands for mirroring

Table 6.2 contains the commands that support mirroring capabilities. For complete descriptions, syntax, and usage examples, see Chapter 7, bigpipe Command Reference

Mirroring commands in bigpipe

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

To configure global mirroring

You must 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:

b global mirror enable | disable | show

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

b global mirror enable

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

b global mirror disable

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

b global mirror show

Mirroring virtual server state

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

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

Note: Mirroring cannot be used with SSL gateways

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

b virtual <virt addr>:<service> \

mirror [conn] enable|disable

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

b virtual <virt addr>:<service> \

mirror [conn] show

If you do not specify conn for connection information, the BIG-IP assumes that you want to display this type 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:

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

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

b snat 192.168.225.100 mirror enable

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

b snat default mirror enable|disable

Using gateway fail-safe

Fail-safe features on the BIG-IP provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active BIG-IP 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
  
  

Note: We recommend a gateway failsafe ping interval of 2 seconds with a timeout of 10 seconds. If this interval is too small, you can use any 1 to 5 ratio that works for you.

To configure gateway fail-safe using the Configuration utility

1. In the navigation pane, click System.
   The Network map screen opens.
2. Click the Redundant Properties tab.
   The Redundant Properties screen opens.
3. In the Gateway Fail-safe section of the screen, make the following entries:
   
   
   • Check 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 number of seconds you want the BIG-IP 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.
4. 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 bigpipe db command. The keys set the following values:

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

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:

b db set 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 to wait before pinging the router:

b db set 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 to wait before marking the router down:

b db set Local.Bigip.GatewayPinger.Timeout=<seconds>

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

bigstart reinit bigd

For more information about BIG/db and using bigpipe db, see Chapter 9, BIG/db Configuration Keys.

To enable gateway fail-safe from the command line

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

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

b global gateway failsafe arm

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

b global gateway failsafe disarm

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

b global gateway failsafe show

Finding 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 console (/dev/console).

Using network-based fail-over

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

To configure network-based fail-over using the Configuration utility

1. In the navigation pane, click System.
   The Network Map screen opens.
2. Click the Redundant Properties tab.
   The Redundant Properties screen opens.
3. Check the Network Failover Enabled box.
4. 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 bigpipe db command. 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:

b db set Common.Sys.Failover.Network=1

b failover init

Other keys are available to lengthen the delay to detect the fail-over condition on the standby unit, and to lengthen the heart beat interval from the active unit. The default number of seconds required for the standby unit to notice a failure in the active unit is 3 seconds. To change the default setting, use the following syntax:

b db set Common.Bigip.Cluster.StandbyTimeoutSec=<value>

b failover init

The default heart beat interval is 1 second. To change it from the active BIG-IP, change the following value using b db:

b db set Common.Bigip.Cluster.ActiveKeepAliveSec=<value>

b failover init

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

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

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

The active or standby preference for the BIG-IP is defined by setting the appropriate startup parameters for the fail-over mechanism in BIG/db. For more details on fail-over startup and functioning, see Failover and cluster keys, on page 9-2.

To force a BIG-IP to active or standby state

The following example shows how to set the BIG-IP to standby:

b db set Local.Bigip.Failover.ForceStandby

b failover init

A BIG-IP that prefers to be standby can still become the active unit if it does not detect an active unit.

This example shows how to set a BIG-IP to active:

b db set Local.Bigip.Failover.ForceActive

b failover init

A BIG-IP that prefers to be active can still serve as the standby unit when it is on a live redundant system that already has an active unit. For example, if an active BIG-IP 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 unit until the next time the redundant system needed an active unit, for example, at reboot.

Setting up active-active redundant BIG-IP units

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

Note: If you do not want to use this feature, BIG-IP redundant units 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 redundant systems is active/standby. To use active-active mode on the BIG-IP redundant system, you must perform the following tasks, in order. Each task included below is outlined in the following sections.

• Enable active-active on the BIG-IP.
• Configure an additional floating self IP address on the internal VLAN for each unit. You must have two floating self IP addresses for the redundant system.
• Set the routing configuration on the servers that are load balanced by the active-active BIG-IP system.
• Make sure the BIG/db key Local.Bigip.Failover.UnitId is set at 1 for one of the units, and 2 for the other.
• Define the virtual servers, NATs, and/or SNATs to run on either unit 2 or 1.
• Update the fail-over mechanism with the configuration changes made in BIG/db.
• Synchronize the configuration.
• Complete the transition from active/standby to active-active.

Task 1: Enabling active-active on the BIG-IP

The first task you need to complete is to enable active-active on the BIG-IP in the redundant system.

To enable active-active using the Configuration utility

Perform this procedure on the active unit first. After the active unit is enabled, wait several seconds and open the Configuration utility for the other unit. Follow this procedure on the other unit. After you perform this task on the standby unit, wait several seconds and click the Refresh button (Microsoft Internet Explorer) or Reload button (Netscape Navigator) on the browser for both units.

1. In the navigation pane, click System.
   The Network Map screen opens.
2. Click the Redundant Properties tab.
   The Redundant Properties screen opens.
3. Check the Active-Active Mode Enabled box.
4. Click the Apply button.

To enable active-active from the command line

Set the Common.Bigip.Failover.ActiveMode key to 1. Use the following commands on each unit to enable active-active mode:

b db set Common.Bigip.Failover.ActiveMode = 1

b failover init

The default for this entry is 0 which indicates that the unit is in active/standby mode.

Task 2: Configuring an additional floating self IP address

When you configure a redundant system, you enter a pair of shared floating self IP addresses, one for the external VLAN and one for the internal VLAN. As defined during Setup utility configuration, the floating self IP addresses are configured as belonging to unit one and unit two.

In an active-active configuration, each BIG-IP must have its own floating self IP address on the internal VLAN. This is the address to which the servers behind the BIG-IP route traffic. For example, you could use 11.12.11.3 as the internal floating self IP address for unit one and 11.12.11.4 as the internal floating self IP address for unit two. Configured correctly, 11.12.11.3 should appear on both units as a floating self IP address belonging to unit one and 11.12.11.4 should appear on both units as a floating self IP address belonging to unit two.

Since you already have a floating self IP address for the internal interface that is configured for unit one and unit two, you only need to create a second floating IP address for unit two.

To create an additional floating self IP address

On unit two, create the second internal floating self IP address and assign it to unit two:

b self 11.12.11.4 vlan internal unit 2 floating enable

If the BIG-IP 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 the external VLANs of each BIG-IP, as well. This makes it possible for routers to route to a virtual server using virtual noarp mode.

Task 3: Configuring servers for active-active

In an active-active system, the servers must be logically segregated to accept connections from one BIG-IP or the other. To do this, set the default route of some of your servers to the floating self IP address on one unit and the default route on some of your servers to the floating self IP address on the other unit (see Task 2: Configuring an additional floating self IP address). When a unit fails over, the surviving BIG-IP assumes the internal IP alias of the failed machine, providing each server a default route.

Task 4: Checking the BIG-IP unit number

Using the bigpipe db get *unit* command, check the value of the BIG/db key Local.Bigip.Failover.UnitId. This value should be 1 for one of the units, and 2 for the other.

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

Note: You set the unit number for the BIG-IP in the Setup utility.

To check the BIG-IP unit number using the Configuration utility

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

1. Open the Configuration utility.
2. In the navigation pane, look at the upper left corner. The status of the BIG-IP is Active and the unit number is either 1 or 2.

Task 5: Defining the virtual address configuration

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

To define virtual servers, NATs, and SNATs on active-active units from the command line

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

b virtual <virt addr>:<service> [unit <1|2>] \

use pool <pool_name>|rule <rule_name>

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

b snat map <orig_ip> to <snat_ip> ... [unit <1|2>]

Each BIG-IP in an active-active configuration requires a unit number: either a 1 or a 2. Use the Setup utility to specify a unit number for each BIG-IP. 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.

Note: The default SNAT is not compatible with an active-active system. However, you may create the equivalent of a default SNAT using SNAT automap. Refer to Enabling or disabling SNAT automap, on page 3-19.

To define virtual servers, NATs, and SNATs on active-active units using 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. Click the Add button.
3. When you reach the Configure Redundant Properties screen, select the unit number for the virtual server from the Unit ID list. The connections served by this virtual server are managed by the BIG-IP assigned to this unit ID.
4. Complete the Resources section of the screen. For more information about individual settings, refer to the online help.
5. Click the Apply button.

Task 6: Updating the fail-over mechanism with the configuration changes made in BIG/db

If you change a BIG/db key that affects the fail-over mechanism (keys that contain the word Failover) the system needs to be updated with the change. To update the fail-over mechanism, type the following command:

b failover init

Task 7: Synchronizing the configuration

After you complete all six previous tasks on each BIG-IP in the active-active system, synchronize the configurations on the units with the Configuration utility, or from the command line.

To synchronize the configuration using the Configuration utility

1. In the navigation pane, click System.
   The Network Map screen opens.
2. Click the Redundant Properties tab.
   The Redundant Properties screen opens.
3. Click the Synchronize Configuration button.

To synchronize the configuration from the command line

To synchronize the configuration between two BIG-IP units from the command line, use the following command:

b config sync all

Task 8: Transitioning from active/standby to active-active

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

b failover standby

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

b failover standby

Now both units are in active-active mode.

Note: This task is not required if you enable active-active in the Configuration utility. The transition is made during Task 1: Enabling active-active on the BIG-IP, on page 6-11.

Understanding active-active system fail-over

Before a failure in an active-active installation, one BIG-IP is servicing all requests for virtual servers configured on unit 1, and the other BIG-IP is servicing all requests for virtual servers configured on unit 2. If one of the BIG-IP units fails, the remaining BIG-IP 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 is acting as both units 1 and 2.

If the BIG-IP that failed reboots, it re-assumes connections for the unit number with which it was configured. The BIG-IP 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, unless they were mirrored connections.

Disabling automatic fail back

In some cases, you may not want connections to automatically failback. The fact that a machine has resumed operation may not be reason enough to disrupt connections that are running on the BIG-IP 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 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 BIG-IP out of service

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

b failover standby

This command causes the BIG-IP to surrender its unit number to its peer. That is, its peer now becomes both units 1 and 2, the BIG-IP 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 BIG-IP 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 BIG-IP with no unit number.

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

b failover failback

This command causes the BIG-IP to resume its unit number. That is, the peer now relinquishes the unit number of the BIG-IP 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 BIG-IP running with both unit numbers.

Introducing 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. This value is set by the Setup utility or when you upgrade your units to this version of the BIG-IP software.
• 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 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 Understanding active-active system fail-over, on page 6-15.
• Common.Bigip.Failover.AwaitPeerDeadDelay
  The BIG-IP 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 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 mechanism logs state change information in this file. This value is not set by default.
• Common.Bigip.Failover.PrintPeerState
  Causes the fail-over mechanism to periodically write to the log file, the state of its connections to its peer (hard-wired and/or network). 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, and those that are standby connections for the peer BIG-IP. In prior versions of the BIG-IP, one unit 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. 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:

b conn dump [mirror]

b virtual persist dump [mirror]

b sticky dump [mirror]

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

Reviewing specific active-active bigpipe commands

There are several specific commands included in bigpipe to support active-active configurations. One of these commands is the bigpipe failover init command. You can use the bigpipe failover init command to read the BIG/db database and refresh its parameters. To do this, type the following command:

b failover init

Another command specifically designed for active-active configurations is the bigpipe failover failback command. This command causes the BIG-IP to resume normal operation after a fail-over occurs. To do this, type the following command:

b failover failback

After a bigpipe failover standby command is issued, use this command to allow the BIG-IP to resume normal operation. If manual fail back is enabled, this command causes a BIG-IP 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 BIG-IP you are logged into:

b unit [show]

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

b unit peer [show]

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 mechanism with the change by typing the command bigpipe failover init.
3. Synchronize the configuration by typing the command bigpipe configsync all.
4. Since each BIG-IP is an active unit, transition each unit into active/standby mode by typing the command bigpipe failover standby on each unit.
   
   

   When in active/standby mode, the active BIG-IP 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.