In Active/Standby Failover, One device acts as active and one as standby. Active device handles all over traffic and replicates the configuration and states to standby. By default all interfaces will be monitor to trigger the failover.
If one interface went down on active device then standby will take the active role and users will not face any network interruption because standby also have all active connection states as well as standby takes the primary IP address and primary MAC address while former primary will take the IP address and MAC address of secondary. In the case of transparent firewall mode, standby will take the management IP address of former active ASA.
If we are changing or adding configuration on active device then it will be replicate to standby but when we are changing anything on standby then it will not replicate to active device.
To configure the active/standby failover we need to configure the failover link and stateful link. Stateful link is optional.
We can use the same interface for both links or separate interfaces.
You can see the example configuration on below link
By default, the communications on the failover and stateful failover links are plain text (unencrypted). But we can encrypt this communication for enhanced security by configuring an IPsec encryption key.
The failover mechanism is stateful which means that the active ASA sends all stateful connection information state to the standby ASA. This includes TCP/UDP states, NAT translation tables, ARP table, VPN information and more. When the active ASA fails, the standby ASA will take over and users will not face any network disruption because standby has all connection information.
Note For multiple context mode, the ASA can fail over the entire unit (including all contexts) but cannot fail over individual contexts separately.
NOTE: If we are saving the configuration on active ASA then it will also be replicated to the standby ASA
NOTE: Active/standby failover does not use preemption. So former Active can’t be Active again after restoration. It will be remain in standby.
NOTE: Active/standby supported in both transparent and routed firewall mode.
Failover Link
We can use an unused data interface (physical, redundant, or EtherChannel) as the failover link; however, you cann’t 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 also for the state link).
Stateful Link
The active unit uses the stateful link to pass connection state information to the standby device. This means that the standby unit can maintain certain types of connections without impacting the user. This information helps the standby unit maintain existing connections when a failover occurs.
We can use a dedicated data interface (physical, redundant) for the stateful link. We can also use EtherChannel for stateful link, to prevent out-of-order packets. In this case, only one interface of the EtherChannel can be used. If that interface fails, then next interface of EtherChannel will be use.
Using a single link for both the failover and stateful failover links is the best way to conserve interfaces. However, you must consider a dedicated interface for the stateful link and failover link, if you have a large configuration and a high amount of traffic in network.
NOTE: Cisco recommends that the bandwidth of the stateful link should match the largest bandwidth of the data interfaces on the device.
The active ASA sends the state information of the following protocols/tables to the Standby ASA using the stateful link:
- NAT Translation Table
- TCP connection Table
- UDP Connection Table
- ARP Table
- Layer2 Bridge Table (if Transparent mode enabled)
- HTTP Connection Table (if HTTP Replication enabled)
- ISAKMP and IPSEC (SA) Table
- GTP PDP Connection table
- SIP signaling sessions
Others:
- The unit state (active or standby)
- Hello messages (keep-alives)
- Network link status
- MAC address exchange
- Configuration replication and synchronization
The following are not synchronized:
- HTTP connection Table (unless HTTP Replication Enable)
- Routing Table
- User Authentication (UAUTH) Table
- State Information for Security Service Module.
MAC Address
If the secondary unit boots without detecting the primary unit, Then secondary unit becomes the active unit and uses its own MAC addresses. Because it doesn’t know the MAC addresses of primary unit. However, when the former primary unit becomes available, The secondary (current active) unit changes its MAC addresses with former primary unit. which can cause an interruption in your network traffic. Similarly, if we swap out the primary unit with new hardware, a new MAC address is used.
We can prevent this interruption by using virtual MAC addresses guard against this interruption. Because active MAC address is 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. In single context mode, we can manually configure virtual MAC addresses
hostname (config): failover mac address Ethernet0/2 MAC_FOR_ACTIVE MAC_FOR_STANDBY
hostname (config): failover mac address Ethernet0/2 00a0.c969.87c8 00a0.c918.95d8
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 the MAC address which was changed.
NOTE: We can’t configure a virtual MAC address for the failover or Stateful Failover links. The MAC and IP addresses for those links do not change during failover.
Important (Keep in mind)
If port security is Configured on switch(es) connected to an ASA failover pair. Then it can cause communication problems when a failover event occurs. This is because if a secure MAC address configured or learned on one secure port moves to another secure port, then a violation is flagged by the switch port security feature. So we should avoid the port security on switches / routers which are connected to ASA failover pair.
ASA failover replication fails if you try to make a configuration change in two or more contexts at the same time. The workaround is to make configuration changes on each unit sequentially.
AnyConnect images must be the same on both ASAs in a failover pair. If the failover pair has mismatched images when a hitless upgrade is performed, then the WebVPN connection terminates in the final reboot step of the upgrade process, the database shows an orphaned session, and the IP pool shows that the IP address assigned to the client is “in use.”
If failover link fails at startup or failover link has been fail and then rebooted the devices then both devices will be active.
If stateful links fails and after that failover occur then user will face a connectivity blimp because active connection details only replicates through stateful link.
Failover Triggers
Failover can be trigger if active ASA:
- The unit has a hardware failure or a power failure.
- The unit has a software failure.
- Too many monitored interfaces failed.
- Manual by using command (no failover active on active unit or failover active on standby unit)
Enabling HTTP replication
By default, Active ASA does not replicate HTTP session information to standby when Stateful Failover is enabled. Because HTTP sessions are typically short-lived and because HTTP clients can typically retry failed connection attempts. Also no HTTP sessions replication increases system performance without causing serious data or connection loss. If we still want to enable the replication for HTTP sessions then we can do it by using failover replication http.
hostname (config)# failover replication http
Interface monitoring
By default ASA monitors all the interface excluding sub interfaces. we can also enable interface monitoring if we don’t want to monitor all the interfaces for trigger the failover, ASA can monitor up to 250 interfaces on a unit, it also depends on hardware.
Hello messages are exchanged during every interface poll frequency time period between the ASA failover pair. The failover interface poll time is 3 to 15 seconds. For example, if the poll time is set to 5 seconds and testing begins on an interface and 5 consecutive hellos are not heard on that interface (25 seconds). Then it will be consider as non operational.
ASA(config)# monitor-interface INSIDE
Interface health monitoring
Interface health monitoring is useful to detect and respond for interface failures more quickly.
Monitored failover interfaces can have the following status:
Unknown—Initial status. This means , status cannot be determined.
Normal—The interface is receiving traffic.
Testing—Hello messages are not heard on the interface for five poll times.
Link Down—The interface or VLAN is administratively down.
No Link—The physical link for the interface is down.
Failed—No traffic is received on the interface, yet traffic is heard on the peer interface.
we can specify a specific number of interface or a percentage of monitored interfaces that must fail before failover occurs. By default, a single interface failure causes failover.
hostname (config)# failover interface-policy 20%
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.
Poll and hold timers are used for health monitoring. ASA send the hello messages out to all health monitoring interfaces to check the health status.
Poll time is from 1 to 15 seconds or 500 to 999 milliseconds. Hold time is from 5 to 75 seconds. You cannot enter a hold time that is less than 5 times the poll time.
hostname (config)# failover polltime interface msec 500 holdtime 5
Changes the interface poll and hold times.
hostname(config)# failover polltime unit msec 200 holdtime msec 800
Changes the unit poll and hold times.
You offer some interesting points within this article, but aren’t you overlooking something contextual?