FortiGate Active-Passive HA Cluster: CLI Setup Guide

A single FortiGate is a single point of failure for your whole branch or edge - when it reboots for a firmware upgrade or dies on a hot afternoon, the Internet vanishes with it. FortiGate's FGCP (FortiGate Clustering Protocol) lets two units run as an active-passive HA cluster: one unit carries traffic while the standby synchronizes configuration and session state over dedicated heartbeat interfaces, taking over automatically on failure. This guide shows the full CLI configuration for a two-unit A-P cluster based on the official Fortinet administration guide.

What You Need Before Starting

Both FortiGates must run the same firmware and model family. Physically connect two dedicated heartbeat links (typically ha1 and ha2), and do not plug heartbeat ports into a switch running STP that could delay failover detection. All HA settings except device priority must be identical on both units.

Primary Unit Configuration

On the primary, set a higher priority and enable override so it reclaims the active role after recovery:

config system global
    set hostname FGT-Primary
end
config system ha
    set mode a-p
    set group-id 100
    set group-name My-cluster
    set password <ha-password>
    set priority 200
    set override enable
    set hbdev ha1 200 ha2 100
    set session-pickup enable
    set monitor "port1" "port2"
end

hbdev lists the heartbeat interfaces with their priority; a higher number means that heartbeat link is preferred. session-pickup enable synchronizes the session table so established connections survive failover.

Secondary Unit Configuration

On the standby unit use the same commands but with a lower priority (and override disabled or left default):

config system global
    set hostname FGT-Secondary
end
config system ha
    set mode a-p
    set group-id 100
    set group-name My-cluster
    set password <ha-password>
    set priority 128
    set hbdev ha1 200 ha2 100
    set session-pickup enable
end

Verifying the Cluster

get system ha status
diagnose sys ha status
get system ha statistics

In get system ha status check that one unit shows HA active, the other HA standby, configuration and sessions are synchronized, and both heartbeat links are up. The cluster answers on virtual MACs, so downstream switches and upstream routers see no ARP change during failover.

How FGCP Failover Actually Works

FGCP (FortiGate Clustering Protocol) is Fortinet's proprietary clustering protocol. When both units boot, they send hello packets out of the heartbeat interfaces, form a cluster, and elect one unit as active. The election is decided by the override setting first and device priority second: a unit with override enabled and a higher priority will always fight to take the active role, while without override the cluster keeps whoever came up first. Once the election settles, the two units synchronise over the heartbeat link: the full configuration, the routing table, DHCP state, IPsec and SSL VPN state, and the connection and session table.

Two mechanisms make failover invisible to the rest of the network:

• Virtual MAC addresses. The cluster presents a virtual MAC derived from the group ID on every monitored interface. Downstream switches never see a MAC move, so they do not flush their CAM tables and do not need to re-learn anything.
• Gratuitous ARP (GARP). On takeover the new active unit advertises GARP for every cluster IP address, so upstream routers refresh their ARP caches immediately instead of waiting for the old entry to time out.

The practical consequence is that a healthy failover should be measured in tens of milliseconds for session pickup and milliseconds for GARP-based reconvergence. If users complain about thirty-second timeouts after a failover, the fault is almost never the election itself — look at the heartbeat network, the monitored interface list, or session synchronisation instead.

Heartbeat Interface Design and Cabling

The heartbeat link is the single most important cable in the cluster. Use two of them. Fortinet's guidance is to connect the heartbeat interfaces directly between the two units, or through a dedicated Layer 2 segment that carries nothing else. If you must cross a switch, make sure it is not running RSTP/STP on those ports (use edge or BPDU-filter configuration) — a spanning tree state change can delay hello delivery long enough to trigger a false failover.

The hbdev setting takes interface names together with a priority, and the priority decides which link is preferred and which is the backup:

config system ha
    set hbdev ha1 200 ha2 100
end

With this configuration ha1 carries heartbeats and ha2 stands by. If ha1 fails, the cluster continues over ha2 instead of splitting. For SFP-based units, make sure the heartbeat interfaces are the same media type and speed on both members; a 1G/10G mismatch on ha1 is a classic cause of one-way hello loss.

Many engineers also dedicate a management interface per unit and enable HA management so that each FortiGate keeps its own out-of-band address even while clustering:

config system ha
    set ha-mgmt-status enable
    config ha-mgmt-interfaces
        edit 1
            set interface "mgmt"
            set gateway 192.0.2.1
        next
    end
end

That way you can SSH to the standby unit directly for diagnosis instead of jumping through the active one.

Priority, Override and Which Unit Becomes Active

Priority is a numeric value from 0 to 255, and the higher value wins. Two rules matter in practice:

• Without override, the unit that becomes active first stays active even if the other unit has a higher priority. This is the safer default when the two units sit in different sites or have different upstream paths.
• With override enabled on one unit only, that unit will take back the active role after it recovers. Useful when the "primary" unit has better uplinks; dangerous if it also has a habit of flapping, because every flap becomes a real failover.

The recommended pattern is: enable override on the preferred unit with a high priority (200 in our example), and leave override disabled on the standby with a lower priority (128). Remember that the priority is compared only when override is in play, so a mismatched pair of settings is the usual explanation for "the wrong unit is active".

You can force the issue from the CLI without changing configuration on the standby:

execute ha failover set 1
execute ha failover unset 1

Always test failover this way before you trust the cluster in production, and confirm the active role moved by checking the status output (covered below).

Link Monitoring: What set monitor Really Does

set monitor tells the cluster which interfaces to watch. Each monitored interface gets a virtual MAC and is counted towards failover decisions. If all monitored interfaces on the active unit go down, the standby takes over — this is what lets the cluster survive an upstream link failure, not just a dead appliance.

config system ha
    set monitor "port1" "port2" "wan1"
end

Two things are easy to get wrong here. First, never monitor the heartbeat interfaces themselves. Second, monitor the interfaces that actually carry traffic in both directions: monitoring only a LAN port means the cluster will not react when the WAN link dies. On the flip side, monitoring a port that legitimately flaps (a lab switch, an unused DMZ port) will cause unnecessary failovers. Pair the monitored set with the link failure threshold so a single down member does not immediately trigger a takeover:

config system ha
    set link-failure-threshold 50
end

A threshold of 50 means the cluster fails over only when at least half of the monitored interfaces are down. Tune it to the number of monitored ports you have.

Session Pickup, Session Pickup Delay and Connectionless Traffic

set session-pickup enable synchronises the session table so that established TCP flows survive the failover. What it does not do by default is pick up connectionless traffic:

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
    set session-pickup-expectation enable
    set session-pickup-nat enable
    set session-pickup-delay enable
end

session-pickup-connectionless covers ICMP and UDP sessions, session-pickup-expectation covers sessions created by expectation (FTP data channels, SIP media and other ALG-driven flows), and session-pickup-nat handles NATed sessions. session-pickup-delay is the interesting one: with a delay enabled, the cluster only starts picking up sessions after the link has been up for a configurable period, which avoids the brief flood of half-open sessions that can occur right after a failover on busy links.

Session pickup has a cost: the active unit streams session updates to the standby over the heartbeat link, which consumes bandwidth and CPU. On a very large session table you may prefer a dedicated session sync interface rather than sharing the heartbeat:

config system ha
    set session-sync-dev "ha2"
end

Finally, remember that asymmetric routing breaks session pickup. If return traffic can reach the standing unit while forward traffic goes through the active unit, sessions will look broken even though the cluster itself is healthy.

Failover Timers and Thresholds

FGCP timers decide how quickly the cluster reacts and how long it takes to declare a member dead. The safest approach is to leave the defaults alone unless you have measured a specific problem, then change one value at a time:

config system ha
    set hb-interval 2
    set hb-lost-threshold 6
    set hello-holddown 20
    set route-ttl 10
    set route-wait 0
    set arps 5
    set arp-interval 5
    set gratuitous-arps enable
end

Read them as follows: hb-interval is how often heartbeats are sent, hb-lost-threshold how many consecutive misses are tolerated before a member is considered lost, and hello-holddown how long a newly joined member waits before it can become active. Lower values mean faster failover but more sensitivity to transient loss. If your heartbeat crosses a switch or a microwave/4G link, raising the lost threshold is usually better than shortening the interval.

Do not guess at the exact option names available on your build — the HA configuration tree has grown over releases. Print the available options directly on the unit:

config system ha
    set ?
end
show full-configuration system ha

show full-configuration system ha is the definitive answer to "what is actually set on this box", including defaults you never typed.

Upgrading FortiOS on an HA Cluster

Firmware upgrades are the most common reason a healthy cluster breaks. Both members must run the same FortiOS build and the same model family; a mismatched build results in a split cluster where both units claim the active role. The safe sequence for an active-passive pair is:

1. Back up the configuration from the active unit (System → Backup, or execute backup config tftp ...).
2. Confirm the cluster is fully synchronised and both heartbeats are up.
3. Upload the new firmware image and let the cluster handle the upgrade — with an active-passive pair, the standby reboots first, comes up, and then the active unit fails over so the newly upgraded unit takes traffic.
4. Verify status, sessions and monitored interfaces after each reboot.
5. Do not leave the cluster in this state — the upgrade completes quickly, but if it does not, both units must be on the same build.

To allow traffic to keep flowing during the upgrade, enable uninterrupted upgrade handling if your build supports it:

config system ha
    set uninterruptible-upgrade enable
end

If the upgrade is interrupted and the cluster is split ("both units active"), do not guess. Shut one unit down, let the other stabilise, then rejoin the second one and check that configuration syncs one way only.

Common HA Problems and How to Diagnose Them

Ninety percent of HA trouble falls into five buckets, and each has a CLI signature:

• Cluster does not form at all. Almost always heartbeat: wrong interface, wrong cable, or a switch in between blocking the link. Verify the heartbeat ports are up and that both units use the same group-id and group-name. diagnose sys ha status shows the per-interface hello state.
• Both units active (split brain). Configuration mismatch, password mismatch, or heartbeat loss. Compare show system ha output line by line on both units.
• Configuration out of sync. The secondary has an older configuration because someone edited it locally. Check the checksums and force a resync.
• Failover happens too often. A monitored interface is flapping, or timers are too aggressive. Check interface counters and show system ha for the failover reason.
• Sessions drop on failover even though the cluster is healthy. Session pickup is off, only partially enabled, or asymmetric routing is in play.

Useful diagnostic commands, in the order you should run them:

get system ha status
diagnose sys ha status
diagnose sys ha checksum show
get system ha statistics
diagnose sys session stat
execute ha manage 1

The last command jumps to the other member's CLI from the active unit, so you can compare settings in one session instead of two SSH windows. When a status checksum differs between members, diagnose sys ha checksum show tells you which part of the configuration is out of step.

For a live look at heartbeat traffic, FortiOS exposes HA debug applications, but treat them as a maintenance-window tool — they are noisy:

diagnose debug application hatalk -1
diagnose debug application hasync -1
diagnose debug enable
diagnose debug disable

Always finish with diagnose debug disable. A forgotten debug on a busy FortiGate is its own outage.

Rebuilding or Removing HA

If you need to return one unit to standalone operation (for example to repurpose it as a lab device), remove the cluster configuration in this order: disconnect the heartbeat cables first so the remaining unit does not immediately form a cluster with the unit you are editing, then clear HA on the unit you are removing:

config system ha
    unset mode
    unset group-id
    unset group-name
    unset hbdev
    unset monitor
end
execute reboot

After the reboot the unit comes back standalone with its own hostname and its own MAC addresses. Its interfaces are NOT administratively disabled, so review the configuration before you put it on a network where it could create a duplicate IP or a second DHCP server.

To rebuild the cluster from scratch, factory reset both units, apply the base configuration to the primary only, then configure HA on both with identical group settings. Let the primary finish synchronising to the secondary before you attach real traffic.

Post-Deployment Verification Checklist

Work through this list before you declare the cluster production-ready:

1. get system ha status shows one member active, one standby, and both heartbeat links up.
2. Configuration and session sync both report as synchronised in the same output.
3. Both units run the same firmware build (get system status).
4. Every interface in the monitor list actually carries production traffic.
5. Failover tested with execute ha failover set: no interface renegotiation, no ARP timeout on a downstream host, and long-lived sessions survive.
6. Failback tested by restoring the preferred unit and confirming it reclaims the active role (if override is enabled).
7. Firmware upgrade path tested once in a maintenance window, not during an incident.
8. Both members reachable out of band for diagnosis (ha-mgmt-status).
9. Backups of the cluster configuration stored off-box.

A FortiGate HA pair is only as good as its heartbeat network and its session sync. Test both deliberately, and the day you actually need failover will be uneventful.

Related Guides on This Site

HA pairs still need VPNs and remote access: see FortiGate site-to-site IPsec setup and FortiGate SSL VPN web mode, or compare with the Linux approach in Keepalived VRRP for HAProxy. For day-to-day CLI work on the pair, keep our FortiOS CLI troubleshooting cheat sheet open; first-hop redundancy on other platforms is covered in Cisco HSRP priority, preempt and tracking.

原文链接：https://docs.fortinet.com/document/fortigate/latest/administration-guide/23145/sd-wan-with-fgcp-ha