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 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.
-
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:
|
|
Note - There is no requirement for throughput of Sync interface |
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.
![Closed](transparent.gif)
-
The Sync interface is a Bond of several physical subordinate interfaces.
To work with this topology, you can configure the Bond interface in High Availability or Load Sharing mode.
-
All physical subordinate interfaces on all Cluster Members connect to the same switch.
-
In this topology, Cluster Members monitor only the link state of the subordinate interfaces.
![Closed](transparent.gif)
-
The Sync interface is a Bond of several physical subordinate interfaces.
To work with this topology, you can configure the Bond interface in High Availability or Load Sharing mode.
-
On each Cluster Member, physical subordinate interfaces of the same Bond connect to different switches.
-
The switches must connect to each other through a cable.
-
In this topology, Cluster Members monitor only the link state of the subordinate interfaces.
![Closed](transparent.gif)
-
The Sync interface is a Bond of several physical subordinate interfaces.
To work with this topology:
-
You must configure the Bond interface in the Active-Backup mode.
-
You must not configure the primary subordinate interface explicitly.
-
-
On each Cluster Member, physical subordinate interfaces of the same Bond connect to different switches.
-
The switches do not need to connect to each other through a cable.
-
In this topology, Cluster Members:
-
Monitor the link state of the subordinate interfaces.
-
Monitor the path between the Cluster Members, communicate about their connectivity, and agree on which bond subordinate interface to use.
-
Send Cluster Control Protocol
Proprietary Check Point protocol that runs between Cluster Members on UDP port 8116, and has the following roles: (1) State Synchronization (Delta Sync), (2) Health checks (state of Cluster Members and of cluster interfaces): Health-status Reports, Cluster-member Probing, State-change Commands, Querying for cluster membership. Note: CCP is located between the Check Point Firewall kernel and the network interface (therefore, only TCPdump should be used for capturing this traffic). Acronym: CCP. (CCP) packets only on the active subordinate interface (there is no CCP broadcast on all the subordinate interfaces).
-
Fail over only if all subordinate interfaces are down.
Additional information
If a Cluster Member does not receive CCP packets from other Cluster Members (for example, a cable is disconnected between switches), it sends a dedicated CCP packet to all other Cluster Members.
This dedicated CCP packet includes a map of all available bond subordinate interfaces on that Cluster Member.
When other Cluster Members receive this dedicated CCP packet, they:
-
Compare the received map of available bond subordinate interfaces to the state of their own bond subordinate interfaces.
-
Perform bond internal failover accordingly.
-
-
Fail over to a specific selected subordinate interface instead of iterating over all available subordinate interfaces.
-
![Closed](transparent.gif)
-
The Sync interface is a Bond of several physical subordinate interfaces.
To work with this topology:
-
You must configure the Bond interface in the Active-Backup mode.
-
You must not configure the primary subordinate interface explicitly.
-
-
On each Cluster Member, physical subordinate interfaces of the same Bond connect to different pairs of switches.
-
These pairs of switches connect to each other (chained together).
-
In this topology, Cluster Members:
-
Monitor the link state of the subordinate interfaces.
-
Monitor the path between the Cluster Members, communicate about their connectivity, and agree on which bond subordinate interface to use.
-
Send Cluster Control Protocol (CCP) packets only on the active subordinate interface (there is no CCP broadcast on all the subordinate interfaces).
-
Fail over only if all subordinate interfaces are down.
Additional information
If a Cluster Member does not receive CCP packets from other Cluster Members (for example, a cable is disconnected between switches), it sends a dedicated CCP packet to all other Cluster Members.
This dedicated CCP packet includes a map of all available bond subordinate interfaces on that Cluster Member.
When other Cluster Members receive this dedicated CCP packet, they:
-
Compare the received map of available bond subordinate interfaces to the state of their own bond subordinate interfaces.
-
Perform bond internal failover accordingly.
-
-
Fail over to a specific selected subordinate interface instead of iterating over all available subordinate interfaces.
-
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 |
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 |
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.