Active-Active Mode in ClusterXL

Introduction

R80.40 introduced a new ClusterXL mode called Active-Active.

This mode is designed for a cluster, whose Cluster Members are located in different geographical areas (different sites, different cloud availability zones).

The IP addresses of the interfaces on each Cluster Member are on different networks (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 members.

Example Topology:

Important:

  • You can configure the Active-Active mode only on Management Server R80.40 (and higher) and only on ClusterXL R80.40 (and higher).

  • The Active-Active mode does not provide Load Sharing of the traffic.

    Administrator must monitor the load on each Cluster Member (see Monitoring and Troubleshooting Clusters).

  • Cluster Control Protocol (CCP) Encryption must be enabled, which is the default (see Configuring the Cluster Control Protocol (CCP) Settings).

  • It is possible to configure the Cluster Control Protocol (CCP) to work on Layer 2.

  • It is possible to enable Dynamic Routing on each Cluster Member, so they become routers in the applicable Area or Autonomous System on the site.

    In this case, you must enable the Bidirectional Forwarding Detection (BFD - ip-reachability-detection) on each interface that is configured for dynamic routing.

Configuring Active-Active mode

Step

Instructions

1

Install one ClusterXL Cluster Member on each site.

See the R80.40 Installation and Upgrade Guide.

Important:

On all Cluster Members in Active-Active mode, names of interfaces that belong to the same "side" must be identical (Known Limitation PMTR-70256).

Examples:

  • If you connected the interface eth1 to Switch #A on one Cluster Member, then you must connect the interface eth1 to Switch #A on all other Cluster Members.

  • If you configured the interface eth2 as a Sync interface on one Cluster Member, then you must configure the interface eth2 as a Sync on all other Cluster Members.

2

On each Cluster Member, set the value of the kernel parameter "ccl_force_sticky" to 0 (zero):

  1. Connect to the command line on each Cluster Member.

  2. Log in to the Expert mode.

  3. Set the value of the kernel parameter "ccl_force_sticky" to 0 (zero):

    fw ctl set -f int ccl_force_sticky 0

    The command output must show:

    "fwkern.conf" was updated successfully

  4. Make sure the kernel parameter "ccl_force_sticky" was added to the "fwkern.conf" file with the value of 0 (zero):

    cat $FWDIR/boot/modules/fwkern.conf

Note - It is not necessary to reboot Cluster Members.

3

Optional: On each Cluster Member, enable Dynamic Routing, so they become routers in the applicable Area or Autonomous System on the site.

Important - In this case, you must enable the Bidirectional Forwarding Detection (BFD - ip-reachability-detection) on each interface that is configured for dynamic routing.

See the R80.40 Gaia Advanced Routing Administration Guide.

4

Connect with SmartConsole to the Management Server.

5

From the left navigation panel, click Gateways & Servers.

6

Create a new Cluster object in one of these ways:

  • From the top toolbar, click the New () > Cluster > Cluster.

  • In the top left corner, click Objects menu > More object types > Network Object > Gateways and Servers > Cluster > New Cluster.

  • In the top right corner, click Objects Pane > New > More > Network Object > Gateways and Servers > Cluster > Cluster.

In the Check Point Security Gateway Cluster Creation window, you must click Classic Mode.

7

From the left tree, click General Properties.

  1. In the IPv4 Address field, you must enter the 0.0.0.0 address.

  2. On the Network Security tab, you must clear IPsec VPN.

  3. For the list of supported Software Blades, see the Known Limitation PMTR-70255 in sk160753.

8

From the left tree, click Cluster Members.

  1. Click Add > New Cluster Member.

    The Cluster Member Properties window opens.

  2. In the Name field, enter the applicable name for the first Cluster Member object.

  3. Configure the main physical IP address(es) for this Cluster Member object.

    In the IPv4 Address and IPv6 Address fields, configure the same IPv4 and IPv6 addresses that you configured on the Management Connection page of the Cluster Member's First Time Configuration Wizard.

    Make sure the Security Management Server or Multi-Domain Server can connect to these IP addresses.

  4. Click Communication.

  5. In the One-time password and Confirm one-time password fields, enter the same Activation Key you entered during the Cluster Member's First Time Configuration Wizard.

  6. Click Initialize.

  7. Click Close.

  8. Click OK.

  9. Repeat Steps a-h to add the second Cluster Member.

 

If the Trust State field does not show Trust established, perform these steps:

  1. Connect to the command line on the Cluster Member.

  2. Make sure there is a physical connectivity between the Cluster Member and the Management Server (for example, pings can pass).

  3. Run:

    cpconfig

  4. Enter the number of this option:

    Secure Internal Communication

  5. Follow the instructions on the screen to change the Activation Key.

  6. In SmartConsole, click Reset.

  7. Enter the same Activation Key you entered in the cpconfig menu.

  8. In SmartConsole, click Initialize.

9

From the left tree, click ClusterXL and VRRP.

  1. In the Select the cluster mode and configuration section, select Active-Active.

  2. In the Tracking section, select the applicable option.

  3. Optional: Select Use State Synchronization.

    This configures the Cluster Members to synchronize the information about the connections they inspect.

    Best Practice - Enable this setting to prevent connection drops after a cluster failover.

  4. Optional: Select Start synchronizing [  ] seconds after connection initiation and enter the applicable value.

    This option is available only for clusters R80.20 and higher.

    To prevent the synchronization of short-lived connections (which decreases the cluster performance), you can configure the Cluster Members to start the synchronization of all connections a number of seconds after they start.

    Range: 2 - 60 seconds

    Default: 3 seconds

    Notes:

    • This setting in the cluster object applies to all connections that pass through the cluster.

      You can override this global cluster synchronization delay in the properties of applicable services - see Configuring Services to Synchronize After a Delay.

    • The greater this value, the fewer short-lived connections the Cluster Members have to synchronize.

    • The connections that the Cluster Members did not synchronize, do not survive a cluster failover.

    Best Practice - Enable and configure this setting to increase the cluster performance.

10

Click OK to update the cluster object properties with the new cluster mode.

11

Open the cluster object and continue the configuration.

12

From the left tree, click Network Management.

  1. From the top, click the Get Interfaces > Get Interfaces With Topology.

    Important - On all Cluster Members in Active-Active mode, names of interfaces that belong to the same "side" must be identical (Known Limitation PMTR-70256).

  2. Select each interface and click Edit.

  3. From the left tree, click the General page.

  4. In the General section, in the Network Type field, select the applicable type:

    • For cluster traffic interfaces, select Cluster.

      In the IPv4 field, the dummy IP address 0.0.0.0 / 24 is configured automatically.

      Note - SmartConsole requires an IP address configured for each interface. Cluster Members do not get and do not use this IP address.

    • For cluster synchronization interfaces, select Sync.

      Notes:

      • Check Point cluster supports only one synchronization network. If redundancy is required, configure a Bond interface.

      • In the Network Type field, it is not supported to select "Cluster+Sync" (Known Limitation PMTR-70259) when you deploy a cluster in a cloud (for example: AWS, Azure).

    • For interfaces that do not pass the traffic between the connected networks, select Private.

  5. In the Member IPs section, make sure the IPv4 address and its Net Mask are correct on each Cluster Member.

  6. In the Topology section:

    Make sure the settings are correct in the Leads To and Security Zone fields.

    Only these options are supported on cluster interfaces (Known Limitation PMTR-70260):

    • Override > Network defined by routes (this is the default).

    • Override > Specific > select the applicable Network object or Network Group object.

13

Click OK.

14

Publish the SmartConsole session.

15

Configure and install the applicable Access Control Policy.

16

Configure and install the applicable Threat Prevention Policy.

17

Examine the cluster state.

See Viewing Cluster State.

Dynamic Routing Failover

By design, a Cluster Member changes its state to DOWN in these cases:

  • If there is an issue with the Sync interface (interface state or interface link).

    In this case, the Critical Device Interfaces Active Check on the Cluster Member reports its state as "problem".

  • If you run the command "clusterXL_admin down" (see The clusterXL_admin Script).

    In this case, the Critical Device admin_down on the Cluster Member reports its state as "problem".

When the cluster state of a Cluster Member is DOWN, it stops processing the dynamic routing traffic to force the next hop router to update its routing tables. As a result, there may be a network outage, because it takes time for dynamic routing protocols to update their routing tables and propagate the changes.

Note - If it is necessary that Cluster Members change their cluster state because of other Critical Devices, you must manually configure this behavior.