ClusterXL Configuration Commands

Description

These commands let you configure internal behavior of the Clustering Mechanism.

Important:

Syntax

Notes:

Table: ClusterXL Configuration Commands

Description
of Command

Command in
Gaia Clish

Command in
Expert Mode

Configure how to show the Cluster MemberClosed Security Gateway that is part of a cluster. in local ClusterXLClosed Cluster of Check Point Security Gateways that work together in a redundant configuration. The ClusterXL both handles the traffic and performs State Synchronization. These Check Point Security Gateways are installed on Gaia OS: (1) ClusterXL supports up to 5 Cluster Members, (2) VRRP Cluster supports up to 2 Cluster Members, (3) VSX VSLS cluster supports up to 13 Cluster Members. Note: In ClusterXL Load Sharing mode, configuring more than 4 Cluster Members significantly decreases the cluster performance due to amount of Delta Sync traffic. logs - by its Member ID or its Member Name (see Configuring the Cluster Member ID Mode in Local Logs)

set cluster member idmode {id | name}

cphaconf mem_id_mode {id | name}

Register a single Critical DeviceClosed A special software device on each Cluster Member, through which the critical aspects for cluster operation are monitored. When the critical monitored component on a Cluster Member fails to report its state on time, or when its state is reported as problematic, the state of that member is immediately changed to Down. The complete list of the configured critical devices (pnotes) is printed by the 'cphaprob -ia list' command or 'show cluster members pnotes all' command. Synonyms: Pnote, Problem Notification. (Pnote) on the Cluster Member (see Registering a Critical Device)

N / A

cphaconf set_pnote -d <Name of Device> -t <Timeout in Sec> -s {ok|init|problem} [-p] [-g] register

Unregister a single Critical Device (Pnote) on the Cluster Member (see Unregistering a Critical Device)

N / A

cphaconf set_pnote -d <Name of Device> [-p] [-g] unregister

ReportClosed Summary of network activity and Security Policy enforcement that is generated by Check Point products, such as SmartEvent. (change) a state in a single Critical Device (Pnote) on the Cluster Member (see Reporting the State of a Critical Device)

N / A

cphaconf set_pnote -d <Name of Device> -s {ok|init|problem} [-g] report

Register several Critical Devices (Pnotes) from a file on the Cluster Member (see Registering Critical Devices Listed in a File)

N / A

cphaconf set_pnote -f <Name of File> [-g] register

Unregister all Critical Devices (Pnotes) on the Cluster Member (see Unregistering All Critical Devices)

N / A

cphaconf set_pnote -a [-g] unregister

Configure the Cluster Control ProtocolClosed Proprietary Check Point protocol that runs between Cluster Members on UDP port 8116, and has the following roles: (1) State Synchronization (Delta Sync), (2) Health checks (state of Cluster Members and of cluster interfaces): Health-status Reports, Cluster-member Probing, State-change Commands, Querying for cluster membership. Note: CCP is located between the Check Point Firewall kernel and the network interface (therefore, only TCPdump should be used for capturing this traffic). Acronym: CCP. (CCP) Encryption on the Cluster Member (see Configuring the Cluster Control Protocol (CCP) Settings)

set cluster member ccpenc {off | on}

cphaconf ccp_encrypt {off | on}

cphaconf ccp_encrypt_key <Key String>

Configure the Cluster Forwarding LayerClosed The Forwarding Layer is a ClusterXL mechanism that allows a Cluster Member to pass packets to peer Cluster Members, after they have been locally inspected by the firewall. This feature allows connections to be opened from a Cluster Member to an external host. Packets originated by Cluster Members are hidden behind the Cluster Virtual IP address. Thus, a reply from an external host is sent to the cluster, and not directly to the source Cluster Member. This can pose problems in the following situations: (1) The cluster is working in High Availability mode, and the connection is opened from the Standby Cluster Member. All packets from the external host are handled by the Active Cluster Member, instead. (2) The cluster is working in a Load Sharing mode, and the decision function has selected another Cluster Member to handle this connection. This can happen since packets directed at a Cluster IP address are distributed between Cluster Members as with any other connection. If a Cluster Member decides, upon the completion of the firewall inspection process, that a packet is intended for another Cluster Member, it can use the Forwarding Layer to hand the packet over to that Cluster Member. In High Availability mode, packets are forwarded over a Synchronization network directly to peer Cluster Members. It is important to use secured networks only, as encrypted packets are decrypted during the inspection process, and are forwarded as clear-text (unencrypted) data. In Load Sharing mode, packets are forwarded over a regular traffic network. Packets that are sent on the Forwarding Layer use a special source MAC address to inform the receiving Cluster Member that they have already been inspected by another Cluster Member. Thus, the receiving Cluster Member can safely hand over these packets to the local Operating System, without further inspection. on the Cluster Member (controls the forwardingClosed Process of transferring of an incoming traffic from one Cluster Member to another Cluster Member for processing. There are two types of forwarding the incoming traffic between Cluster Members - Packet forwarding and Chain forwarding. For more information, see "Forwarding Layer in Cluster" and "ARP Forwarding". of traffic between Cluster Members)

Note - For Check Point use only.

set cluster member forwarding {off | on}

cphaconf forward {off | on}

Print the current cluster configuration as loaded in the kernel on the Cluster Member (for details, see sk93306)

N / A

cphaconf debug_data

Start internal failoverClosed Transferring of a control over traffic (packet filtering) from a Cluster Member that suffered a failure to another Cluster Member (based on internal cluster algorithms). Synonym: Fail-over. between subordinate interfaces of specified bond interface - only in Bond High AvailabilityClosed A redundant cluster mode, where only one Cluster Member (Active member) processes all the traffic, while other Cluster Members (Standby members) are ready to be promoted to Active state if the current Active member fails. In the High Availability mode, the Cluster Virtual IP address (that represents the cluster on that network) is associated: (1) With physical MAC Address of Active member (2) With virtual MAC Address. Synonym: Active/Standby. Acronym: HA. mode (for details, see sk93306)

N / A

cphaconf failover_bond <bond_name>

Configure what happens during a failover after a Bond already failed over internally (for details, see sk93306)

N / A

cphaconf enable_bond_failover <bond_name>

Initiate manual cluster failover (see Initiating Manual Cluster Failover)

set cluster member admin {down | up}

clusterXL_admin {down | up}

Configure the minimal number of required subordinate interfaces for Bond Load SharingClosed A redundant cluster mode, where all Cluster Members process all incoming traffic in parallel. For more information, see "Load Sharing Multicast Mode" and "Load Sharing Unicast Mode". Synonyms: Active/Active, Load Balancing mode. Acronym: LS. (see Configuring the Minimal Number of Required Subordinate Interfaces for Bond Load Sharing)

N / A

cphaconf bond_ls {set <Bond Name> <Value> | remove <Bond Name>}

Configuring Link Monitoring on the Cluster Interfaces (see Configuring Link Monitoring on the Cluster Interfaces)

N / A

N / A

Configuring the Multi-Version ClusterClosed The Multi-Version Cluster mechanism lets you synchronize connections between cluster members that run different versions. This lets you upgrade to a newer version without a loss in connectivity and lets you test the new version on some of the cluster members before you decide to upgrade the rest of the cluster members. Acronym: MVC. Mechanism (see Configuring the Multi-Version Cluster Mechanism)

N / A

cphaconf mvc {off | on}

List of the Gaia Clish "set cluster member" commands

set cluster member admin {down | up} [permanent]

set cluster member ccpenc {off | on}

set cluster member forwarding {off | on}

set cluster member idmode {id | name}

set cluster member mvc {off | on}

List of the Expert mode "cphaconf" commands

Note - Some commands are not applicable to 3rd party clusters.

cphaconf [-D] <options> start

cphaconf stop

cphaconf [-t <Sync IF 1>...] [-d <Non-Monitored IF 1>...] add

cphaconf clear-secured

cphaconf clear-non-monitored

cphaconf debug_data

cphaconf delete_link_local [-vs <VSID>] <IF name>

cphaconf set_link_local [-vs <VSID>] <IF name> <Cluster IP>

cphaconf mem_id_mode {id | name}

cphaconf failover_bond <bond_name>

cphaconf [-s] {set | unset | get} var <Kernel Parameter Name> [<Value>]

cphaconf bond_ls {set <Bond Name> <Value> | remove <Bond Name>}

cphaconf set_pnote -d <Device> -t <Timeout in sec> -s {ok | init | problem} [-p] [-g] register

cphaconf set_pnote -f <File> [-g] register

cphaconf set_pnote -d <Device> [-p] [-g] unregister

cphaconf set_pnote -a [-g] unregister

cphaconf set_pnote -d <Device> -s {ok | init | problem} [-g] report

cphaconf ccp_encrypt {off | on}

cphaconf ccp_encrypt_key <Key String>