Table Of Contents
Information About High Availability
Information About Failover and High Availability
Failover System Requirements
Hardware Requirements
Software Requirements
Failover and Stateful Failover Links
Failover Link
LAN-Based Failover Link
Stateful Failover Link
Failover Interface Speed for Stateful Links
Active/Active and Active/Standby Failover
Active/Standby Failover
Information About Active/Standby Failover
Primary/Secondary Status and Active/Standby Status
Device Initialization and Configuration Synchronization
Command Replication
Failover Triggers
Failover Actions
Active/Active Failover
Information About Active/Active Failover
Primary/Secondary Status and Active/Standby Status
Device Initialization and Configuration Synchronization
Command Replication
Failover Triggers
Failover Actions
Determining Which Type of Failover to Use
Stateless (Regular) and Stateful Failover
Stateless (Regular) Failover
Stateful Failover
Failover Health Monitoring
Unit Health Monitoring
Interface Monitoring
Failover Feature/Platform Matrix
Failover Times by Platform
Information About High Availability
This chapter provides an overview of the failover features that enable you to achieve high availability on the Cisco 5500 series adaptive security appliances. For information about configuring failover, see Chapter 34, "Configuring Active/Active Failover" or Chapter 33, "Configuring Active/Standby Failover."
This chapter includes the following sections:
•
Information About Failover and High Availability, page 32-1
•Failover System Requirements, page 32-2
•Failover and Stateful Failover Links, page 32-3
•Active/Active and Active/Standby Failover, page 32-5
•Stateless (Regular) and Stateful Failover, page 32-15
•Failover Health Monitoring, page 32-16
•Failover Feature/Platform Matrix, page 32-18
•Failover Times by Platform, page 32-18
Information About Failover and High Availability
To achieve high availability, the failover configuration requires two identical adaptive security appliances connected to each other through a dedicated failover link and, optionally, a Stateful Failover link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs.
The adaptive security appliance supports two failover configurations, Active/Active failover and Active/Standby failover. Each failover configuration has its own method for determining and performing failover.
With Active/Active failover, both units can pass network traffic. This also lets you configure traffic sharing on your network. Active/Active failover is available only on units running in multiple context mode.
With Active/Standby failover, only one unit passes traffic while the other unit waits in a standby state. Active/Standby failover is available on units running in either single or multiple context mode.
Both failover configurations support stateful or stateless (regular) failover.
Note When the security appliance is configured for Active/Active stateful failover, you cannot enable IPsec or SSL VPN. Therefore, these features are unavailable. VPN failover is available for Active/Standby failover configurations only.
Failover System Requirements
This section describes the hardware, software, and license requirements for adaptive security appliances in a failover configuration.
Note IPv6 failover is not supported in Release 8.2(1).
This section contains the following topics:
•Hardware Requirements, page 32-2
•Software Requirements, page 32-2
Hardware Requirements
The two units in a failover configuration must have the same hardware configuration. They must be the same model, have the same number and types of interfaces, the same amount of RAM, and, for the Cisco ASA 5500 series adaptive security appliance, the same SSMs installed (if any).
Note The two units do not have to have the same size Flash memory. If you are using units with different Flash memory sizes in your failover configuration, make sure the unit with the smaller Flash memory has enough space to accommodate the software image files and the configuration files. If it does not, configuration synchronization from the unit with the larger Flash memory to the unit with the smaller Flash memory fails.
Software Requirements
The two units in a failover configuration must be in the same operating modes (routed or transparent, single or multiple context). They must have the same major (first number) and minor (second number) software version. However, you can use different versions of the software during an upgrade process; for example, you can upgrade one unit from Version 7.0(1) to Version 7.0(2) and have failover remain active. We recommend upgrading both units to the same version to ensure long-term compatibility.
See "Performing Zero Downtime Upgrades for Failover Pairs" section on page 77-5 for more information about upgrading the software on a failover pair.
Failover and Stateful Failover Links
This section describes the failover and the Stateful Failover links, which are dedicated connections between the two units in a failover configuration. This section includes the following topics:
•Failover Link, page 32-3
•Stateful Failover Link, page 32-4
Failover Link
The two units in a failover pair constantly communicate over a failover link to determine the operating status of each unit. The following information is communicated over the failover link:
•The unit state (active or standby)
•Hello messages (keep-alives)
•Network link status
•MAC address exchange
•Configuration replication and synchronization
Caution All information sent over the failover and Stateful Failover links is sent in clear text unless you secure the communication with a failover key. If the adaptive security appliance is used to terminate VPN tunnels, this information includes any usernames, passwords and preshared keys used for establishing the tunnels. Transmitting this sensitive data in clear text could pose a significant security risk. We recommend securing the failover communication with a failover key if you are using the adaptive security appliance to terminate VPN tunnels.
The adaptive security appliance failover link can be a LAN-based connection only.
LAN-Based Failover Link
You can use any unused Ethernet interface on the device as the failover link; however, you cannot specify an interface that is currently configured with a name. The LAN failover link interface is not configured as a normal networking interface. It exists for failover communication only. This interface should only be used for the LAN failover link (and optionally for the stateful failover link).
Connect the LAN failover link in one of the following two ways:
•Using a switch, with no other device on the same network segment (broadcast domain or VLAN) as the LAN failover interfaces of the adaptive security appliance.
•Using a crossover Ethernet cable to connect the appliances directly, without the need for an external switch.
Note When you use a crossover cable for the LAN failover link, if the LAN interface fails, the link is brought down on both peers. This condition may hamper troubleshooting efforts because you cannot easily determine which interface failed and caused the link to come down.
Note The adaptive security appliance supports Auto-MDI/MDIX on its copper Ethernet ports, so you can either use a crossover cable or a straight-through cable. If you use a straight-through cable, the interface automatically detects the cable and swaps one of the transmit/receive pairs to MDIX.
Stateful Failover Link
To use Stateful Failover, you must configure a Stateful Failover link to pass all state information. You have three options for configuring a Stateful Failover link:
•You can use a dedicated Ethernet interface for the Stateful Failover link.
•If you are using LAN-based failover, you can share the failover link.
•You can share a regular data interface, such as the inside interface. However, this option is not recommended.
If you are using a dedicated Ethernet interface for the Stateful Failover link, you can use either a switch or a crossover cable to directly connect the units. If you use a switch, no other hosts or routers should be on this link.
Note Enable the PortFast option on Cisco switch ports that connect directly to the adaptive security appliance.
If you use a data interface as the Stateful Failover link, you receive the following warning when you specify that interface as the Stateful Failover link:
******* WARNING ***** WARNING ******* WARNING ****** WARNING *********
Sharing Stateful failover interface with regular data interface is not
a recommended configuration due to performance and security concerns.
******* WARNING ***** WARNING ******* WARNING ****** WARNING *********
Sharing a data interface with the Stateful Failover interface can leave you vulnerable to replay attacks. Additionally, large amounts of Stateful Failover traffic may be sent on the interface, causing performance problems on that network segment.
Note Using a data interface as the Stateful Failover interface is supported in single context, routed mode only.
In multiple context mode, the Stateful Failover link resides in the system context. This interface and the failover interface are the only interfaces in the system context. All other interfaces are allocated to and configured from within security contexts.
Note The IP address and MAC address for the Stateful Failover link does not change at failover unless the Stateful Failover link is configured on a regular data interface.
Caution All information sent over the failover and Stateful Failover links is sent in clear text unless you secure the communication with a failover key. If the adaptive security appliance is used to terminate VPN tunnels, this information includes any usernames, passwords, and preshared keys used for establishing the tunnels. Transmitting this sensitive data in clear text could pose a significant security risk. We recommend securing the failover communication with a failover key if you are using the adaptive security appliance to terminate VPN tunnels.
Failover Interface Speed for Stateful Links
If you use the failover link as the Stateful Failover link, you should use the fastest Ethernet interface available. If you experience performance problems on that interface, consider dedicating a separate interface for the Stateful Failover interface.
Use the following failover interface speed guidelines for the adaptive security appliances:
•Cisco ASA 5510
–Stateful link speed can be 100 Mbps, even though the data interface can operate at 1 Gigabit due to the CPU speed limitation.
•Cisco ASA 5520/5540/5550
–Stateful link speed should match the fastest data link.
•Cisco ASA 5580
–Use only non-management 1 Gigabit ports for the stateful link because management ports have lower performance and cannot meet the performance requirement for stateful failover.
For optimum performance when using long distance LAN failover, the latency for the failover link should be less than 10 milliseconds and no more than 250 milliseconds. If latency is more than10 milliseconds, some performance degradation occurs due to retransmission of failover messages.
All platforms support sharing of failover heartbeat and stateful link, but we recommend using a separate heartbeat link on systems with high Stateful Failover traffic.
Active/Active and Active/Standby Failover
This section describes each failover configuration in detail, and it includes the following topics:
•Active/Standby Failover, page 32-5
•Active/Active Failover, page 32-9
•Determining Which Type of Failover to Use, page 32-14
Active/Standby Failover
This section describes Active/Standby failover, andit includes the following topics:
•Information About Active/Standby Failover, page 32-5
•Primary/Secondary Status and Active/Standby Status, page 32-6
•Device Initialization and Configuration Synchronization, page 32-6
•Command Replication, page 32-7
•Failover Triggers, page 32-8
•Failover Actions, page 32-8
Information About Active/Standby Failover
Active/Standby failover lets you use a standby adaptive security appliance to take over the functionality of a failed unit. When the active unit fails, it changes to the standby state while the standby unit changes to the active state. The unit that becomes active assumes the IP addresses (or, for transparent firewall, the management IP address) and MAC addresses of the failed unit and begins passing traffic. The unit that is now in standby state takes over the standby IP addresses and MAC addresses. Because network devices see no change in the MAC to IP address pairing, no ARP entries change or time out anywhere on the network.
Note For multiple context mode, the adaptive security appliance can fail over the entire unit (including all contexts) but cannot fail over individual contexts separately.
Primary/Secondary Status and Active/Standby Status
The main differences between the two units in a failover pair are related to which unit is active and which unit is standby, namely which IP addresses to use and which unit actively passes traffic.
However, a few differences exist between the units based on which unit is primary (as specified in the configuration) and which unit is secondary:
•The primary unit always becomes the active unit if both units start up at the same time (and are of equal operational health).
•The primary unit MAC addresses are always coupled with the active IP addresses. The exception to this rule occurs when the secondary unit is active and cannot obtain the primary unit MAC addresses over the failover link. In this case, the secondary unit MAC addresses are used.
Device Initialization and Configuration Synchronization
Configuration synchronization occurs when one or both devices in the failover pair boot. Configurations are always synchronized from the active unit to the standby unit. When the standby unit completes its initial startup, it clears its running configuration (except for the failover commands needed to communicate with the active unit), and the active unit sends its entire configuration to the standby unit.
The active unit is determined by the following:
•If a unit boots and detects a peer already running as active, it becomes the standby unit.
•If a unit boots and does not detect a peer, it becomes the active unit.
•If both units boot simultaneously, then the primary unit becomes the active unit and the secondary unit becomes the standby unit.
Note If the secondary unit boots without detecting the primary unit, it becomes the active unit. It uses its own MAC addresses for the active IP addresses. However, when the primary unit becomes available, the secondary unit changes the MAC addresses to those of the primary unit, which can cause an interruption in your network traffic. To avoid this, configure the failover pair with virtual MAC addresses. See the "Configuring Virtual MAC Addresses" section on page 33-16 for more information.
When the replication starts, the adaptive security appliance console on the active unit displays the message "Beginning configuration replication: Sending to mate," and when it is complete, the adaptive security appliance displays the message "End Configuration Replication to mate." During replication, commands entered on the active unit may not replicate properly to the standby unit, and commands entered on the standby unit may be overwritten by the configuration being replicated from the active unit. Avoid entering commands on either unit in the failover pair during the configuration replication process. Depending upon the size of the configuration, replication can take from a few seconds to several minutes.
Note The crypto ca server command and related sub-commands are not synchronized to the failover peer.
On the standby unit, the configuration exists only in running memory. To save the configuration to Flash memory after synchronization, do the following:
•For single context mode, enter the write memory command on the active unit. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory.
•For multiple context mode, enter the write memory all command on the active unit from the system execution space. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory. Using the all keyword with this command causes the system and all context configurations to be saved.
Note Startup configurations saved on external servers are accessible from either unit over the network and do not need to be saved separately for each unit. Alternatively, you can copy the contexts on disk from the active unit to an external server, and then copy them to disk on the standby unit, where they become available when the unit reloads.
Command Replication
Command replication always flows from the active unit to the standby unit. As commands are entered on the active unit, they are sent across the failover link to the standby unit. You do not have to save the active configuration to Flash memory to replicate the commands.
Table 32-1 lists the commands that are and are not replicated to the standby unit.
Table 32-1 Command Replication
Commands Replicated to the Standby Unit
|
Commands Not Replicated to the Standby Unit
|
all configuration commands except for the mode, firewall, and failover lan unit commands
|
all forms of the copy command except for copy running-config startup-config
|
copy running-config startup-config
|
all forms of the write command except for write memory
|
delete
|
crypto ca server and associated sub-commands
|
mkdir
|
debug
|
rename
|
failover lan unit
|
rmdir
|
firewall
|
write memory
|
mode
|
—
|
show
|
Note Changes made on the standby unit are not replicated to the active unit. If you enter a command on the standby unit, the adaptive security appliance displays the message **** WARNING **** Configuration Replication is NOT performed from Standby unit to Active unit. Configurations are no longer synchronized. This message displays even when you enter many commands that do not affect the configuration.
If you enter the write standby command on the active unit, the standby unit clears its running configuration (except for the failover commands used to communicate with the active unit), and the active unit sends its entire configuration to the standby unit.
For multiple context mode, when you enter the write standby command in the system execution space, all contexts are replicated. If you enter the write standby command within a context, the command replicates only the context configuration.
Replicated commands are stored in the running configuration. To save the replicated commands to the Flash memory on the standby unit, do the following:
•For single context mode, enter the copy running-config startup-config command on the active unit. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory.
•For multiple context mode, enter the copy running-config startup-config command on the active unit from the system execution space and within each context on disk. The command is replicated to the standby unit, which proceeds to write its configuration to Flash memory. Contexts with startup configurations on external servers are accessible from either unit over the network and do not need to be saved separately for each unit. Alternatively, you can copy the contexts on disk from the active unit to an external server and then copy them to disk on the standby unit.
Failover Triggers
The unit can fail if one of the following events occurs:
•The unit has a hardware failure or a power failure.
•The unit has a software failure.
•Too many monitored interfaces fail.
•The no failover active command is entered on the active unit, or the failover active command is entered on the standby unit.
Failover Actions
In Active/Standby failover, failover occurs on a unit basis. Even on systems running in multiple context mode, you cannot fail over individual or groups of contexts.
Table 32-2 shows the failover action for each failure event. For each failure event, the table shows the failover policy (failover or no failover), the action taken by the active unit, the action taken by the standby unit, and any special notes about the failover condition and actions.
Table 32-2 Failover Behavior
Failure Event
|
Policy
|
Active Action
|
Standby Action
|
Notes
|
Active unit failed (power or hardware)
|
Failover
|
n/a
|
Become active
Mark active as failed
|
No hello messages are received on any monitored interface or the failover link.
|
Formerly active unit recovers
|
No failover
|
Become standby
|
No action
|
None.
|
Standby unit failed (power or hardware)
|
No failover
|
Mark standby as failed
|
n/a
|
When the standby unit is marked as failed, then the active unit does not attempt to fail over, even if the interface failure threshold is surpassed.
|
Failover link failed during operation
|
No failover
|
Mark failover interface as failed
|
Mark failover interface as failed
|
You should restore the failover link as soon as possible because the unit cannot fail over to the standby unit while the failover link is down.
|
Failover link failed at startup
|
No failover
|
Mark failover interface as failed
|
Become active
|
If the failover link is down at startup, both units become active.
|
Stateful Failover link failed
|
No failover
|
No action
|
No action
|
State information becomes out of date, and sessions are terminated if a failover occurs.
|
Interface failure on active unit above threshold
|
Failover
|
Mark active as failed
|
Become active
|
None.
|
Interface failure on standby unit above threshold
|
No failover
|
No action
|
Mark standby as failed
|
When the standby unit is marked as failed, then the active unit does not attempt to fail over even if the interface failure threshold is surpassed.
|
Active/Active Failover
This section describes Active/Active failover. This section includes the following topics:
•Information About Active/Active Failover, page 32-9
•Primary/Secondary Status and Active/Standby Status, page 32-10
•Device Initialization and Configuration Synchronization, page 32-11
•Command Replication, page 32-11
•Failover Triggers, page 32-12
•Failover Actions, page 32-13
Information About Active/Active Failover
Active/Active failover is only available to adaptive security appliances in multiple context mode. In an Active/Active failover configuration, both adaptive security appliances can pass network traffic.
In Active/Active failover, you divide the security contexts on the adaptive security appliance into failover groups. A failover group is simply a logical group of one or more security contexts. You can create a maximum of two failover groups on the adaptive security appliance. The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default.
The failover group forms the base unit for failover in Active/Active failover. Interface failure monitoring, failover, and active/standby status are all attributes of a failover group rather than the unit. When an active failover group fails, it changes to the standby state while the standby failover group becomes active. The interfaces in the failover group that becomes active assume the MAC and IP addresses of the interfaces in the failover group that failed. The interfaces in the failover group that is now in the standby state take over the standby MAC and IP addresses.
Note A failover group failing on a unit does not mean that the unit has failed. The unit may still have another failover group passing traffic on it.
When creating the failover groups, you should create them on the unit that will have failover group 1 in the active state.
Note Active/Active failover generates virtual MAC addresses for the interfaces in each failover group. If you have more than one Active/Active failover pair on the same network, it is possible to have the same default virtual MAC addresses assigned to the interfaces on one pair as are assigned to the interfaces of the other pairs because of the way the default virtual MAC addresses are determined. To avoid having duplicate MAC addresses on your network, make sure you assign each physical interface a virtual active and standby MAC address.
Primary/Secondary Status and Active/Standby Status
As in Active/Standby failover, one unit in an Active/Active failover pair is designated the primary unit, and the other unit the secondary unit. Unlike Active/Standby failover, this designation does not indicate which unit becomes active when both units start simultaneously. Instead, the primary/secondary designation does two things:
•Determines which unit provides the running configuration to the pair when they boot simultaneously.
•Determines on which unit each failover group appears in the active state when the units boot simultaneously. Each failover group in the configuration is configured with a primary or secondary unit preference. You can configure both failover groups be in the active state on a single unit in the pair, with the other unit containing the failover groups in the standby state. However, a more typical configuration is to assign each failover group a different role preference to make each one active on a different unit, distributing the traffic across the devices.
Note The adaptive security appliance also provides load balancing, which is different from failover. Both failover and load balancing can exist on the same configuration. For information about load balancing, see Understanding Load Balancing, page 63-6.
You can determine which unit each failover group becomes active on in the following ways:
•When a unit boots while the peer unit is not available, both failover groups become active on the unit.
•When a unit boots while the peer unit is active (with both failover groups in the active state), the failover groups remain in the active state on the active unit regardless of the primary or secondary preference of the failover group until one of the following occurs:
–A failover occurs.
–You manually force the failover group to the other unit with the no failover active command.
–You configured the failover group with the preempt command, which causes the failover group to automatically become active on the preferred unit when the unit becomes available.
•When both units boot at the same time, each failover group becomes active on its preferred unit after the configurations have been synchronized.
Device Initialization and Configuration Synchronization
Configuration synchronization occurs when one or both units in a failover pair boot. The configurations are synchronized as follows:
•When a unit boots while the peer unit is active (with both failover groups active on it), the booting unit contacts the active unit to obtain the running configuration regardless of the primary or secondary designation of the booting unit.
•When both units boot simultaneously, the secondary unit obtains the running configuration from the primary unit.
When the replication starts, the adaptive security appliance console on the unit sending the configuration displays the message "Beginning configuration replication: Sending to mate," and when it is complete, the adaptive security appliance displays the message "End Configuration Replication to mate." During replication, commands entered on the unit sending the configuration may not replicate properly to the peer unit, and commands entered on the unit receiving the configuration may be overwritten by the configuration being received. Avoid entering commands on either unit in the failover pair during the configuration replication process. Depending upon the size of the configuration, replication can take from a few seconds to several minutes.
On the unit receiving the configuration, the configuration exists only in running memory. To save the configuration to Flash memory after synchronization enter the write memory all command in the system execution space on the unit that has failover group 1 in the active state. The command is replicated to the peer unit, which proceeds to write its configuration to Flash memory. Using the all keyword with this command causes the system and all context configurations to be saved.
Note Startup configurations saved on external servers are accessible from either unit over the network and do not need to be saved separately for each unit. Alternatively, you can copy the contexts configuration files from the disk on the primary unit to an external server, and then copy them to disk on the secondary unit, where they become available when the unit reloads.
Command Replication
After both units are running, commands are replicated from one unit to the other as follows:
•Commands entered within a security context are replicated from the unit on which the security context appears in the active state to the peer unit.
Note A context is considered in the active state on a unit if the failover group to which it belongs is in the active state on that unit.
•Commands entered in the system execution space are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
•Commands entered in the admin context are replicated from the unit on which failover group 1 is in the active state to the unit on which failover group 1 is in the standby state.
Failure to enter the commands on the appropriate unit for command replication to occur causes the configurations to be out of synchronization. Those changes may be lost the next time the initial configuration synchronization occurs.
Table 32-3 shows the commands that are and are not replicated to the standby unit:
Table 32-3 Command Replication
Commands Replicated to the Standby Unit
|
Commands Not Replicated to the Standby Unit
|
all configuration commands except for the mode, firewall, and failover lan unit commands
|
all forms of the copy command except for copy running-config startup-config
|
copy running-config startup-config
|
all forms of the write command except for write memory
|
delete
|
debug
|
mkdir
|
failover lan unit
|
rename
|
firewall
|
rmdir
|
mode
|
write memory
|
show
|
You can use the write standby command to resynchronize configurations that have become out of sync. For Active/Active failover, the write standby command behaves as follows:
•If you enter the write standby command in the system execution space, the system configuration and the configurations for all of the security contexts on the adaptive security appliance is written to the peer unit. This includes configuration information for security contexts that are in the standby state. You must enter the command in the system execution space on the unit that has failover group 1 in the active state.
Note If there are security contexts in the active state on the peer unit, the write standby command causes active connections through those contexts to be terminated. Use the failover active command on the unit providing the configuration to make sure all contexts are active on that unit before entering the write standby command.
•If you enter the write standby command in a security context, only the configuration for the security context is written to the peer unit. You must enter the command in the security context on the unit where the security context appears in the active state.
Replicated commands are not saved to the Flash memory when replicated to the peer unit. They are added to the running configuration. To save replicated commands to Flash memory on both units, use the write memory or copy running-config startup-config command on the unit upon which you made the changes. The command is replicated to the peer unit and cause the configuration to be saved to Flash memory on the peer unit.
Failover Triggers
In Active/Active failover, failover can be triggered at the unit level if one of the following events occurs:
•The unit has a hardware failure.
•The unit has a power failure.
•The unit has a software failure.
•The no failover active or the failover active command is entered in the system execution space.
Failover is triggered at the failover group level when one of the following events occurs:
•Too many monitored interfaces in the group fail.
•The no failover active group group_id or failover active group group_id command is entered.
You configure the failover threshold for each failover group by specifying the number or percentage of interfaces within the failover group that must fail before the group fails. Because a failover group can contain multiple contexts, and each context can contain multiple interfaces, it is possible for all interfaces in a single context to fail without causing the associated failover group to fail.
See the "Failover Health Monitoring" section on page 32-16 for more information about interface and unit monitoring.
Failover Actions
In an Active/Active failover configuration, failover occurs on a failover group basis, not a system basis. For example, if you designate both failover groups as active on the primary unit, and failover group 1 fails, then failover group 2 remains active on the primary unit while failover group 1 becomes active on the secondary unit.
Note When configuring Active/Active failover, make sure that the combined traffic for both units is within the capacity of each unit.
Table 32-4 shows the failover action for each failure event. For each failure event, the policy (whether or not failover occurs), actions for the active failover group, and actions for the standby failover group are given.
Table 32-4 Failover Behavior for Active/Active Failover
Failure Event
|
Policy
|
Active Group Action
|
Standby Group Action
|
Notes
|
A unit experiences a power or software failure
|
Failover
|
Become standby Mark as failed
|
Become active
Mark active as failed
|
When a unit in a failover pair fails, any active failover groups on that unit are marked as failed and become active on the peer unit.
|
Interface failure on active failover group above threshold
|
Failover
|
Mark active group as failed
|
Become active
|
None.
|
Interface failure on standby failover group above threshold
|
No failover
|
No action
|
Mark standby group as failed
|
When the standby failover group is marked as failed, the active failover group does not attempt to fail over, even if the interface failure threshold is surpassed.
|
Formerly active failover group recovers
|
No failover
|
No action
|
No action
|
Unless configured with the preempt command, the failover groups remain active on their current unit.
|
Failover link failed at startup
|
No failover
|
Become active
|
Become active
|
If the failover link is down at startup, both failover groups on both units become active.
|
Stateful Failover link failed
|
No failover
|
No action
|
No action
|
State information becomes out of date, and sessions are terminated if a failover occurs.
|
Failover link failed during operation
|
No failover
|
n/a
|
n/a
|
Each unit marks the failover interface as failed. You should restore the failover link as soon as possible because the unit cannot fail over to the standby unit while the failover link is down.
|
Determining Which Type of Failover to Use
The type of failover you choose depends upon your adaptive security appliance configuration and how you plan to use the adaptive security appliances.
If you are running the adaptive security appliance in single mode, then you can use only Active/Standby failover. Active/Active failover is only available to adaptive security appliances running in multiple context mode.
If you are running the adaptive security appliance in multiple context mode, then you can configure either Active/Active failover or Active/Standby failover.
•To allow both members of the failover pair to share the traffic, use Active/Active failover. Do not exceed 50% load on each device.
•If you do not want to share the traffic in this way, use Active/Standby or Active/Active failover.
Table 32-5 provides a comparison of some of the features supported by each type of failover configuration:
Table 32-5 Failover Configuration Feature Support
Feature
|
Active/Active
|
Active/Standby
|
Single Context Mode
|
No
|
Yes
|
Multiple Context Mode
|
Yes
|
Yes
|
Traffic Sharing Network Configurations
|
Yes
|
No
|
Unit Failover
|
Yes
|
Yes
|
Failover of Groups of Contexts
|
Yes
|
No
|
Failover of Individual Contexts
|
No
|
No
|
Stateless (Regular) and Stateful Failover
The adaptive security appliance supports two types of failover, regular and stateful. This section includes the following topics:
•Stateless (Regular) Failover, page 32-15
•Stateful Failover, page 32-15
Stateless (Regular) Failover
When a failover occurs, all active connections are dropped. Clients need to reestablish connections when the new active unit takes over.
Note In Release 8.0 and later, some configuration elements for WebVPN (such as bookmarks and customization) use the VPN failover subsystem, which is part of Stateful Failover. You must use Stateful Failover to synchronize these elements between the members of the failover pair. Stateless (regular) failover is not recommended for WebVPN.
Stateful Failover
When Stateful Failover is enabled, the active unit continually passes per-connection state information to the standby unit. After a failover occurs, the same connection information is available at the new active unit. Supported end-user applications are not required to reconnect to keep the same communication session.
Table 32-6 list the state information that is and is not passed to the standby unit when Stateful Failover is enabled.
Table 32-6 State Information
State Information Passed to Standby Unit
|
State Information Not Passed to Standby Unit
|
NAT translation table
|
The HTTP connection table (unless HTTP replication is enabled).
|
TCP connection states
|
The user authentication (uauth) table.
|
UDP connection states
|
The routing tables. After a failover occurs, some packets may be lost or routed out of the wrong interface (the default route) while the dynamic routing protocols rediscover routes.
|
The ARP table
|
State information for Security Service Modules.
|
The Layer 2 bridge table (when running in transparent firewall mode)
|
DHCP server address leases.
|
The HTTP connection states (if HTTP replication is enabled)
|
Stateful failover for phone proxy. When the active unit goes down, the call fails, media stops flowing, and the phone should unregister from the failed unit and reregister with the active unit. The call must be re-established.
|
The ISAKMP and IPSec SA table
|
—
|
GTP PDP connection database
|
—
|
SIP signalling sessions
|
—
|
The following WebVPN features are not supported with Stateful Failover:
•Smart Tunnels
•Port Forwarding
•Plugins
•Java Applets
•IPv6 clientless or Anyconnect sessions
•Citrix authentication (Citrix users must reauthenticate after failover)
Note If failover occurs during an active Cisco IP SoftPhone session, the call remains active because the call session state information is replicated to the standby unit. When the call is terminated, the IP SoftPhone client loses connection with the Cisco CallManager. This occurs because there is no session information for the CTIQBE hangup message on the standby unit. When the IP SoftPhone client does not receive a response back from the Call Manager within a certain time period, it considers the CallManager unreachable and unregisters itself.
For VPN failover, VPN end-users should not have to reauthenticate or reconnect the VPN session in the event of a failover. However, applications operating over the VPN connection could lose packets during the failover process and not recover from the packet loss.
Failover Health Monitoring
The adaptive security appliance monitors each unit for overall health and for interface health. See the following sections for more information about how the adaptive security appliance performs tests to determine the state of each unit:
•Unit Health Monitoring, page 32-17
•Interface Monitoring, page 32-17
Unit Health Monitoring
The adaptive security appliance determines the health of the other unit by monitoring the failover link. When a unit does not receive three consecutive hello messages on the failover link, the unit sends interface hello messages on each interface, including the failover interface, to validate whether or not the peer interface is responsive. The action that the adaptive security appliance takes depends upon the response from the other unit. See the following possible actions:
•If the adaptive security appliance receives a response on the failover interface, then it does not fail over.
•If the adaptive security appliance does not receive a response on the failover link, but it does receive a response on another interface, then the unit does not failover. The failover link is marked as failed. You should restore the failover link as soon as possible because the unit cannot fail over to the standby while the failover link is down.
•If the adaptive security appliance does not receive a response on any interface, then the standby unit switches to active mode and classifies the other unit as failed.
Note If a failed unit does not recover, and you believe it should not be failed, you can reset the state by entering the failover reset command. If the failover condition persists, however, the unit will fail again.
You can configure the frequency of the hello messages and the hold time before failover occurs. A faster poll time and shorter hold time speed the detection of unit failures and make failover occur more quickly, but it can also cause "false" failures due to network congestion delaying the keepalive packets. See Configuring Interface Health Monitoring, page 33-15 for more information about configuring unit health monitoring.
Interface Monitoring
You can monitor up to 250 interfaces divided between all contexts. You should monitor important interfaces. For example, you might configure one context to monitor a shared interface. (Because the interface is shared, all contexts benefit from the monitoring.)
When a unit does not receive hello messages on a monitored interface for half of the configured hold time, it runs the following tests:
1. Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the interface is operational, then the adaptive security appliance performs network tests. The purpose of these tests is to generate network traffic to determine which (if either) unit has failed. At the start of each test, each unit clears its received packet count for its interfaces. At the conclusion of each test, each unit looks to see if it has received any traffic. If it has, the interface is considered operational. If one unit receives traffic for a test and the other unit does not, the unit that received no traffic is considered failed. If neither unit has received traffic, then the next test is used.
2. Network Activity test—A received network activity test. The unit counts all received packets for up to 5 seconds. If any packets are received at any time during this interval, the interface is considered operational and testing stops. If no traffic is received, the ARP test begins.
3. ARP test—A reading of the unit ARP cache for the 2 most recently acquired entries. One at a time, the unit sends ARP requests to these machines, attempting to stimulate network traffic. After each request, the unit counts all received traffic for up to 5 seconds. If traffic is received, the interface is considered operational. If no traffic is received, an ARP request is sent to the next machine. If at the end of the list no traffic has been received, the ping test begins.
4. Broadcast Ping test—A ping test that consists of sending out a broadcast ping request. The unit then counts all received packets for up to 5 seconds. If any packets are received at any time during this interval, the interface is considered operational and testing stops.
If all network tests fail for an interface, but this interface on the other unit continues to successfully pass traffic, then the interface is considered to be failed. If the threshold for failed interfaces is met, then a failover occurs. If the other unit interface also fails all the network tests, then both interfaces go into the "Unknown" state and do not count towards the failover limit.
An interface becomes operational again if it receives any traffic. A failed adaptive security appliance returns to standby mode if the interface failure threshold is no longer met.
Note If a failed unit does not recover and you believe it should not be failed, you can reset the state by entering the failover reset command. If the failover condition persists, however, the unit will fail again.
Failover Feature/Platform Matrix
Table 32-7 shows the failover features supported by each hardware platform.
Table 32-7 Failover Feature Support by Platform
Platform
|
Cable-Based Failover
|
LAN-Based Failover
|
Stateful Failover
|
Active/Standby Failover
|
Active/Active Failover
|
Cisco ASA 5505 adaptive security appliance
|
No
|
Yes
|
No
|
Yes
|
No
|
Cisco ASA 5500 series adaptive security appliance (other than the ASA 5505)
|
No
|
Yes
|
Yes
|
Yes
|
Yes
|
Cisco PIX 500 series security appliance
|
Yes
|
Yes
|
Yes
|
Yes
|
Yes
|
Failover Times by Platform
Table 32-8 shows the minimum, default, and maximum failover times for the Cisco PIX 500 series security appliance.
Table 32-8 Cisco PIX 500 Series Security Appliance Failover Times.
Failover Condition
|
Minimum
|
Default
|
Maximum
|
Active unit loses power or stops normal operation.
|
800 milliseconds
|
45 seconds
|
45 seconds
|
Active unit interface link down.
|
500 milliseconds
|
5 seconds
|
15 seconds
|
Active unit interface up, but connection problem causes interface testing.
|
5 seconds
|
25 seconds
|
75 seconds
|
Table 32-9 shows the minimum, default, and maximum failover times for the Cisco ASA 5500 series adaptive security appliance.
Table 32-9 Cisco ASA 5500 Series Adaptive Security Appliance Failover Times
Failover Condition
|
Minimum
|
Default
|
Maximum
|
Active unit loses power or stops normal operation.
|
800 milliseconds
|
15 seconds
|
45 seconds
|
Active unit main board interface link down.
|
500 milliseconds
|
5 seconds
|
15 seconds
|
Active unit 4GE card interface link down.
|
2 seconds
|
5 seconds
|
15 seconds
|
Active unit IPS or CSC card fails.
|
2 seconds
|
2 seconds
|
2 seconds
|
Active unit interface up, but connection problem causes interface testing.
|
5 seconds
|
25 seconds
|
75 seconds
|
