Collect the current state #
In global context when VDOMs are enabled:
Collect the current state
FortiOS 7.4 · Global CLI context
get system statusget system ha statusdiagnose sys ha checksum clusterRecord the firmware build, expected member count, serial numbers, current roles and configuration status. Check that the member you are connected to is the one you intended to inspect. Hostnames alone are insufficient identifiers when equipment has been replaced or renamed.
Read checksum comparisons by scope #
The checksum output separates global configuration and VDOM configuration. Compare corresponding sections across members, rather than comparing a global checksum on one unit with a VDOM checksum on another. A mismatch in one VDOM is a more useful starting point than the general statement that the cluster is out of sync.
For a narrower read-only comparison on each member, use the relevant scope:
Read checksum comparisons by scope
FortiOS 7.4 · Global CLI context
diagnose sys ha checksum show globaldiagnose sys ha checksum show rootReplace root with the actual VDOM name. Preserve the outputs from both members with their serial numbers. A table-level mismatch tells you where to compare configuration; it does not automatically identify which member contains the intended setting.
Avoid premature repair #
Do not force synchronization, recalculate checksums or trigger failover merely to make a warning disappear. First determine whether a configuration change is still in progress, whether both expected members are reachable and whether the disagreement persists. A brief transition during planned work and a stable unexplained mismatch call for different responses.
For a stable difference, identify the exact configuration section and compare the actual settings before planning remediation. Preserve backups and the intended source of truth. Repair commands belong in a separate change procedure with an impact assessment, not in an initial health-check block.
Know the boundary of this check #
Matching configuration does not demonstrate that every live session would survive a role change, or that both data paths are wired correctly. Likewise, packet capture on the wrong active virtual cluster can produce misleading silence. Use a representative forwarding test when validating a service, and the dedicated platform guide for chassis-based 6000/7000 systems.
Sources
Documentation reviewed: 8 October 2026
- community.fortinet.com — troubleshooting tip fortigate ha synchronization messages and cluster verification steps 92284
- community.fortinet.com — technical tip troubleshooting a checksum mismatch in a fortigate ha cluster 99096
- community.fortinet.com — technical tip packet capture and debug behavior in fortigate ha vcluster mode 227556