This chapter describes how to configure Active/Standby or Active/Active failover to accomplish high availability of the Cisco ASA.
Configuring failover requires two identical ASAs connected to each other through a dedicated failover link and, optionally, a state link. The health of the active units and interfaces is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs.
The ASA supports two failover modes, Active/Active failover and Active/Standby failover. Each failover mode has its own method for determining and performing failover.
This section describes the hardware, software, and license requirements for ASAs in a failover configuration.
The two units in a failover configuration must:
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 will fail.
The two units in a failover configuration must:
See Upgrade a Failover Pair or ASA Cluster for more information about upgrading the software on a failover pair.
The two units in a failover configuration do not need to have identical licenses; the licenses combine to make a failover cluster license. See Failover or ASA Cluster Licenses for more information.
The failover link and the optional Stateful Failover link are dedicated connections between the two units.
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:
You can use any unused interface (physical, redundant, or EtherChannel) as the failover link; however, you cannot specify an interface that is currently configured with a name. The failover link interface is not configured as a normal networking interface; it exists for failover communication only. This interface can only be used for the failover link (and optionally also for the state link). The ASA does not support sharing interfaces between user data and the failover link even if different subinterfaces are configured for user data and failover. A separate physical, EtherChannel, or redundant interface must be used for the failover link.
For a redundant interface used as the failover link, see the following benefits for added redundancy:
For an EtherChannel used as the failover link, to prevent out-of-order packets, only one interface in the EtherChannel is used. If that interface fails, then the next interface in the EtherChannel is used. You cannot alter the EtherChannel configuration while it is in use as a failover link.
Connect the failover link in one of the following two ways:
If you do not use a switch between the units, if the interface fails, the link is brought down on both peers. This condition may hamper troubleshooting efforts because you cannot easily determine which unit has the failed interface and caused the link to come down.
The ASA 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.
To use Stateful Failover, you must configure a Stateful Failover link (also known as the state link) to pass connection state information.
You have three interface options for the state link:
Note
Do not use a management interface for the state link.
You can use a dedicated interface (physical, redundant, or EtherChannel) for the state link. For an EtherChannel used as the state link, to prevent out-of-order packets, only one interface in the EtherChannel is used. If that interface fails, then the next interface in the EtherChannel is used.
Connect a dedicated state link in one of the following two ways:
If you do not use a switch between the units, if the interface fails, the link is brought down on both peers. This condition may hamper troubleshooting efforts because you cannot easily determine which unit has the failed interface and caused the link to come down.
The ASA 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.
For optimum performance when using long distance 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.
Sharing a failover link might be necessary if you do not have enough interfaces. If you use the failover link as the state link, you should use the fastest Ethernet interface available. If you experience performance problems on that interface, consider dedicating a separate interface for the state link.
Sharing a data interface with the state link 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.
Using a data interface as the state link is supported in single context, routed mode only.
We recommend that failover links and data interfaces travel through different paths to decrease the chance that all interfaces fail at the same time. If the failover link is down, the ASA can use the data interfaces to determine if a failover is required. Subsequently, the failover operation is suspended until the health of the failover link is restored.
See the following connection scenarios to design a resilient failover network.
If a single switch or a set of switches are used to connect both failover and data interfaces between two ASAs, then when a switch or inter-switch-link is down, both ASAs become active. Therefore, the following two connection methods shown in Figure 7-1 and Figure 7-2 are NOT recommended.
Figure 7-1 Connecting with a Single Switch—Not Recommended
Figure 7-2 Connecting with a Double Switch—Not Recommended
We recommend that failover links NOT use the same switch as the data interfaces. Instead, use a different switch or use a direct cable to connect the failover link, as shown in Figure 7-3 and Figure 7-4.
Figure 7-3 Connecting with a Different Switch
Figure 7-4 Connecting with a Cable
If the ASA data interfaces are connected to more than one set of switches, then a failover link can be connected to one of the switches, preferably the switch on the secure (inside) side of network, as shown in Figure 7-5.
Figure 7-5 Connecting with a Secure Switch
The most reliable failover configurations use a redundant interface on the failover link, as shown in Figure 7-6 and Figure 7-7.
Figure 7-6 Connecting with Redundant Interfaces
Figure 7-7 Connecting with Inter-switch Links
When you configure your interfaces, you must specify an active IP address and a standby IP address on the same network.
1.
When the primary unit or failover group fails over, the secondary unit assumes the IP addresses and MAC addresses of the primary unit and begins passing traffic.
2.
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
If the secondary unit boots without detecting the primary unit, the secondary unit becomes the active unit and uses its own MAC addresses, because it does not know the primary unit MAC addresses. However, when the primary unit becomes available, the secondary (active) unit changes the MAC addresses to those of the primary unit, which can cause an interruption in your network traffic.Similarly, if you swap out the primary unit with new hardware, a new MAC address is used.
Virtual MAC addresses guard against this disruption because the active MAC addresses are known to the secondary unit at startup, and remain the same in the case of new primary unit hardware. In multiple context mode, the ASA generates virtual active and standby MAC addresses by default. See About MAC Addresses for more information. In single context mode, you can manually configure virtual MAC addresses; see Configure Active/Active Failover for more information.
If you do not configure virtual MAC addresses, you might need to clear the ARP tables on connected routers to restore traffic flow. The ASA does not send gratuitous ARPs for static NAT addresses when the MAC address changes, so connected routers do not learn of the MAC address change for these addresses.
Note
The IP address and MAC address for the state link do not change at failover; the only exception is if the state link is configured on a regular data interface.
You can place the primary and secondary ASASMs within the same switch or in two separate switches. The following sections describe each option:
If you install the secondary ASASM in the same switch as the primary ASASM, you protect against module-level failure. To protect against switch-level failure, as well as module-level failure, see Inter-Chassis Failover.
Even though both ASASMs are assigned the same VLANs, only the active module takes part in networking. The standby module does not pass any traffic.
Figure 7-8 shows a typical intra-switch configuration.
Figure 7-8 Intra-Switch Failover
To protect against switch-level failure, you can install the secondary ASASM in a separate switch. The ASASM does not coordinate failover directly with the switch, but it works harmoniously with the switch failover operation. See the switch documentation to configure failover for the switch.
For the best reliability of failover communications between ASASMs, we recommend that you configure an EtherChannel trunk port between the two switches to carry the failover and state VLANs.
For other VLANs, you must ensure that both switches have access to all firewall VLANs, and that monitored VLANs can successfully pass hello packets between both switches.
Figure 7-9 shows a typical switch and ASASM redundancy configuration. The trunk between the two switches carries the failover ASASM VLANs (VLANs 10 and 11).
Note
ASASM failover is independent of the switch failover operation; however, ASASM works in any switch failover scenario.
If the primary ASASM fails, then the secondary ASASM becomes active and successfully passes the firewall VLANs (Figure 7-10).
If the entire switch fails, as well as the ASASM (such as in a power failure), then both the switch and the ASASM fail over to their secondary units (Figure 7-11).
The ASA supports two types of failover, stateless and stateful for both the Active/Standby and Active/Active modes.
Note
Some configuration elements for clientless SSL VPN (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 failover is not recommended for clientless SSL VPN.
When a failover occurs, all active connections are dropped. Clients need to reestablish connections when the new active unit takes over.
Note
Some configuration elements for clientless SSL VPN (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 clientless SSL VPN.
When Stateful Failover is enabled, the active unit continually passes per-connection state information to the standby unit, or in Active/Active failover, between the active and standby failover groups. 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.
The following state information is passed to the standby ASA when Stateful Failover is enabled:
Note
Routes are synchronized only for link-up or link-down events on an active unit. If the link goes up or down on the standby unit, dynamic routes sent from the active unit may be lost. This is normal, expected behavior.
The following state information is not passed to the standby ASA when Stateful Failover is enabled:
–
IPv6 clientless or Anyconnect sessions
–
Citrix authentication (Citrix users must reauthenticate after failover)
When the active unit fails over to the standby unit, the connected switch port running Spanning Tree Protocol (STP) can go into a blocking state for 30 to 50 seconds when it senses the topology change. To avoid traffic loss while the port is in a blocking state, you can configure one of the following workarounds depending on the switch port mode:
The PortFast feature immediately transitions the port into STP forwarding mode upon linkup. The port still participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP blocking mode.
Blocking BPDUs disables STP on the switch. Be sure not to have any loops involving the ASA in your network layout.
If neither of the above options are possible, then you can use one of the following less desirable workarounds that impacts failover functionality or STP stability:
To avoid loops when you use failover in transparent mode, you should allow BPDUs to pass (the default), and you must use switch software that supports BPDU forwarding.
Loops can occur if both modules are active at the same time, such as when both modules are discovering each other’s presence, or due to a bad failover link. Because the ASASMs bridge packets between the same two VLANs, loops can occur when inside packets destined for the outside get endlessly replicated by both ASASMs (see Figure 7-12). The spanning tree protocol can break such loops if there is a timely exchange of BPDUs. To break the loop, BPDUs sent between VLAN 200 and VLAN 201 need to be bridged.
Figure 7-12 Transparent Mode Loop
The ASA monitors each unit for overall health and for interface health. This section includes information about how the ASA performs tests to determine the state of each unit.
The ASA determines the health of the other unit by monitoring the failover link with hello messages. When a unit does not receive three consecutive hello messages on the failover link, the unit sends LANTEST messages on each data interface, including the failover link, to validate whether or not the peer is responsive. The action that the ASA takes depends on the response from the other unit. See the following possible actions:
You can monitor up to 250 interfaces (in multiple mode, divided between all contexts). You should monitor important interfaces. For example in multiple mode, 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 2 polling periods, it runs interface tests. If all interface tests fail for an interface, but this same 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 ASA returns to standby mode if the interface failure threshold is no longer met.
If you have a services module, such as the ASA FirePOWER SSP, then the ASA also monitors the health of the module over the backplane interface. Failure of the module is considered a unit failure and will trigger failover. This setting is configurable.
If an interface has IPv4 and IPv6 addresses configured on it, the ASA uses the IPv4 addresses to perform the health monitoring.
If an interface has only IPv6 addresses configured on it, then the ASA uses IPv6 neighbor discovery instead of ARP to perform the health monitoring tests. For the broadcast ping test, the ASA uses the IPv6 all nodes address (FE02::1).
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.
The ASA uses the following interface tests:
1.
Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the interface is down, then the ASA considers it failed. If the status is Up, then the ASA performs the Network Activity test.
2.
Network Activity test—A received network activity test. The purpose of this test is to generate network traffic using LANTEST messages to determine which (if either) unit has failed. At the start of the test, each unit clears its received packet count for its interfaces. As soon as a unit receives any packets during the test (up to 5 seconds), then the interface is considered operational. If one unit receives traffic and the other unit does not, then the unit that received no traffic is considered failed. If neither unit received traffic, then the ASA starts the ARP test.
3.
ARP test—A reading of the unit ARP cache for the 10 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 ASA starts the ping test.
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 no traffic is received, the testing starts over again with the ARP test.
Monitored interfaces can have the following status:
Table 7-1 shows the minimum, default, and maximum failover times.
|
|
|
|
|
|---|---|---|---|
Active unit interface up, but connection problem causes interface testing. |
Failover includes two types of configuration synchronization:
Running configuration replication 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.
When the replication starts, the ASA console on the active unit displays the message “Beginning configuration replication: Sending to mate,” and when it is complete, the ASA displays the message “End Configuration Replication to mate.” Depending on the size of the configuration, replication can take from a few seconds to several minutes.
On the standby unit, the configuration exists only in running memory. You should save the configuration to flash memory according to Save Configuration Changes.
Note
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 during the configuration replication process.
Note
The crypto ca server command and related sub commands are not synchronized to the failover peer.
Configuration syncing does not replicate the following files and configuration components, so you must copy these files manually so they match:
The ASA uses a cached file for the AnyConnect client profile stored in cache:/stc/profiles, and not the file stored in the flash file system. To replicate the AnyConnect client profile to the standby unit, perform one of the following:
–
Enter the write standby command on the active unit.
After startup, commands that you enter on the active unit are immediately replicated to the standby unit. You do not have to save the active configuration to flash memory to replicate the commands.
In Active/Active failover, commands entered in the system execution space are replicated from the unit on which failover group 1 is in the active 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.
The following commands are replicated to the standby ASA:
The following commands are not replicated to the standby ASA:
Active/Standby failover lets you use a standby ASA 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.
Note
For multiple context mode, the ASA can fail over the entire unit (including all contexts) but cannot fail over individual contexts separately.
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:
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 7-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.
In an Active/Active failover configuration, both ASAs can pass network traffic. Active/Active failover is only available to ASAs in multiple context mode. In Active/Active failover, you divide the security contexts on the ASA into a maximum of 2 failover groups.
A failover group is simply a logical group of one or more security contexts. You can assign failover group to be active on the primary ASA, and failover group 2 to be active on the secondary ASA. When a failover occurs, it occurs at the failover group level. For example, depending on interface failure patterns, it is possible for failover group 1 to fail over to the secondary ASA, and subsequently failover group 2 to fail over to the primary ASA. This event could occur if the interfaces in failover group 1 are down on the primary ASA but up on the secondary ASA, while the interfaces in failover group 2 are down on the secondary ASA but up on the primary ASA.
The admin context is always a member of failover group 1. Any unassigned security contexts are also members of failover group 1 by default. If you want Active/Active failover, but are otherwise uninterested in multiple contexts, the simplest configuration would be to add one additional context and assign it to failover group 2.
Note
When configuring Active/Active failover, make sure that the combined traffic for both units is within the capacity of each unit.
Note
You can assign both failover groups to one ASA if desired, but then you are not taking advantage of having two active ASAs.
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:
The unit on which a failover group becomes active is determined as follows:
–
You manually force a failover.
–
You configured preemption for the failover group, which causes the failover group to automatically become active on the preferred unit when the unit becomes available.
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.
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.
Table 7-3 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.
Failover units do not require the same license on each unit. If you have licenses on both units, they combine into a single running failover cluster license. There are some exceptions to this rule. See the following table for precise licensing requirements for failover.
Additional Guidelines and Limitations
By default, the failover policy consists of the following:
Follow the steps in this section to configure the primary in an Active/Standby failover configuration. These steps provide the minimum configuration needed to enable failover on the primary unit.
Step 1
Designate this unit as the primary unit:
Step 2
Specify the interface to be used as the failover link:
This interface cannot be used for any other purpose (except, optionally, the state link).
The if_name argument assigns a name to the interface.
The interface_id argument can be a physical interface, subinterface, redundant interface, or EtherChannel interface ID. On the ASASM, the interface_id specifies a VLAN ID.
Step 3
Assign the active and standby IP addresses to the failover link:
This address should be on an unused subnet.
The standby IP address must be in the same subnet as the active IP address.
Step 4
Enable the failover link:
Step 5
(Optional) Specify the interface you want to use as the state link:
We recommend specifying a separate interface from the failover link or data interfaces.
The if_name argument assigns a name to the interface.
The interface_id argument can be a physical interface, subinterface, redundant interface, or EtherChannel interface ID. On the ASASM, the interface_id specifies a VLAN ID.
Step 6
If you specified a separate state link, assign the active and standby IP addresses to the state link:
This address should be on an unused subnet, different from the failover link.
The standby IP address must be in the same subnet as the active IP address.
Skip this step if you are sharing the state link.
Step 7
If you specified a separate state link, enables the state link.
Skip this step if you are sharing the state link.
Step 8
(Optional) Do one of the following to encrypt communications on the failover and state links:
The key can be up to 128 characters in length. Identify the same key on both units. The key is used by IKEv2 to establish the tunnels.
If you use a master passphrase (see Configure the Master Passphrase), then the key is encrypted in the configuration. If you are copying from the configuration (for example, from more system:running-config output), specify that the key is encrypted by using the 8 keyword. 0 is used by default, specifying an unencrypted password.
The failover ipsec pre-shared-key shows as ***** in show running-config output; this obscured key is not copyable.
If you do not configure failover and state link encryption, failover communication, including any passwords or keys in the configuration that are sent during command replication, will be in clear text.
You cannot use both IPsec encryption and the legacy failover key encryption. If you configure both methods, IPsec is used. However, if you use the master passphrase (see Configure the Master Passphrase), you must first remove the failover key using the no failover key command before you configure IPsec encryption.
Failover LAN-to-LAN tunnels do not count against the IPsec (Other VPN) license.
Use a shared_secret from 1 to 63 characters or a 32-character hex key. For the shared_secret, you can use any combination of numbers, letters, or punctuation. The shared secret or hex key is used to generate the encryption key. Identify the same key on both units.
If you use a master passphrase (see Configure the Master Passphrase), then the shared secret or hex key is encrypted in the configuration. If you are copying from the configuration (for example, from more system:running-config output), specify that the shared secret or hex key is encrypted by using the 8 keyword. 0 is used by default, specifying an unencrypted password.
The failover key shared secret shows as ***** in show running-config output; this obscured key is not copyable.
If you do not configure failover and state link encryption, failover communication, including any passwords or keys in the configuration that are sent during command replication, will be in clear text.
Step 10
Save the system configuration to flash memory:
The following example configures the failover parameters for the primary unit:
The only configuration required on the secondary unit is for the failover link. The secondary unit requires these commands to communicate initially with the primary unit. After the primary unit sends its configuration to the secondary unit, the only permanent difference between the two configurations is the failover lan unit command, which identifies each unit as primary or secondary.
Step 1
Re-enter the exact same commands as on the primary unit except for the failover lan unit primary command. You can optionally replace it with the failover lan unit secondary command, but it is not necessary because secondary is the default setting. See Configure the Primary Unit for Active/Standby Failover.
ciscoasa(config)# interface gigabitethernet 0/3
ciscoasa(config)# failover link statelink gigabitethernet0/4
ciscoasa(config)# interface gigabitethernet 0/4
Step 2
After the failover configuration syncs, save the configuration to flash memory:
Follow the steps in this section to configure the primary unit in an Active/Active failover configuration. These steps provide the minimum configuration needed to enable failover on the primary unit.
Step 1
Designate this unit as the primary unit:
Step 2
Specify the interface to be used as the failover link:
This interface cannot be used for any other purpose (except, optionally, the state link).
The if_name argument assigns a name to the interface.
The interface_id argument can be a physical interface, subinterface, redundant interface, or EtherChannel interface ID. On the ASASM, the interface_id specifies a VLAN ID.
Step 3
Assign the active and standby IP addresses to the failover link:
This address should be on an unused subnet.
The standby IP address must be in the same subnet as the active IP address.
Step 4
Enable the failover link:
Step 5
(Optional) Specify the interface you want to use as the state link:
We recommend specifying a separate interface from the failover link or data interfaces.
The if_name argument assigns a name to the interface.
The interface_id argument can be a physical interface, subinterface, redundant interface, or EtherChannel interface ID. On the ASASM, the interface_id specifies a VLAN ID.
Step 6
If you specified a separate state link, assign the active and standby IP addresses to the state link:
This address should be on an unused subnet, different from the failover link.
The standby IP address must be in the same subnet as the active IP address.
Skip this step if you are sharing the state link.
Step 7
If you specified a separate state link, enable the state link:
Skip this step if you are sharing the state link.
Step 8
(Optional) Do one of the following to encrypt communications on the failover and state links:
The key can be up to 128 characters in length. Identify the same key on both units. The key is used by IKEv2 to establish the tunnels.
If you use a master passphrase (see Configure the Master Passphrase), then the key is encrypted in the configuration. If you are copying from the configuration (for example, from more system:running-config output), specify that the key is encrypted by using the 8 keyword. 0 is used by default, specifying an unencrypted password.
The failover ipsec pre-shared-key shows as ***** in show running-config output; this obscured key is not copyable.
If you do not configure failover and state link encryption, failover communication, including any passwords or keys in the configuration that are sent during command replication, will be in clear text.
You cannot use both IPsec encryption and the legacy failover key encryption. If you configure both methods, IPsec is used. However, if you use the master passphrase (see Configure the Master Passphrase), you must first remove the failover key using the no failover key command before you configure IPsec encryption.
Failover LAN-to-LAN tunnels do not count against the IPsec (Other VPN) license.
Use a shared_secret, from 1 to 63 characters, or a 32-character hex key.
For the shared_secret, you can use any combination of numbers, letters, or punctuation. The shared secret or hex key is used to generate the encryption key. Identify the same key on both units.
If you use a master passphrase (see Configure the Master Passphrase), then the shared secret or hex key is encrypted in the configuration. If you are copying from the configuration (for example, from more system:running-config output), specify that the shared secret or hex key is encrypted by using the 8 keyword. 0 is used by default, specifying an unencrypted password.
The failover key shared secret shows as ***** in show running-config output; this obscured key is not copyable.
If you do not configure failover and state link encryption, failover communication, including any passwords or keys in the configuration that are sent during command replication, will be in clear text.
Step 9
Create failover group 1:
By default, this group is assigned to the primary unit. Typically, you assign group 1 to the primary unit, and group 2 to the secondary unit. If you want a non-standard configuration, you can specify different unit preferences if desired using the primary or secondary subcommands.
Step 10
Create failover group 2 and assigns it to the secondary unit:
Step 11
Enter the context configuration mode for a given context, and assign the context to a failover group:
Repeat this command for each context.
Any unassigned contexts are automatically assigned to failover group 1. The admin context is always a member of failover group 1; you cannot assign it to group 2.
Step 13
Save the system configuration to flash memory:
The following example configures the failover parameters for the primary unit:
The only configuration required on the secondary unit is for the failover link. The secondary unit requires these commands to communicate initially with the primary unit. After the primary unit sends its configuration to the secondary unit, the only permanent difference between the two configurations is the failover lan unit command, which identifies each unit as primary or secondary.
Step 1
Re-enter the exact same commands as on the primary unit except for the failover lan unit primary command. You can optionally replace it with the failover lan unit secondary command, but it is not necessary because secondary is the default setting. You also do not need to enter the failover group and join-failover-group commands, as they are replicated from the primary unit. See Configure the Primary Unit for Active/Active Failover.
ciscoasa(config)# interface gigabitethernet 0/3
ciscoasa(config)# failover link statelink gigabitethernet0/4
ciscoasa(config)# interface gigabitethernet 0/4
Step 2
After the failover configuration syncs from the primary unit, save the configuration to flash memory:
Step 3
If necessary, force failover group 2 to be active on the secondary unit:
You can customize failover settings as desired.
See Defaults for Failover for the default settings for many parameters that you can change in this section. For Active/Active mode, you set most criteria per failover group.
Configure these settings in the system execution space in multiple context mode.
Step 1
Change the unit poll and hold times:
In Active/Active mode, you set this rate for the system; you cannot set this rate per failover group.
You cannot enter a holdtime value that is less than 3 times the unit poll time. With a faster poll time, the ASA can detect failure and trigger failover faster. However, faster detection can cause unnecessary switchovers when the network is temporarily congested.
If a unit does not hear hello packet on the failover communication interface for one polling period, additional testing occurs through the remaining interfaces. If there is still no response from the peer unit during the hold time, the unit is considered failed and, if the failed unit is the active unit, the standby unit takes over as the active unit.
Step 2
Set the HTTP replication rate in connections per second:
Set the rate between 8341 and 50000. The default is 50000. In Active/Active mode, you set this rate for the system; you cannot set this rate per failover group.
Step 3
Disable the ability to make any configuration changes directly on the standby unit or context:
By default, configurations on the standby unit/context are allowed with a warning message.
Step 4
(Active/Active mode only) Specify the failover group you want to customize:
Step 5
(Active/Active mode only) Configure failover group preemption for failover group 1:
If one unit boots before the other, then both failover groups become active on that unit, despite the primary or secondary setting. This command causes the failover group to become active on the designated unit automatically when that unit becomes available.
You can enter an optional delay value, which specifies the number of seconds the failover group remains active on the current unit before automatically becoming active on the designated unit. Valid values are from 1 to 1200.
If Stateful Failover is enabled, the preemption is delayed until the connections are replicated from the unit on which the failover group is currently active.
Step 6
Enable HTTP state replication:
To allow HTTP connections to be included in the state information replication, you need to enable HTTP replication. Because HTTP connections are typically short-lived, and because HTTP clients typically retry failed connection attempts, HTTP connections are not automatically included in the replicated state information.
Step 7
Set the threshold for failover when interfaces fail:
By default, one interface failure causes failover.
When specifying a specific number of interfaces, the num argument can be from 1 to 250.
When specifying a percentage of interfaces, the num argument can be from 1 to 100.
Step 8
Change the interface poll and hold times:
Valid values for poll time are from 1 to 15 seconds or, if the optional msec keyword is used, from 500 to 999 milliseconds. The hold time determines how long it takes from the time a hello packet is missed to when the interface is marked as failed. Valid values for the hold time are from 5 to 75 seconds. You cannot enter a hold time that is less than 5 times the poll time.
If the interface link is down, interface testing is not conducted and the standby unit could become active in just one interface polling period if the number of failed interfaces meets or exceeds the configured failover criteria.
Step 9
Configure the virtual MAC address for an interface:
The phy_if argument is the physical name of the interface, such as gigabitethernet0/1.
The active_mac and standby_mac arguments are MAC addresses in H.H.H format, where H is a 16-bit hexadecimal digit. For example, the MAC address 00-0C-F1-42-4C-DE would be entered as 000C.F142.4CDE.
The active_mac address is associated with the active IP address for the interface, and the standby_mac is associated with the standby IP address for the interface.
You can also set the MAC address using other commands or methods, but we recommend using only one method. If you set the MAC address using multiple methods, the MAC address used depends on many variables, and might not be predictable.
Use the show interface command to display the MAC address used by an interface.
Step 10
(Active/Active mode only) Repeat this procedure for the other failover group, if desired.
By default, monitoring is enabled on all physical interfaces, or for the ASASM, all VLAN interfaces, and on any hardware modules installed on the ASA. You might want to exclude interfaces attached to less critical networks from affecting your failover policy.
Step 1
Enable or disable health monitoring for an interface:
If you do not want a hardware module failure, such as the ASA FirePOWER module, to trigger failover, you can disable module monitoring using the no monitor-interface service-module command.
When running in Active/Active failover, a unit may receive a return packet for a connection that originated through its peer unit. Because the ASA that receives the packet does not have any connection information for the packet, the packet is dropped. This drop most commonly occurs when the two ASAs in an Active/Active failover pair are connected to different service providers and the outbound connection does not use a NAT address.
You can prevent the return packets from being dropped by allowing asymmetrically routed packets. To do so, you assign the similar interfaces on each ASA to the same ASR group. For example, both ASAs connect to the inside network on the inside interface, but connect to separate ISPs on the outside interface. On the primary unit, assign the active context outside interface to ASR group 1; on the secondary unit, assign the active context outside interface to the same ASR group 1. When the primary unit outside interface receives a packet for which it has no session information, it checks the session information for the other interfaces in standby contexts that are in the same group; in this case, ASR group 1. If it does not find a match, the packet is dropped. If it finds a match, then one of the following actions occurs:
Note
This feature does not provide asymmetric routing; it restores asymmetrically routed packets to the correct interface.
Figure 7-13 shows an example of an asymmetrically routed packet.
1.
An outbound session passes through the ASA with the active SecAppA context. It exits interface outsideISP-A (192.168.1.1).
2.
Because of asymmetric routing configured somewhere upstream, the return traffic comes back through the interface outsideISP-B (192.168.2.2) on the ASA with the active SecAppB context.
3.
Normally the return traffic would be dropped because there is no session information for the traffic on interface 192.168.2.2. However, the interface is configured as part of ASR group 1. The unit looks for the session on any other interface configured with the same ASR group ID.
4.
The session information is found on interface outsideISP-A (192.168.1.2), which is in the standby state on the unit with SecAppB. Stateful Failover replicated the session information from SecAppA to SecAppB.
5.
Instead of being dropped, the layer 2 header is rewritten with information for interface 192.168.1.1 and the traffic is redirected out of the interface 192.168.1.2, where it can then return through the interface on the unit from which it originated (192.168.1.1 on SecAppA). This forwarding continues as needed until the session ends.
Step 1
On the primary unit, specify the interface for which you want to allow asymmetrically routed packets:
Step 2
Set the ASR group number for the interface:
Valid values for num range from 1 to 32.
Step 3
On the secondary unit, specify the similar interface for which you want to allow asymmetrically routed packets:
Step 4
Set the ASR group number for the interface to match the primary unit interface:
The two units have the following configuration (configurations show only the relevant commands). The device labeled SecAppA in the diagram is the primary unit in the failover pair.
Example 7-1 Primary Unit System Configuration
Example 7-2 SecAppA Context Configuration
Example 7-3 SecAppB Context Configuration
This section describes how to manage failover units after you enable failover, including how to change the failover setup and how to force failover from one unit to another.
To force the standby unit to become active, perform the following procedure.
In multiple context mode, perform this procedure in the System execution space.
Step 1
Force a failover when entered on the standby unit. The standby unit becomes the active unit.
If you specify the group group_id, then this command forces a failover when entered on the standby unit for the specified Active/Active failover group. The standby unit becomes the active unit for the failover group.
Step 2
Force a failover when entered on the active unit. The active unit becomes the standby unit.
If you specify the group group_id, then this command forces a failover when entered on the active unit for the specified failover group. The active unit becomes the standby unit for the failover group.
Disabling failover on one or both units causes the active and standby state of each unit to be maintained until you reload. For an Active/Active failover pair, the failover groups remain in the active state on whichever unit they are active, no matter which unit they are configured to prefer.
See the following characteristics when you disable failover:
In multiple context mode, perform this procedure in the system execution space.
Step 2
To completely disable failover, save the configuration and reload:
To restore a failed unit to an unfailed state, perform the following procedure.
In multiple context mode, perform this procedure in the System execution space.
Step 1
Restore a failed unit to an unfailed state:
Restoring a failed unit to an unfailed state does not automatically make it active; restored units remain in the standby state until made active by failover (forced or natural). An exception is a failover group (Active/Active mode only) configured with failover preemption. If previously active, a failover group becomes active if it is configured with preemption and if the unit on which it failed is the preferred unit.
If you specify the group group_id, this command restores a failed Active/Active failover group to an unfailed state.
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 test failover functionality, perform the following procedure.
Step 1
Test that your active unit is passing traffic as expected by using FTP (for example) to send a file between hosts on different interfaces.
Step 2
Force a failover by entering the following command on the active unit:
Step 3
Use FTP to send another file between the same two hosts.
Step 4
If the test was not successful, enter the show failover command to check the failover status.
Step 5
When you are finished, you can restore the unit to active status by enter the following command on the newly active unit:
Note
When an ASA interface goes down, for failover it is still considered to be a unit issue. If the ASA detects that an interface is down, failover occurs immediately, without waiting for the interface holdtime. The interface holdtime is only useful when the ASA considers its status to be OK, although it is not receiving hello packets from the peer. To simulate interface holdtime, shut down the VLAN on the switch to prevent peers from receiving hello packets from each other.
Remote command execution lets you send commands entered at the command line to a specific failover peer.
Because configuration commands are replicated from the active unit or context to the standby unit or context, you can use the failover exec command to enter configuration commands on the correct unit, no matter which unit you are logged in to. For example, if you are logged in to the standby unit, you can use the failover exec active command to send configuration changes to the active unit. Those changes are then replicated to the standby unit. Do not use the failover exec command to send configuration commands to the standby unit or context; those configuration changes are not replicated to the active unit and the two configurations will no longer be synchronized.
Output from configuration, exec, and show commands is displayed in the current terminal session, so you can use the failover exec command to issue show commands on a peer unit and view the results in the current terminal.
You must have sufficient privileges to execute a command on the local unit to execute the command on the peer unit.
Step 1
If you are in multiple context mode, use the changeto context name command to change to the context you want to configure. You cannot change contexts on the failover peer with the failover exec command.
Step 2
Use the following command to send commands to he specified failover unit:
Use the active or standby keyword to cause the command to be executed on the specified unit, even if that unit is the current unit. Use the mate keyword to cause the command to be executed on the failover peer.
Commands that cause a command mode change do not change the prompt for the current session. You must use the show failover exec command to display the command mode the command is executed in. See Change Command Modes for more information.
The failover exec command maintains a command mode state that is separate from the command mode of your terminal session. By default, the failover exec command mode starts in global configuration mode for the specified device. You can change that command mode by sending the appropriate command (such as the interface command) using the failover exec command. The session prompt does not change when you change modes using failover exec.
For example, if you are logged in to global configuration mode of the active unit of a failover pair, and you use the failover exec active command to change to interface configuration mode, the terminal prompt remains in global configuration mode, but commands entered using failover exec are entered in interface configuration mode.
The following examples show the difference between the terminal session mode and the failover exec command mode. In the example, the administrator changes the failover exec mode on the active unit to interface configuration mode for the interface GigabitEthernet0/1. After that, all commands entered using failover exec active are sent to interface configuration mode for interface GigabitEthernet0/1. The administrator then uses failover exec active to assign an IP address to that interface. Although the prompt indicates global configuration mode, the failover exec active mode is in interface configuration mode.
Changing commands modes for your current session to the device does not affect the command mode used by the failover exec command. For example, if you are in interface configuration mode on the active unit, and you have not changed the failover exec command mode, the following command would be executed in global configuration mode. The result would be that your session to the device remains in interface configuration mode, while commands entered using failover exec active are sent to router configuration mode for the specified routing process.
Use the show failover exec command to display the command mode on the specified device in which commands sent with the failover exec command are executed. The show failover exec command takes the same keywords as the failover exec command: active, mate, or standby. The failover exec mode for each device is tracked separately.
For example, the following is sample output from the show failover exec command entered on the standby unit:
The failover exec command uses the failover link to send commands to and receive the output of the command execution from the peer unit. You should enable encryption on the failover link to prevent eavesdropping or man-in-the-middle attacks.
When you use remote commands you face the following limitations:
The ASA issues a number of syslog messages related to failover at priority level 2, which indicates a critical condition. To view these messages, see the syslog messages guide. To enable logging, see Chapter39, “Logging”
Note
During a fail over, failover logically shuts down and then bring up interfaces, generating syslog messages 411001 and 411002. This is normal activity.
To see debug messages, enter the debug fover command. See the command reference for more information.
Note
Because debugging output is assigned high priority in the CPU process, it can drastically affect system performance. For this reason, use the debug fover commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco TAC.
To receive SNMP syslog traps for failover, configure the SNMP agent to send SNMP traps to SNMP management stations, define a syslog host, and compile the Cisco syslog MIB into your SNMP management station. See Chapter 40, “SNMP” for more information.
To monitor failover status, enter one of the following commands:
Displays information about the failover state of the unit.
Displays information about the failover state of the failover group. The information displayed is similar to that of the show failover command but limited to the specified group.
Displays information about the monitored interface.
Displays the failover commands in the running configuration.