Configuring the CCP Transport Mode on the Cluster Members

From R80.20, the Cluster Control Protocol (CCP) has four modes:

Mode	Description
Automatic	The CCP mode changes automatically between Multicast, Broadcast, and Unicast to find the optimized CCP mode according to network state. These CCP mode changes are independent for individual interfaces. This CCP mode prevents unnecessary cluster failovers and interface state changes when CCP packets are not received because of networking issues.
Unicast	This CCP mode is applicable to clusters of two members only. In this CCP mode, the CCP packets are sent to a unicast Layer 2 destination MAC address of a peer Cluster Member. This CCP mode decreases unneeded network traffic and overcomes network barriers (switches that does not pass multicast traffic, and so on).
Multicast	In this CCP mode, the CCP packets are sent to a multicast Layer 2 destination MAC address (01:00:5E:xx:yy:zz). See sk25977. This is the default CCP mode for non-Sync interfaces.
Broadcast	In this CCP mode, the CCP packets are sent to a broadcast Layer 2 MAC address (FF:FF:FF:FF:FF:FF). See sk25977 and sk36644. This is the default CCP mode for Sync interface. This is the only supported CCP mode on Bridge interfaces. Use this CCP mode if the connecting switches do not pass CCP multicast packets.

To set the CCP mode:

• In Gaia Clish, run:

  set cluster ccp {auto | unicast | multicast | broadcast}

• In Expert mode, run:

  cphaconf set_ccp {auto | unicast | multicast | broadcast}

This configuration applies immediately and survives reboot.

To monitor the CCP mode:

• In Gaia Clish, run:

  show cluster members interfaces virtual

• In Expert mode, run:

  cphaprob -a if

Example output:

[Expert@Member2:0]# cphaprob -a if   CCP mode: Automatic Required interfaces: 3 Required secured interfaces: 1   eth0 UP non sync(non secured), multicast eth1 UP sync(secured), unicast eth2 UP non sync(non secured), multicast   Virtual cluster interfaces: 2   eth0 192.168.3.55 VMAC address: 00:1C:7F:00:36:70 eth2 192.250.3.55 VMAC address: 00:1C:7F:00:36:70   [Expert@Member2:0]# [Expert@Member2:0]# cphaconf set_ccp auto [Expert@Member2:0]# [Expert@Member2:0]# cat $FW_BOOT_DIR/ha_boot.conf ha_installed 1 ccp_mode automatic [Expert@Member2:0]# [Expert@Member2:0]# cphaconf set_ccp broadcast [Expert@Member2:0]# [Expert@Member2:0]# cphaprob -a if   CCP mode: Manual (Broadcast) Required interfaces: 3 Required secured interfaces: 1   eth0 UP non sync(non secured), broadcast eth1 UP sync(secured), broadcast eth2 UP non sync(non secured), broadcast   Virtual cluster interfaces: 2   eth0 192.168.3.55 VMAC address: 00:1C:7F:00:36:70 eth2 192.250.3.55 VMAC address: 00:1C:7F:00:36:70   [Expert@Member2:0]# [Expert@Member2:0]# cat $FW_BOOT_DIR/ha_boot.conf ha_installed 1 ccp_mode broadcast [Expert@Member2:0]# [Expert@Member2:0]# grep ccp /config/active cluster:ccp:broadcast t [Expert@Member2:0]#

Configuring the Cluster Object and Members

The Check Point Appliance or Open Server Wizard is recommended for enterprise grade appliances and open server platforms.

To create a new cluster with the Appliance or Open Server Wizard:

1. In SmartConsole, right-click Check Point in the Network Objects tree.
2. Select Security Cluster > Check Point Appliance/Open Server.
3. In the Check Point Security Gateway Cluster Creation window, click Wizard Mode.
4. In the Cluster General Properties window, enter or select:
   • Cluster Name - Unique name for the cluster
   • Cluster IPv4 and IPv6 address - Virtual Management IP addresses for this cluster.

     Important: You must define a corresponding IPv4 address for every IPv6 address. This release does not support pure IPv6 addresses.

   • Choose the Cluster Solution - Select Check Point ClusterXL and then select High Availability or Load Sharing (must follow sk162637).
5. In the Cluster Member Properties window, click Add > New Cluster Member to configure each member.
   1. Enter the physical IPv4 and IPv6 addresses.

      Note: Make sure that you do not define IPV6 address for sync interfaces. The wizard does not let you define an interface with an IPv6 address as a sync interface.

   2. Enter and confirm the SIC trust activation key.
6. In the Cluster Topology window, define a network objective (Role) for each network interface and, if necessary, define the virtual cluster IP addresses.

   The wizard automatically calculates the subnet for each network and assigns it to the applicable interface on each member. The calculated subnet shows in the upper section of the window.

   The available network objectives are:

   • Cluster Interface - A cluster interface that connects to an internal or external network. Enter the cluster virtual IP addresses for each network (internal or external). These addresses must be located in the calculated subnet.
   • Cluster Sync Interface - A cluster synchronization interface. You must define one or more synchronization interfaces for redundancy. If you are using more than one synchronization interface, define which interface is the primary, secondary, or tertiary interface. Synchronization redundancy is not supported on Small Business appliances. On these appliances, you can only select 1st sync and only for the LAN2/SYNC interface. You cannot configure VLANs on the synchronization interface.
   • Monitored Private - An interface that is not part of the cluster, but ClusterXL monitors the member state and failover occurs if a fault is detected.
   • Non Monitored Private - ClusterXL does not monitor the member state and there is no failover.

     This option is recommended for the management interface.

7. Click Next and then Finish to complete the wizard.

After you finish the wizard, we recommend that you open the cluster object and do these procedures:

• Define Anti-Spoofing properties for each interface
• Change the topology type (Internal or External) if necessary
• Configure other Software Blades, features and properties as necessary.

VRRP Cluster

Virtual Router Redundancy Protocol (VRRP) provides dynamic failover of IP addresses from one router to another in the event of failure. This increases the availability and reliability of routing paths via gateway selections on an IP network. Each VRRP router has a unique identifier known as the Virtual Router Identifier (VRID) which is associated with at least one Virtual IP Address (VIP). Neighboring network nodes connect to the VIP as a next hop in a route or as a final destination. Gaia supports VRRP as defined in RFC 3768.

On Gaia, VRRP can be used with or without ClusterXL enabled. The most common use case is with ClusterXL enabled. This guide describes one way of configuring VRRP, known as Monitored Circuit/Simplified VRRP, with ClusterXL enabled. To learn about all the ways of configuring VRRP, and to use VRRP without ClusterXL enabled, see the Gaia Administration Guide.

With ClusterXL enabled, VRRP supports a maximum of one VRID with one Virtual IP Address (VIP) on every interface. Only active/backup environments are supported, and you must configure VRRP so that the same node is the VRRP master for all VRIDs. This means that you must configure each VRID to monitor every other VRRP-enabled interface. You must also configure priority deltas to allow failover to the backup node when the VRID on any interface does a failover.

Monitored Circuit/Simplified VRRP makes possible a complete node failover by automatically monitoring all VRRP-enabled interfaces. You configure one VRID, and this VRID is automatically added to all the VRRP interfaces. If the VRID on any interface fails, the configured priority delta is decremented on the other interfaces. This allows the backup node to take over as the VRRP master.

How VRRP Failover Works

Each Virtual Router (VRRP Group) is identified by a unique Virtual Router ID (VRID). A Virtual Router contains one Master Security Gateway, and at least one Backup Security Gateway. The master sends periodic VRRP advertisements (known as hello messages) to the backups.

VRRP advertisements broadcast the operational status of the master to the backups. Gaia uses dynamic routing protocols to advertise the VIP (virtual IP address or backup address) of the Virtual Router.

If the master or its interfaces fails, VRRP uses a priority algorithm to decide if failover to a backup is necessary. Initially, the master is the Security Gateway that has the highest defined priority value. You define a priority for each Security Gateway when you create a Virtual Router or change its configuration. If two Security Gateways have same priority value, the platform that comes online and broadcasts its VRRP advertisements first, becomes the master.

Gaia also uses priorities to select a backup Security Gateway upon failover (when there is more than one backup available). In the event of failover, the Virtual Router priority value is decreased by a predefined Priority Delta value to calculate an Effective Priority value. The Virtual Router with the highest effective priority becomes the new master. The Priority Delta value is a Check Point proprietary parameter that you define when configuring a Virtual Router. If you configure your system correctly, the effective priority will be lower than the backup gateway priority in the other Virtual Routers. This causes the problematic master to fail over for the other Virtual Routers as well.

Note- If the effective priority for the current master and backup are the same, the Gateway with the highest IP address becomes the master.

Internal Network High Availability

This is a simple VRRP use case, where Security Gateway 1 is the VRRP Master, and Security Gateway 2 is the VRRP Backup. Virtual Router redundancy is available only for connections to and from the internal network. There is no redundancy for external network traffic.

Item	Description
1	VRRP Master Security Gateway
2	VRRP Backup Security Gateway
3	Virtual Router VRID 5 - Virtual IP Address (Backup Address) is 192.168.2.5
4	Internal Network and hosts