Failover/High Availability – Two ASAs are paired to operate together and provide redundancy in case of a device failure.
Primary Unit – Determines which of the two ASAs will be referred as the ‘Primary Unit’. Initially, all the configurations are done on the primary unit. It should not be confused with the term ‘active’. The primary unit can either be active or standby.
Secondary Unit – Determines which of the ASAs will be referred as the ‘Secondary Unit’. It should not be confused with the term ‘standby’. The secondary unit can either be active or standby.
Active – The device with the active role will handle all the security functions.
Standby – The unit with the standby role will monitor the active unit for failure and take the active role when a failure occurs.
Failover link – A dedicated link between the two ASAs to propagate communication regarding the failover state, configuration/commands synchronization. Although you can use the already existing data interfaces for the failover related communication, it is not recommended.
Stateful Failover link – A dedicated link between the two ASAs to propagate communication regarding the active TCP/UDP sessions so that they can be replicated on to the standby unit for a stateful failover. Always a separate interface must be used because of the large number of connections that are established/turned down, as the same information is cascaded to the standby ASA in realtime.
Types of failover:
- Active/Standby Failover – One ASA take the active role and handles all the normal security functions. The other ASA stays in standby mode and is ready to take over the active role in the event of a failure. This type of failover provides device redundancy.
- Active/Active Failover – This can be achieved only when using ASAs in multiple context mode. The contexts can be organized into groups and each ASA is active for one group and standby for the other group. This type of failover provides device redundancy as well as load balancing across contexts.
Stateless failover – The TCP/UDP connections are NOT replicated on the standby unit, this causes the active connections to drop when a failover occurs. Both the above failover types support stateless failover.
Stateful failover – The TCP/UDP connections are replicated on the standby unit, so at the time of failover the standby unit has the TCP/UDP state information and the connections are not dropped. Both the above failover types support stateful failover.
State information replicated in Stateful failover- NAT, ARP, MAC, TCP/UDP connections, H.323 and SIP, MGCP and HTTP (if explicitly enabled).
State information not replicated in Stateful failover- Dynamic routing table entries, uauth cut-through proxy, DHCP leases, Phone proxy and SSM Activity.
- Both the units must be of the same model.
- Both the units should have Identical sets of interfaces.
- Both the units must have the same software configuration and proper license.
- Both the units must have the same SSM modules, if any.
- Both the units must be in the same mode (transparent/routed, single/multiple context)
The Election Procedure:
- While booting, if both ASAs are equally healthy, primary > active and secondary > standby.
- While booting, if one is healthier than the other, the healthier one takes the active role.
- While booting, if the active role is already assigned, the other ASA takes the standby role.
- While booting, if no peer is detected, the booting ASA will become active.
Monitored Interfaces – By default, every ASA interface will be monitored to detect a failure that might trigger a failover. Interfaces can be excluded from monitoring if required.
Monitoring peer’s health:
- If hellos are received over the LAN failover interface, the peer is alive and no failover occurs.
- If hellos are not received over the LAN failover interface but are received on other monitored interfaces, the peer is alive and no failover occurs. However, the LAN failover interface is declared as “failed” and should be replaced ASAP.
- If no hellos are received over any interface, the peer is declared to be “failed” and failover occurs.
Hello packets – Over the LAN failover interface > 1 second
Over other monitored interface > 5 seconds
Hold timer – Over the LAN failover interface > 15 seconds
Over other monitored interface > 5 times the hello timer (25 seconds)
The Interface testing mode – If hello packets are not seen on a monitored interface within ‘half’ of the hold time (25 seconds), that interface is moved into the ‘testing’ mode to determine if a failure has occurred.
- Interface Status – If the link is ‘down’, the interface is failed.
- Network activity – If no packets are received for 5 seconds, the next testing phase begins. If packets are received, the interface can still be used.
- ARP – The interface stimulates received traffic by sending ARP requests . If no traffic is received in 5 seconds, the next testing phase begins.
- Broadcast ping – Traffic is stimulated by sending an ICMP echo request to the broadcast address on the interface. If no replies are received in 5 seconds, the interface is marked as “failed”.