Important Note: Based on the reports from the field and multiple tests in the lab, the use of more than one Synchronization Network for redundancy is not supported for the following reasons:
- By design, the Delta Sync traffic is duplicated on the sending cluster member on all the configured Synchronization Networks (the receiving cluster member checks all received Delta Sync packets and discards the packets that were already processed on one of the Synchronization Networks). This increases load on the CPU on all cluster members.
- By design, if a cluster interface goes down (from cluster point of view), the member will go into "Down" state. This applies to Sync interfaces as well. Meaning, configuring multiple Synchronization Networks does not provide 100% sync redundancy.
- Multiple Synchronization Networks are not supported in VSX.
Note: The ability to configure multiple Synchronization Networks in a cluster object will still exist in SmartDashboard for unique special cases where the cluster administrator is unable to create Bond interfaces.
Table of Contents:
In version R80.20 new sync redundancy capabilities have been added, for more information refer to: ClusterXL R80.20 admin Guide - 'Supported Topologies for Synchronization Network'.
In version R80.10 there is an option to configure sync redundancy under the bond interface configuration. It supports both bond LS and bond HA (old topologies before R80.20)
In versions R77.30 and below, in order to implement Sync Redundancy, configure several physical interfaces as a Bond interface - in High Availability (Active/Backup) mode, or Load Sharing (Active/Active) mode - and then configure the dedicated Synchronization Network over this single Bond interface.
Connect the Sync bond interface of each member to the same switch or VLAN or Back-to-Back.
(2) Procedure for versions R77.30 and below
Define Bond interface with slaves intended for Sync network on all members.
Refer to these Administration Guides:
- For Gaia OS: Gaia Administration Guide (R75.40, R75.40VS, R76, R77) - Chapter 'Network Management' - Network Interfaces - Bond Interfaces (Link Aggregation).
- For SecurePlatform OS: ClusterXL Administration Guide (R70, R71, R75, R75.20, R75.40, R75.40VS, R76, R77) - Chapter 'ClusterXL Advanced Configuration' - Link Aggregation and Clusters.
Example for Gaia OS:
Note: On all members - either use Gaia Portal, or run the following commands in Clish.
Create the Bond interface (in this example, Bond 0):
HostName> add bonding group 0
HostName> set bonding group 0 mode 8023AD
Add slave interfaces to Bond (in this example, eth1 and eth2 are the intended bonded interfaces for Sync):
HostName> add bonding group 0 interface eth1
HostName> add bonding group 0 interface eth2
HostName> save config
Connect to Security Management Server with SmartDashboard.
Open the cluster object.
Go to Topology pane - click on Edit....
Under the name of each member, click on Get Topology.
Check the configuration of Virtual IP addresses.
Configure the new Bond interface as "1st Sync" interface (The slaves will not be seen, only the bond interface is):
Click on 'OK' to apply the settings.
Save the settings: go to File menu - click on Save.
Install policy onto this cluster.
Verify by running the cphaprob -a if command on cluster members - Sync interface should state it is in Bond mode.
Example for Bond in HA mode:
When adding the current Sync interface as a slave into the newly created Bond, instead of moving the Sync to another interface, we might face the following issue in the output of "cphaprob -a if" command:
Warning: Sync will not function since there aren't any sync(secured) interfaces
The new Bond interface will act as a Sync interface, but it will be displayed in the output of "cphaprob -a if" command as a regular monitored interface.
To update the Check Point kernel about the new Bond and Sync, restart the Check Point services with "cpstop;cpstart" commands (Note: This might cause fail-over).
- 802.3ad is the recommended Bond mode.
- When using Sync over Bond in HA mode (Active-Backup), slave interfaces must be added in the same order on all cluster members.