# ClusterXL Standby member stays down because of the Critical Device "Fullsync"

**Product**: ClusterXL  
**Version**: R81 (EOS), R81.10 (EOS), R81.20  
**OS**: Gaia  
**Last Modified**: 2025-12-18

## Symptoms

- Output of the `cphaprob state` command on the ClusterXL Standby member shows:
  - The cluster state is `Down`
  - The message `Reason for state change:  FULLSYNC PNOTE - Connection terminated by remote member`
- Output of the `cphaprob -l list` command on the ClusterXL Standby member shows:
  
  `Device Name: Fullsync`
  `Registration number: 0`
  `Timeout: none`
  `Current state: problem`
- The issue on the ClusterXL Standby member started after a reboot or after restarting the Check Point services with the `cpstop;cpstart` commands.
- Policy Installation succeeds on the ClusterXL Standby member, but fails on the ClusterXL Active member with a timeout error.
- The `/var/log/messages` file on the ClusterXL Active member contains these lines repeatedly:

`FULLSYNC: Server Starting sync on FW IPV4 instance #0`
  `FULLSYNC: Server Finished sync on FW IPV4 instance #0`
  `FULLSYNC: Policy changed during fullsync, stopping fullsync)`

- The `$FWDIR/log/cxld.elg` file on the ClusterXL Active member contains lines about the successful policy installation on the CoreXL Firewall instance 0, but the failed policy installation on the CoreXL Firewall instance 1:

`FULLSYNC: Finished full-sync for FW instance 0. LD data = XXX Kib, time for this instance = XX.XX Seconds.`
  `FULLSYNC: Starting full-sync for FW instance number 1.`
  `FULLSYNC: Failed to retrieve information form the kernel (fwfullsynctabinfo ioctl)`
  `FULLSYNC: Stopping on error 13`

## Cause

The CoreXL Firewall instances have different policy.

## Solution

This problem was fixed. The fix is included starting from:

- [Check Point Quantum R82](https://support.checkpoint.com/results/sk/sk181127)
- [Jumbo Hotfix Accumulator for R81.20](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.20/Default.htm) starting from Take 111
- [Jumbo Hotfix Accumulator for R81.10](https://sc1.checkpoint.com/documents/Jumbo_HFA/R81.10/Default.htm) starting from Take 183

If you choose not to upgrade, Check Point can supply a **Hotfix**. [Contact Check Point Support](https://www.checkpoint.com/support-services/contact-support/) to get a Hotfix for this issue.

A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.

For faster resolution and verification, please collect [CPinfo files](http://supportcontent.checkpoint.com/solutions?id=sk92739) from the Security Management Server and Security Gateways involved in the case.

**Hotfix installation instructions:**

Refer to [sk168597 - How to install a Hotfix](https://support.checkpoint.com/results/sk/sk168597).

**Workaround:**

**Important** - Schedule a maintenance window because the procedure below can cause a traffic outage.

1. Connect to the command line on the ClusterXL Active member.
2. Log in.
3. Stop the Check Point services: `cpstop`
4. This triggers a ClusterXL failover.
5. Start the Check Point services: `cpstart`
6. Install policy on the cluster.

Policy installation must be successful on current ClusterXL Standby member.

Also, for cluster members, check the date of the policy installed with #fw stat; if there is a difference in policy date then reinstalling the policy helps to resolve the issue as well.

#### NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

## Article Properties

**Access Level**: General  
**Status**: Approved by TAC  
**Date Created**: 2024-09-16  
**Last Modified**: 2025-12-18