Synchronizing Clusters on a Wide Area Network

Organizations sometimes need to locate Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. Members in geographical locations that are distant from each other.

A typical example is a replicated Data Center, whose locations are widely separated for disaster recovery purposes.

In such a configuration, it is clearly impractical to use a cross cable for the synchronization network A set of interfaces on Cluster Members that were configured as interfaces, over which State Synchronization information will be passed (as Delta Sync packets ). The use of more than one Synchronization Network for redundancy is not supported because the CPU load will increase significantly due to duplicate tasks performed by all configured Synchronization Networks. Synonyms: Sync Network, Secured Network, Trusted Network..

The synchronization network can be spread over remote sites, which makes it easier to deploy geographically distributed clustering.

There are two limitations to this capability:

1. The synchronization network must guarantee no more than 100ms latency and no more than 5% packet loss.

2. The synchronization network may include only Layer 2 networking devices - switches and hubs.

   No Layer 3 routers are allowed on the synchronization network, because routers drop 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.

   Note - The Active-Active A cluster mode (in versions R80.40 and higher), where cluster members are located in different geographical areas (different sites, different cloud availability zones). This mode supports the configuration of IP addresses from different subnets on all cluster interfaces, including the Sync interfaces. Each cluster member inspects all traffic routed to it and synchronizes the recorded connections to its peer cluster members. The traffic is not balanced between the cluster members. mode also supports Layer 3 (see Active-Active Mode in ClusterXL).

You can monitor and troubleshoot geographically distributed clusters using the command line interface.

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 Security Gateway that is part of a cluster. goes 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., 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 Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server., and aggregated.

  In the event of a cluster 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., 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.