Failover
In active-passive HA, failover occurs when the primary device becomes unavailable and the auxiliary device starts processing all the traffic.
In active-active HA, failover occurs when either of the devices becomes unavailable. The peer device then starts processing all the traffic.
When the auxiliary device becomes the primary device after failover, its web admin console shows the primary device configuration.
Triggers for failover
-
Triggers
- Missing heartbeat between the HA devices
- A monitored port is unavailable
- A device is unavailable
Missing Heartbeat
HA devices send heartbeat packets to each other over the dedicated HA link to communicate that they're available. These are Virtual Router Redundancy Protocol (VRRP) requests. By default, they send a heartbeat packet every 250 milliseconds. If a device doesn't receive 16 (default) consecutive packets, it considers the peer unavailable.
When an active device becomes unavailable, failover occurs. When either device (active or passive) becomes unavailable, the peer becomes a standalone device.
Monitored port
You can select physical interfaces to monitor when you configure HA. You can select more than one interface to monitor.
If even a single monitored port becomes unavailable, the device considers itself unavailable, and failover occurs.
Device is unavailable
An HA device can become unavailable for the following reasons:
- Power loss
- Hardware failure
- Software failure
Session failover
When failover occurs, current sessions fail over to the peer device for some services and traffic types.
| Traffic | Session failover |
|---|---|
| Forwarded TCP traffic, including NAT | |
| UDP, ICMP, broadcast, and multicast | |
| VLAN | |
| VPN | VPN tunnels: Route-based, policy-based, and remote access IPsec sessions are restored with seamless connection failover. Traffic over IPsec VPN: In IPsec tunnels, HA session failover supports stateless protocols, such as UDP and ICMP, but doesn't support stateful protocols, such as TCP. |
| Web requests (HTTP and HTTPS) | Current web requests are dropped. The browser automatically retries the request. The current primary processes the request. |
Failing back to primary device
When the device that's the Initial primary fails over to the auxiliary device and then becomes available again, it takes one of the following roles:
- It remains the auxiliary.
- It automatically becomes the primary again if you select Preferred primary device in its HA configuration.
If you select Preferred primary device in the primary device, the cluster behaves as follows:
- After the initial primary device becomes available, all its services start and synchronize themselves with the peer device that's functioning as a standalone device.
- The standalone device restarts.
- The initial primary becomes the current primary device again.
- The peer device becomes the auxiliary device.
Note
We recommend that you select the Preferred primary device setting. It helps you easily identify the device carrying the licenses in active-passive HA.
Here's an example.
