Active Active Failover
This section describes Active/Active failover. This section includes the following topics:
• Active/Active Failover Overview, page 14-10
• Primary/Secondary Status and Active/Standby Status, page 14-10
• Device Initialization and Configuration Synchronization, page 14-11
• Command Replication, page 14-12
• Failover Triggers, page 14-13
• Failover Actions, page 14-13
Active/Active Failover Overview
Active/Active failover is only available to security appliances in multiple context mode. In an Active/Active failover configuration, both security appliances can pass network traffic.
In Active/Active failover, you divide the security contexts on the 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 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 security appliance does not provide load balancing services. Load balancing must be handled by a router passing traffic to the security appliance.
Which unit each failover group becomes active on is determined as follows:
• 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:
- 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 security appliance console on the unit sending the configuration displays the message "Beginning configuration replication: Sending to mate," and when it is complete, the 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.
All configuration and file commands (copy, rename, delete, mkdir, rmdir, and so on) are replicated, with the following exceptions. The show, debug, mode, firewall, and failover lan unit commands are not replicated.
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.
The following commands are replicated to the standby unit:
• all configuration commands except for the mode, firewall, and failover lan unit commands
• copy running-config startup-config
• write memory
The following commands are not replicated to the standby unit:
• all forms of the copy command except for copy running-config startup-config
• all forms of the write command except for write memory
• failover lan unit
• firewall
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 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 that you made the changes on. 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 14-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 14-2 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.
_Chapter 14 Configuring Failover |
H Understanding 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. |
Continue reading here: Interface Monitoring
Was this article helpful?