ClusterXL Requirements and Compatibility

Check Point Appliances and Open Servers

You can install ClusterXL on Check Point appliances in one of these configurations:

• A distributed configuration - the Cluster Members and the Security Management Server are installed on different computers
• A Full High Availability configuration - the Cluster Members and the Security Management Servers are installed on the same computers (each computer runs a Standalone configuration)

You can install ClusterXL on Open Servers only in a distributed configuration - the Cluster Members and the Security Management Server are installed on different computers.

To see the ClusterXL supported platforms, see the R80.10 Release Notes.

For installation instructions, see the R80.10 Installation and Upgrade Guide.

Supported Number of Cluster Members

• ClusterXL in High Availability mode supports up to 5 Cluster Members.
• ClusterXL in Load Sharing mode supports up to 5 Cluster Members.

  Note - Configuring more than 4 members significantly decreases cluster performance due to amount of Delta Sync.

• VRRP Cluster on Gaia OS supports only 2 Cluster Members (see sk105170).
• Virtual System Load Sharing (VSLS) mode supports up to 13 Cluster Members.

Hardware Requirements for Cluster Members

ClusterXL operation completely relies on internal timers and calculation of internal timeouts, which are based on hardware clock ticks.

Therefore, in order to avoid unexpected behavior, ClusterXL is supported only between machines with identical CPU characteristics.

In addition, in order to avoid unexpected fail-overs due to issues with CCP packets on cluster interfaces, we strongly recommend to pair only identical physical interfaces as cluster interfaces - even when connecting the Cluster Members via a switch. For example:

• Intel 82598EB on Member_A with Intel 82598EB on Member_B
• Broadcom NeXtreme on Member_A with Broadcom NeXtreme on Member_B

Note - There is no requirement for throughput of Sync interface to be identical to, or larger than throughput of traffic interfaces (although, to prevent a possible bottle neck, a good practice for throughput of Sync interface is to be at least identical to throughput of traffic interfaces).

Software Requirements for Cluster Members

ClusterXL is supported only between identical operating systems - all Cluster Members must be installed on the same operating system).

ClusterXL is supported only between identical Check Point software versions - all Cluster Members must be installed with identical Check Point software, including OS build and hotfixes.

All Check Point software components must be the same on all Cluster Members. Meaning that the same Software Blades and features must be enabled on all Cluster Members:

• SecureXL status on all Cluster Members must be the same (either enabled, or disabled)
• Number of CoreXL FW instances on all Cluster Members must be the same

  Notes:

  • A Cluster Member with a greater number of CoreXL Firewall instances changes its state to DOWN.
  • Fail-over from a Cluster Member to a peer Cluster Member with a greater number of CoreXL Firewall instances keeps all connections.
  • Fail-over from a Cluster Member to a peer Cluster Member with a smaller number of CoreXL Firewall instances interrupts some connections. The connections that are interrupted are those that pass through CoreXL Firewall instances that do not exist on the peer Cluster Member.
• Advanced Dynamic Routing status and configuration on all Cluster Members must be the same

Otherwise, traffic might not be processed as expected and/or state of Cluster Members might change expectedly. In addition, Full Sync will fail.

Hardware Requirements for Switches and Routers

The Cluster is usually located in an environment having other networking devices, such as switches and routers. These devices and the Cluster Members must interact to assure network connectivity. This section outlines the requirements imposed by ClusterXL on surrounding networking equipment.

High Availability and Load Sharing Unicast Modes

When using CCP in multicast mode, configure the following settings on the switch:

By default, when ClusterXL is configured in High Availability mode or Load Sharing Unicast Mode, Cluster Members send the Cluster Control Protocol (CCP) packets in Multicast mode (the Layer 2 destination MAC address in the CCP packets is a multicast MAC address 01:00:5e:X:X:X). To let the CCP packets pass between Cluster Members, configure the settings below on the surrounding switches.

Switch Setting	Explanation
IGMP and Static CAMs	IGMP registration (also known as IGMP Snooping) is enabled by default on Cluster Members. You can disable IGMP registration on Cluster Members. In scenarios, where disabling IGMP registration is problematic, you can configure Static CAMs on switches to allow multicast traffic on specified switch ports.
Disabling multicast limits	Certain switches have an upper limit on the number of broadcasts and multicasts that they can pass, in order to prevent broadcast storms. This limit is usually a percentage of the total interface bandwidth. It is possible to either turn off broadcast storm control, or to allow a higher level of broadcasts or multicasts through the switch. If the connecting switch is incapable of having any of these settings configured, it is possible, though less efficient, for the switch to use broadcast to forward traffic, and to configure the Cluster Members to use broadcast CCP.

When using CCP in multicast mode, configure the following settings on the router:

By default, when ClusterXL is configured in High Availability mode or Load Sharing Unicast Mode, the unicast Cluster Virtual IP addresses are mapped to unicast MAC addresses of the physical interfaces on the Active or Pivot Cluster Member. To let the traffic reach the cluster, configure the settings below on the surrounding routers.

Router Setting	Explanation
Unicast MAC	The router needs to be able to learn this MAC through regular ARP messages.

Load Sharing Multicast Mode

When working with Load Sharing in Multicast mode, configure the following settings on the switch:

By default, when ClusterXL is configured in Load Sharing Multicast Mode, cluster members send the Cluster Control Protocol (CCP) packets in Multicast mode (the Layer 2 destination MAC address in the CCP packets is a multicast MAC address 01:00:5e:X:X:X).

Switch Setting	Explanation
Port Mirroring	ClusterXL in Load Sharing Multicast mod does not support the use of unicast MAC addresses with Port Mirroring.

When working with Load Sharing in Multicast mode, configure the following settings on the router:

By default, when ClusterXL is configured in High Availability mode or Load Sharing Multicast Mode, the unicast Cluster Virtual IP addresses are mapped to multicast MAC addresses (these are generated automatically by the Management Server based on the configured Cluster Virtual IP addresses). To let the traffic reach the cluster, the router must support sending unicast IP packets with multicast MAC addresses.

Router Setting	Explanation
Static MAC	Most routers can add ARP entries with a unicast IP address and a multicast MAC address automatically. If you have a router that is not able to learn this type of mapping dynamically, you need to configure static MAC entries to map unicast Cluster Virtual IP addresses to multicast MAC addresses.
IGMP and Static CAMs	Some routers require disabling of IGMP snooping, or configuration of static CAMs to support sending of unicast IP packets with multicast MAC addresses.
Disabling multicast limits	Certain routers have an upper limit on the number of broadcasts and multicasts that they can pass, in order to prevent broadcast storms. This limit is usually a percentage of the total interface bandwidth. It is possible to either turn off broadcast storm control, or to allow a higher limit of broadcasts or multicasts through the router.
Disabling forwarding of multicast traffic to the router itself	Some routers send multicast traffic to the router itself. This may cause a multicast storm through the network. Disable such configuration on your router.

VMAC Mode

When ClusterXL is configured in HA mode or Load Sharing Unicast mode (not Multicast), a single cluster member is associated with the Cluster Virtual IP address. In a High Availability environment, the single member is the Active member. In a Load Sharing Unicast environment, the single member is the Pivot.

After fail-over, the new Active member (or Pivot member) broadcasts a series of Gratuitous ARP Requests (G-ARP). The G-ARP packets associate the Virtual IP address of the cluster with the physical MAC address of the new Active member (or Pivot member). When this happens:

• A member with a large number of Static NAT entries can transmit too many G-ARP packets

  Switches may not integrate these GARP updates quickly enough into their ARP tables. Switches continue to send traffic to the physical MAC address of the member that failed. This results in traffic outage until the switches have fully updated ARP cache tables.

• Network components, such as VoIP phones, ignore G-ARP packets

  These components continue to send traffic to the MAC address of the failed member.

To minimize possible traffic outage during a fail-over, configure the cluster to use a virtual MAC address (VMAC).

By enabling Virtual MAC in ClusterXL High Availability mode, or Load Sharing Unicast mode, all cluster members associate the same Virtual MAC address with all Cluster Virtual Interfaces and the Virtual IP address. In Virtual MAC mode, the VMAC that is advertised by the cluster members (through Gratuitous ARP Requests) keeps the real MAC address of each member and adds a Virtual MAC address on top of it.

(For local connections and sync connections, the real MAC address of each member is still associated with its real IP address.)

You can enable VMAC in SmartConsole, or on the command line. See sk50840.

Failover time in a cluster with enabled VMAC mode is shorter than a failover in a cluster that uses a physical MAC addresses.

To configure VMAC Mode in SmartConsole:

1. Double-click the Cluster object to open its Properties window.
2. Go to the ClusterXL and VRRP page.
3. In the Select the cluster mode and configuration section, select High Availability and select ClusterXL.
4. In the Advanced Settings section, select Use Virtual MAC.
5. Click OK.
6. Install a Policy on this cluster object.

To configure VMAC Mode on the command line:

On each cluster member, set the same value for the global kernel parameter fwha_vmac_global_param_enabled.

1. Connect to the command line on each cluster member.
2. Log in to Expert mode.
3. Get the current value of this kernel parameter:

   fw ctl get int fwha_vmac_global_param_enabled

4. Set the new value for this kernel parameter temporarily (does not survive reboot):

   To enable VMAC mode: fw ctl set int fwha_vmac_global_param_enabled 1

   To disable VMAC mode: fw ctl set int fwha_vmac_global_param_enabled 0

5. Make sure the state of the VMAC mode was changed. Run:

   cphaprob -a if

   When VMAC mode is enabled, output of this command shows the VMAC address of each virtual cluster interface.

6. To set the new value for this kernel parameter permanently:

   Follow the instructions in sk26202 to add this line to the $FWDIR/boot/modules/fwkern.conf file:

   fwha_vmac_global_param_enabled=<value>

Hardware Compatibility with Switches and Routers

The following routers and switches are known to be compatible for all ClusterXL modes:

Device	Description
Switches	Cisco Catalyst 2900, 3500 Series Nortel BayStack 450 Alteon 180e Dell PowerConnect 3248 Dell PowerConnect 5224
Routing Switches	Extreme Networks Blackdiamond (need to disable IGMP snooping) Extreme Networks Alpine 3800 Series (need to disable IGMP snooping) Foundry Network Bigiron 4000 Series Nortel Networks Passport 8600 Series Cisco Catalyst 6500 Series (need to disable IGMP snooping and configure Multicast MAC manually)
Routers	Cisco 7200 Series Cisco 1600, 2600, 3600 Series

Example Configuration of a Cisco Catalyst Routing Switch

The following examples show how to perform the configuration needed to support ClusterXL on a Cisco Catalyst 6500 Series routing switch. For more details, or instructions for other networking devices, always refer to the device vendor documentation.

To disable IGMP snooping:

Cisco(config)# no ip igmp snooping

To disable multicast limits:

Cisco(config)# no storm-control multicast level

To define Static CAM entries:

To determine the MAC addresses that must be set:

1. On a network that has a Cluster Virtual IP address of x.y.z.w:
   • If y<=127, the multicast MAC address would be 01:00:5e:y:z:w

     For example: 01:00:5e:5A:0A:64 for 192.90.10.100

   • If y>127, the multicast MAC address would be 01:00:5e:(y-128):z:w

     For example: 01:00:5e:28:0A:64 for 192.168.10.100 (168 - 128 = 40 in dec = 28 in hex)

2. For a network x.y.z.0 that does not have a Cluster Virtual IP address, such as the Sync, you use the same procedure and substitute fa instead of 0 for the last octet of the MAC address.
   • For example: 01:00:5e:00:00:fa for the 10.0.0.X network

To add a permanent CAM entry for the multicast MAC address for module 1 - port 1, and module 2 - ports 1, 3, and 8 through 12:

Cisco> (enable) set cam permanent 01-40-5e-28-0a-64 1/1,2/1,2/3,2/8-12
Permanent multicast entry added to CAM table.
Cisco> (enable)

To prevent multicast packets from reaching the router:

1. Determine the MAC addresses that must be set (see above).
2. Define a static CAM entry (entry will remain in the CAM table until the switch is reset). Run:

   Cisco> (enable) set cam static <MAC address> module/port
Static unicast entry added to CAM table.
Cisco> (enable)

To define a static ARP entry:

1. Determine the MAC addresses that must be set (see above).
2. Define a static ARP entry. Run:

   Cisco(config)# arp <MAC address> arpa