ClusterXL Requirements and Compatibility

Check Point Appliances and Open Servers

You can install ClusterXL 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:

• A Distributed configuration - the Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Members and the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server. are installed on different computers.

• A Full High Availability A special Cluster Mode supported only on Check Point appliances running Gaia OS (R75.40 and higher) or SecurePlatform OS (R77.30 and lower), where each Cluster Member also runs as a Security Management Server. This provides redundancy both between Security Gateways (only High Availability is supported) and between Security Management Servers (only High Availability is supported). Synonyms: Full HA Cluster Mode, Full HA, FullHA. configuration - the Cluster Members and the Security Management Servers are installed on the same computers (each computer runs a Standalone Configuration in which the Security Gateway and the Security Management Server products are installed and configured on the same server. configuration).

You can install ClusterXL on Open Servers only in a distributed configuration - the Cluster Members and the Security Management Server 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 Release Notes.

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

Supported Number of Cluster Members

• ClusterXL in High Availability A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. mode supports up to 5 Cluster Members.

• ClusterXL in Load Sharing A redundant cluster mode, where all Cluster Members process all incoming traffic in parallel. For more information, see "Load Sharing Multicast Mode" and "Load Sharing Unicast Mode". Synonyms: Active/Active, Load Balancing mode. Acronym: LS. mode supports up to 5 Cluster Members.

  Note - Configuring more than 4 members significantly decreases cluster performance due to amount of Delta Sync Synchronization of kernel tables between all working Cluster Members - exchange of CCP packets that carry pieces of information about different connections and operations that should be performed on these connections in relevant kernel tables. This Delta Sync process is performed directly by Check Point kernel. While performing Full Sync, the Delta Sync updates are not processed and saved in kernel memory. After Full Sync is complete, the Delta Sync packets stored during the Full Sync phase are applied by order of arrival..

• VRRP Cluster on Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. OS supports only 2 Cluster Members (see sk105170).

• Virtual System Load Sharing (VSLS) mode supports up to 13 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 interface 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:

• SecureXL Check Point product on a Security Gateway that accelerates IPv4 and IPv6 traffic that passes through a Security Gateway. status on all Cluster Members must be the same (either enabled, or disabled)

• Number of CoreXL Performance-enhancing technology for Security Gateways on multi-core processing platforms. Multiple Check Point Firewall instances are running in parallel on multiple CPU cores. Firewall instances on all Cluster Members must be the same

  Notes: A Cluster Member Security Gateway that is part of a cluster. with a greater number of CoreXL Firewall instances changes its state to DOWN State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.. Fail-over from a Cluster Member to a peer Cluster Member with a greater number of CoreXL Firewall instances keeps all connections. Fail-over from a Cluster Member to a peer Cluster Member with a smaller number of CoreXL Firewall instances interrupts some connections. The connections that are interrupted are those that pass through CoreXL Firewall instances that do not exist on the peer Cluster Member.

• Advanced Dynamic Routing status and configuration on all Cluster Members must be the same

Otherwise, traffic might not be processed as expected and/or state of Cluster Members might change unexpectedly. In addition, Full Sync 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.

VMAC Mode

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 Active 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 Pivot 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 member 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 (VMAC 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.

Failover 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 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 SmartConsole 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

Limitations:

• 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 probing 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.