Check Point ClusterXL Failover Troubleshooting Commands

ClusterXL problems are rarely caused by the firewall engine itself - they come from a critical device going into problem state, a state-sync link that is blocked, or a member stuck in READY because a software version mismatch prevents it from taking over. The diagnostics for all three are in the same handful of commands: show cluster state in Clish, cphaprob in expert mode, and the failover statistics. This guide explains how to read them and what each state actually means.

Reading the Cluster State

show cluster state
show cluster members
show cluster failover count

In expert mode the equivalent is richer:

cphaprob state
cphaprob -ia list
cphaprob -l list

The output lists each member with its unique address, assigned load, state and name, followed by Active PNOTEs and the last state change event with a reason. That reason string is the most valuable field on the screen: All other machines are dead (timeout), FULLSYNC means the local member lost contact with its peers, while a named pnote means a monitored subsystem failed.

Interpreting the Member States

• ACTIVE - everything is fine and this member is forwarding.
• ACTIVE(!) - a problem exists but the member still forwards because it is the only one capable of doing so. Treat this as a degraded cluster, not a healthy one.
• STANDBY - High Availability mode only; the member is waiting for the active to fail.
• READY - the member considers itself part of the cluster but something prevents it from taking a role. The two classic causes are an incomplete full sync, and a software version that is newer than the rest of the cluster during an upgrade.
• DOWN - at least one critical device reports problem state; the member is not forwarding.
• LOST - this member lost connectivity to the local member, typically while the peer reboots.

In Load Sharing modes every healthy member shows ACTIVE, so do not assume one of them is misconfigured just because it is not STANDBY.

Critical Devices (PNOTEs)

A critical device is a monitored component. When one reports a problem or fails to report on time, the member goes DOWN immediately. List them and check which one is unhappy:

cphaprob -ia list
cphaprob list
cphaprob show_failover

The frequent offenders are fwd (the forwarding process), Interface entries for monitored NICs, and Synchronization when the sync network is broken. If an interface pnote is active, confirm the interface is up and that its traffic is not being dropped by an upstream device.

Failover Statistics and History

show cluster failover
cphaprob -l show_failover
cphaprob -reset -c show_failover      # reset the counter
cphaprob -reset -h show_failover      # reset the history

The failover counter survives reboot and is synchronised between members, which makes it a reliable way to prove that unwanted failovers are or are not happening. Reset it after each maintenance window so the next value reflects only the current period, then check the history - it names the member that became active and why.

Common Failure Patterns

Both members ACTIVE in HA mode. The sync interface is down or the heartbeat is being filtered. Verify the dedicated sync link end to end; a cable that negotiates to a different VLAN is enough to break it.

Repeated failovers with no obvious pnote. Look for an interface that flaps. ClusterXL demotes a member whose monitored interface goes down, so an unstable upstream port produces a failover storm. A dedicated packet capture is the fastest way to prove it - see fw monitor packet capture guide.

Member stuck in READY after an upgrade. Check show cluster members for version skew and either finish the upgrade on all members or re-enable multi-version cluster support as appropriate.

Traffic survives failover but sessions drop. State synchronisation is not working. Confirm the sync interface, the sync network configuration on both members and that the firewall rule permitting sync traffic exists. If you are comparing platforms, OPNsense CARP and pfsync high availability describes the equivalent concepts in an open-source stack.

原文链接：https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_CLI_ReferenceGuide/Content/Topics-CLIG/CXLG/ClusterXL-Monitoring-Commands.htm