ClusterXL Requirements and Compatibility

Check Point Appliances and Open Servers

You can install ClusterXLClosed Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. on Check Point appliances in one of these configurations:

You can install ClusterXL on Open Servers only in a distributed configuration - the Cluster Members and the Security Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. are installed on different computers.

To see the ClusterXL supported platforms, see the R81.10 Release Notes.

For installation instructions, see the R81.10 Installation and Upgrade Guide.

Supported Number of Cluster Members

Hardware Requirements for Cluster Members

ClusterXL operation completely relies on internal timers and calculation of internal timeouts, which are based on hardware clock ticks.

Therefore, in order to avoid unexpected behavior, ClusterXL is supported only between machines with identical CPU characteristics.

Best Practice - To avoid unexpected fail-overs due to issues with CCP packets on cluster interfaces, we strongly recommend to pair only identical physical interfaces as cluster interfaces - even when connecting the Cluster Members via a switch.

For example:

  • Intel 82598EB on Member_A with Intel 82598EB on Member_B

  • Broadcom NeXtreme on Member_A with Broadcom NeXtreme on Member_B

Note - There is no requirement for throughput of Sync interfaceClosed An interface on a Cluster Member, whose Network Type was set as Sync or Cluster+Sync in SmartConsole in cluster object. This interface is monitored by cluster, and failure on this interface will cause cluster failover. This interface is used for State Synchronization between Cluster Members. The use of more than one Sync Interfaces for redundancy is not supported because the CPU load will increase significantly due to duplicate tasks performed by all configured Synchronization Networks. Synonyms: Secured Interface, Trusted Interface. to be identical to, or larger than throughput of traffic interfaces (although, to prevent a possible bottle neck, a good practice for throughput of Sync interface is to be at least identical to throughput of traffic interfaces).

Software Requirements for Cluster Members

ClusterXL is supported only between identical operating systems - all Cluster Members must be installed on the same operating system).

ClusterXL is supported only between identical Check Point software versions - all Cluster Members must be installed with identical Check Point software, including OS build and hotfixes.

All Check Point software components must be the same on all Cluster Members. Meaning that the same Software Blades and features must be enabled on all Cluster Members:

Otherwise, traffic might not be processed as expected and/or state of Cluster Members might change unexpectedly. In addition, Full SyncClosed Process of full synchronization of applicable kernel tables by a Cluster Member from the working Cluster Member(s) when it tries to join the existing cluster. This process is meant to fetch a ‎"snapshot" of the applicable kernel tables of already Active Cluster Member(s). Full Sync is performed during the initialization of Check Point software (during boot process, the first time the Cluster Member runs policy installation, during 'cpstart', during 'cphastart'). Until the Full Sync process completes successfully, this Cluster Member remains in the Down state, because until it is fully synchronized with other Cluster Members, it cannot function as a Cluster Member. Meanwhile, the Delta Sync packets continue to arrive, and the Cluster Member that tries to join the existing cluster, stores them in the kernel memory until the Full Sync completes. The whole Full Sync process is performed by fwd daemons on TCP port 256 over the Sync network (if it fails over the Sync network, it tries the other cluster interfaces). The information is sent by fwd daemons in chunks, while making sure they confirm getting the information before sending the next chunk. Also see "Delta Sync". will fail.


When ClusterXL is configured in High Availability mode or Load Sharing Unicast mode (not Multicast), a single Cluster Member is associated with the Cluster Virtual IP address. In a High Availability environment, the single member is the ActiveClosed State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism. member. In a Load Sharing environment, the single member is the PivotClosed A Cluster Member in the Unicast Load Sharing cluster that receives all packets. Cluster Virtual IP addresses are associated with Physical MAC Addresses of this Cluster Member. This Pivot Cluster Member distributes the traffic between other Non-Pivot Cluster Members..

After fail-over, the new Active member (or Pivot member) broadcasts a series of Gratuitous ARP Requests (GARPs). The GARPs associate the Virtual IP address of the cluster with the physical MAC address of the new Active member or the new Pivot.

When this happens:

  • A member with a large number of Static NAT entries can transmit too many GARPs

    Switches may not integrate these GARP updates quickly enough into their ARP tables. Switches continue to send traffic to the physical MAC address of the member that failed. This results in traffic outage until the switches have fully updated ARP cache tables.

  • Network components, such as VoIP phones, ignore GARPs

    These components continue to send traffic to the MAC address of the failed memberClosed A Cluster Member that cannot send or accept traffic because of a hardware or software problem..

To minimize possible traffic outage during a fail-over, configure the cluster to use a Virtual MAC address (VMACClosed Virtual MAC Address. When this feature is enabled in a ClusterXL (in the High Availability or Load Sharing Unicast mode), the current Active or Pivot Cluster Member sends Gratuitous ARP Requests (G-ARP) for its Cluster Virtual IP (VIP) addresses and Virtual MAC (VMAC) addresses in G-ARP updates. Cluster Members create a VMAC address for each Cluster VIP address. This feature helps avoid issues during a cluster failover, when switches do not integrate G-ARP updates into their ARP cache table.).

By enabling Virtual MAC in ClusterXL High Availability mode, or Load Sharing Unicast mode, all Cluster Members associate the same Virtual MAC address with all Cluster Virtual Interfaces and the Virtual IP address. In the Virtual MAC mode, the VMAC that is advertised by the Cluster Members (through GARP Requests) keeps the real MAC address of each member and adds a Virtual MAC address on top of it.

For local connections and sync connections, the real physical MAC address of each Cluster Member is still associated with its real IP address.

Note - Traffic originating from the Cluster Members will be sent with the VMAC Source address.

FailoverClosed Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. time in a cluster with enabled VMAC mode is shorter than a failover in a cluster that uses a physical MAC addresses.

For configuration instructions, see Configuring Virtual MAC (VMAC).

Supported Topologies for Synchronization Network

Note - The topology numbers below are for convenience only.

Clock Synchronization in ClusterXL

When using ClusterXL, make sure to synchronize the clocks of all of the Cluster Members. You can synchronize the clocks manually, or using a protocol such as NTP. Features, such as VPN, only function properly when the clocks of all of the Cluster Members are synchronized.

IPv6 Support for ClusterXL

R81.10 ClusterXL supports High Availability clusters for IPv6.

IPv6 status information is synchronized and the IPv6 clustering mechanism is activated during failover.

Important - You must configure IPv4 address on each interface that has the Network Type "Cluster", "Sync", or "Cluster+Sync" (in SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. > the cluster object > Network Management page).

You can define IPv6 addresses for:

  • Cluster virtual interfaces

  • Member physical interfaces


  • IPv6 is not supported for Load Sharing clusters.

  • You cannot define IPv6 address for synchronization interfaces.

IPv6 in ClusterXL High Availability:

During failover, a cluster sends gratuitous ARP request packets to update hosts and routers connected to cluster interfaces. It does this by advertising the new MAC address for the virtual cluster IPv4 addresses.

ClusterXL updates the IPv6 network during failovers. ClusterXL sends Neighbor Advertisement messages to update the neighbor cache (which is equivalent to the ARP cache in IPv4) by advertising the new MAC address for the virtual cluster IPv6 address. In addition, ClusterXL will reply to any Neighbor Solicitation with a target address equal to the Virtual Cluster IPv6 address.

Note - ClusterXL failover event detection is based on IPv4 probingClosed If a Cluster Member fails to receive status for another member (does not receive CCP packets from that member) on a given segment, Cluster Member will probe that segment in an attempt to illicit a response. The purpose of such probes is to detect the nature of possible interface failures, and to determine which module has the problem. The outcome of this probe will determine what action is taken next (change the state of an interface, or of a Cluster Member).. During state transition the IPv4 driver instructs the IPv6 driver to reestablish IPv6 network connectivity to the HA cluster.

Synchronized Cluster Restrictions

These restrictions apply when you synchronize Cluster Members:

  • The use of more than one dedicated physical interface for synchronization redundancy is not supported.

    You can use Bonding for synchronization interface redundancy (see Sync Redundancy).

    Synchronization interface redundancy is not supported for VRRP Clusters. See sk92804.

  • All Cluster Members must run on identically configured hardware platforms.

  • If a Cluster Member goes down, user-authenticated connections through that member are lost.

    Other Cluster Members cannot restore the connection.

    Cluster Members maintain client-authenticated or session-authenticated connections.

    The reason for this restriction is that a user space process on Cluster Members maintains the user authentication state.

    Cluster Members cannot synchronize the user space information in the same way as they synchronize the kernel space information.

    Cluster Members save the states of Session Authentication and Client Authentication in kernel tables, which they synchronize.

  • Cluster Members cannot synchronize the connection statutes that use system resources. The reason is the same as for the user-authenticated connections.

  • Accounting information for connections is accumulated on each Cluster Member, sent to the Management Server, and aggregated.

    In the event of a cluster failover, the accounting information that is not yet sent to the Management Server, is lost.

    To minimize this risk, you can reduce the time interval when accounting information is sent.

    To do this, in the cluster object > Logs > Additional Logging pane, set a lower value for the Update Account Log every attribute.