Explanation/Reference:
Reference: https://sc1.checkpoint.com/documents/R76/
CP_R76_PerformanceTuning_WebAdmin/6731.htm

There are three methods to implement implicit MEP:
First to Respond, in which the first Security Gateway to reply to the peer Security Gateway is chosen. An organization would choose this option if, for example, the organization has two Security Gateways in a MEP configuration - one in London, the other in New York. It makes sense for VPN-1 peers located in England to try the London Security Gateway first and the NY Security Gateway second. Being geographically closer to VPN peers in England, the London Security Gateway is the first to respond, and becomes the entry point to the internal network. See: First to Respond.
Primary-Backup, in which one or multiple backup Security Gateways provide "high availability" for a primary Security Gateway. The remote peer is configured to work with the primary Security Gateway, but switches to the backup Security Gateway if the primary goes down. An organization might decide to use this configuration if it has two machines in a MEP environment, one of which is stronger than the other. It makes sense to configure the stronger machine as the primary. Or perhaps both machines are the same in terms of strength of performance, but one has a cheaper or faster connection to the Internet. In this case, the machine with the better Internet connection should be configured as the primary. See: Primary-Backup Security Gateways.
Load Distribution, in which the remote VPN peer randomly selects a Security Gateway with which to open a connection. For each IP source/destination address pair, a new Security Gateway is randomly selected. An organization might have a number of machines with equal performance abilities. In this case, it makes sense to enable load distribution. The machines are used in a random and equal way. See: Random Selection.

Section: (none)
Explanation/Reference:
Explanation:
Synchronization works in two modes:
Full sync transfers all Security Gateway kernel table information from one cluster member to another. It

is handled by the fwd daemon using an encrypted TCP connection.
Delta sync transfers changes in the kernel tables between cluster members. Delta sync is handled by

the Security Gateway kernel using UDP multicast or broadcast on port 8116.
Full sync is used for initial transfers of state information, for many thousands of connections. If a cluster member is brought up after being down, it will perform full sync. After all members are synchronized, only updates are transferred via delta sync. Delta sync is quicker than full sync.
Reference: https://sc1.checkpoint.com/documents/R76/CP_R76_ClusterXL_AdminGuide/7288.htm Port info:
https://www.cpug.org/forums/archive/index.php/t-12704.html