Cisco ASA Series Cli Configuration Manual page 355

Chapter 1 Information About Failover
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:
•
•
•
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.
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.
2.
3.
4.
If an interface has IPv4 and IPv6 addresses configured on it, the ASA uses the IPv4 addresses to perform
the health monitoring.
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.
Link Up/Down test—A test of the interface status. If the Link Up/Down test indicates that the
interface is operational, then the ASA 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.
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.
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.
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.
Failover Health Monitoring
Cisco ASA Series CLI Configuration Guide
1-19