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

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 Link Controller:

• 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 Link Controller 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 bigpipe 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 Link Controller supports failure detection on both internal and external VLANs. When you arm the fail-safe option on a VLAN, the Link Controller monitors network traffic going through the VLAN. If the Link Controller 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 Link Controller 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 Link Controller 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 Link Controller 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. Locate the Arm Failsafe box:
   
   
   • To arm fail-safe, check Arm Failsafe.
   • To disarm fail-safe, clear the Arm Failsafe box.
4. 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.
5. 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 timeout and failsafe arm keywords:

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 Link Controller 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 Link Controller 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 Link Controller.

Commands for mirroring

Table 8.2 contains the commands that support mirroring capabilities. For complete descriptions, syntax, and usage examples, see Appendix A, bigpipe Command Reference .

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 Link Controller fails. When you use the mirroring feature, the standby Link Controller 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 Link Controller 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 Link Controller provide network failure detection based on network traffic. Gateway fail-safe monitors traffic between the active Link 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 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 Link 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.
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 Link Controller 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 Link Controller 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

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

Using network-based fail-over

Network-based fail-over allows you to configure a redundant Link Controller system 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 Link Controller, change the following value using b db:

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

b failover init

Setting a specific Link Controller to be the preferred active unit

Setting a preferred active unit means overlaying the basic behavior of a Link Controller with a preference toward being active. A Link Controller 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 Link Controller in the following description. Each of the two Link Controller 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 Link Controller 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 Link Controller 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 Link Controller is defined by setting the appropriate startup parameters for the fail-over mechanism in BIG/db.

To force a Link Controller to active or standby state

The following example shows how to set the Link Controller to standby:

b db set Local.Bigip.Failover.ForceStandby

b failover init

A Link Controller 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 Link Controller to active:

b db set Local.Bigip.Failover.ForceActive

b failover init

A Link Controller 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 Link 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 unit until the next time the redundant system needed an active unit, for example, at reboot.