« Building Lab 1 | Main

HA Features on ASA - Part 3 Reference

Cisco ASA Series CLI Configuration Guide, 9.0
Information about Failover

Practice is great and learning as much as you can is good, but it's always best to look directly at things that have a great big red arrow pointing at them. This link points at a chapter of the documentation - found on the Cisco Learning Network Study Material list. That list is long and some of the links are not very helpful, but this one is very specific.

The following lists what I consider important points from the site. In the analog world, this would be what I might highlight on a hard copy. You should read the document yourself and consider your own points to ponder. I am putting them here not as a summary for you, but as "notes" that I would want to review if I wanted to refresh my memory on this document. I sometimes browse random posts during "idle" time which can help to reinforce the material. My computer is near my tv - so I can poke through a previous post during a commercial break. Since this blog is online - I can use my Kindle (or smartphone) to review a random piece while waiting in line, eating or traveling (not driving).


Configuring high availability requires two identical ASAs 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. Active/Active failover is available only on units running in multiple context mode.

When the ASA 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.

The two units in a failover configuration must be the same model, have the same number and types of interfaces, the same SSMs installed (if any), and the same RAM installed. 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.

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

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 ASA is used to terminate VPN tunnels, this information includes any usernames, passwords and preshared keys used for establishing the tunnels. **Important**

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.

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.

To make the ASA failover pair resistant to failover interface failure, we recommend that failover interfaces NOT use the same switch as the data interfaces.

Note: there are several other acceptable and recommended configurations with 4, 6 and 8 switches. The most reliable failover configurations use a redundant interface on the failover interface.

In an Active/Active failover configuration, both ASAs can pass network traffic. In Active/Active failover, you divide the security contexts on the ASA into failover groups . A failover group is simply a logical group of one or more security contexts. Each group is assigned to be active on a specific ASA in the failover pair. When a failover occurs, it occurs at the failover group level. VPN is not supported in multiple context mode or Active/Active failover.

When a stateless failover occurs, all active connections are dropped. Clients need to reestablish connections when the new active unit takes over. 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. 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.

Stateful Failover participates in dynamic routing protocols, like OSPF and EIGRP, so routes that are learned through dynamic routing protocols on the active unit are maintained in a Routing Information Base (RIB) table on the standby unit.

The following state information is passed to the standby ASA when Stateful Failover is enabled:
- NAT translation table
- TCP connection states
- UDP connection states
- The ARP table
- The Layer 2 bridge table (when running in transparent firewall mode)
- The HTTP connection states (if HTTP replication is enabled)
- The ISAKMP and IPsec SA table
- GTP PDP connection database
- SIP signalling sessions
- ICMP connection state. ICMP connection replication is enabled only if the respective interface is assigned to an asymmetric routing group.

The following state information is not passed to the standby ASA when Stateful Failover is enabled:
- The HTTP connection table (unless HTTP replication is enabled). **Important**
- The user authentication (uauth) table.
- Inspected protocols are subject to advanced TCP-state tracking, and the TCP state of these connections is not automatically replicated. While these connections are replicated to the standby unit, there is a best-effort attempt to re-establish a TCP state.
- DHCP server address leases.
- State information for modules.
- 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.

Intra-Chassis Failover >> If you install the secondary ASASM in the same switch as the primary ASASM, you protect against module-level failure.

Inter-Chassis 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. To accommodate the failover communications between ASASMs, we recommend that you configure a trunk port between the two switches that carries the failover and state VLANs.

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:
# Access mode - configure spanning-tree portfast on the interface.
# Trunk mode - block BPDUs on the ASA on both the inside and outside interfaces
access-list id ethertype deny bpdu
access-group id in interface inside_name
access-group id in interface outside_name
^ Disable failover interface monitoring
^ Increase failover interface holdtime to allow STP to converge before failover
^ Decrease STP timers to allow STP to converge faster than the failover interface holdtime
(the last 3 are less desirable)

You can use the Auto Update Server to deploy software images and configuration files to ASAs in an Active/Standby failover configuration. To enable Auto Update on an Active/Standby failover configuration, enter the Auto Update Server configuration on the primary unit in the failover pair. [Note: I don't see anything on "managing software and configurations" on the blueprint.]

Unit Health Monitoring
The ASA 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 ASA takes depends upon the response from the other unit. See the following possible actions:

** If the ASA receives a response on the failover interface, then it does not fail over.

** If the ASA 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 ASA does not receive a response on any interface, then the standby unit switches to active mode and classifies the other unit as failed.

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.

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.
2 - Network Activity test—A received network activity test.
3 - ARP test—A reading of the unit ARP cache for the 2 most recently acquired entries.
4 - Broadcast Ping test—A ping test that consists of sending out a broadcast ping request.

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).

Failover System Messages
The ASA issues a number of system messages related to failover at priority level 2, which indicates a critical condition. During switchover, failover logically shuts down and then brings up interfaces, generating syslog messages 411001 and 411002. This is normal activity.


And all this is just _about_ failover. To actually configure failover:

Configuring Active/Standby Failover

Configuring Active/Active Failover


Powered by
Movable Type 3.2