6.4 Cluster Control Protocol (CCP) and State Synchronization

The Cluster Control Protocol (CCP)

The Cluster Control Protocol (CCP) is Check Point's proprietary protocol that runs between Cluster Members on UDP port 8116. It sits between the Check Point Firewall kernel and the network interface, and it has two main jobs:

1. State Synchronization (Delta Sync) — synchronizing the kernel connection tables between cluster members so that failover is stateful.
2. Health monitoring — heartbeats, member discovery, cluster-member probing, and state-change signaling.

CCP traffic does not need a Security Policy rule to be permitted; the Firewall kernel processes it before the Access Control policy is evaluated. The bulk of CCP traffic (~90% in steady state) is Delta Sync on UDP 8116; Full Sync, which only runs at cluster formation or after a sync disconnect, uses TCP port 263 (falling back to TCP 256).

CCP can be encrypted between members — and encryption is enabled by default. In Clish: set cluster member ccpenc on|off. In Expert mode: cphaconf ccp_encrypt on|off and cphaconf ccp_encrypt_key <key>. Encrypted CCP is recommended on any sync network that is not physically isolated.

CCP Transport Modes

CCP has four transport modes that control how CCP packets are sent on a given interface:

Configured in Clish with set cluster ccp {auto | unicast | multicast | broadcast} and in Expert mode with cphaconf set_ccp {auto | unicast | multicast | broadcast}. The setting is per cluster (applies to all interfaces) and survives reboot.

Important R82.x Behavior

On recent releases (R80.40+ and continuing through R82.x), CCP effectively runs in unicast mode for inter-member CCP traffic regardless of the configured mode, and the multicast/broadcast/auto modes are no longer separately configurable in the same way on the sync interface. For the CCSA R82 exam, recognize the four transport modes and their original purpose, but be aware that the practical configuration in R82 simplifies toward unicast. The CCP modes are a separate concept from the Load Sharing mode (Multicast / Unicast-Pivot) — do not conflate them.

State Synchronization

State Synchronization keeps the kernel connection tables identical across cluster members so that a failover does not drop existing connections. It has two phases:

Full Sync

Full Sync is the bulk transfer of the entire connection table from one member to another. It runs in two situations:

• When a member joins the cluster or after reboot (the member transitions through INIT until Full Sync completes, then becomes Ready/Active/Standby).
• When Delta Sync has been interrupted long enough that the members' tables have diverged too far to reconcile incrementally.

Full Sync uses TCP 263 (falling back to 256) and is much heavier than Delta Sync. A member in the INIT state is in the post-boot phase before Full Sync completes — it is part of the cluster but cannot yet forward traffic.

Delta Sync

Delta Sync is the continuous synchronization of connection-state changes as they happen — new connections, connection teardowns, NAT assignments, and so on. It runs on UDP 8116 alongside other CCP traffic. In a steady-state cluster, Delta Sync is the dominant sync traffic and is sized to be small enough that a modest sync link can carry it.

A useful mental model: Full Sync gets a member caught up when it joins; Delta Sync keeps it caught up afterward. If Delta Sync fails for long enough (sync link down, sync interface saturated), the cluster will trigger another Full Sync when the link recovers.

Sync Network Requirements

The sync network is the physical/VLAN path that carries CCP and state-sync traffic. Best practice:

• Dedicated interface — a separate physical interface (or VLAN) used only for sync; not shared with data-plane or management traffic.
• Dedicated switch — for production, a separate Layer 2 switch (or VLT/VPC domain) that does not also carry user traffic.
• Non-routed subnet — sync IPs should not be advertised to any routing protocol; the sync subnet is point-to-point between members.
• Low latency — sync must be fast enough that Delta Sync does not fall behind. High latency or packet loss on the sync link causes repeated Full Syncs and, in the worst case, cluster instability.
• Redundant sync links (optional) — ClusterXL supports multiple sync interfaces for redundancy; if one fails, sync continues on the other.

A common exam trap is suggesting that sync traffic can traverse the data network or the public Internet. It should not — sync carries connection state and (if CCP encryption is off) is sensitive. Even with CCP encryption, sync traffic should stay on a private, dedicated link.

Verifying Sync

Useful commands for sync health:

• cphaprob state — shows member states (Active, Standby, Down, etc.).
• cphaprob syncstat — sync statistics; look for Full Sync count and Delta Sync errors.
• cphaprob -a if — interface status including which interfaces are configured for sync and CCP mode.
• show cluster state (Clish) — human-readable cluster status.

If members repeatedly transition through INIT and Full Sync, suspect the sync link: errors, latency, or a misconfigured switch. If Delta Sync is failing but members stay Active/Standby, expect stale connection tables — connections may fail on failover.