Print Download PDF Send Feedback

Previous

Next

ClusterXL Configuration Commands

Included Topics

The cphaconf command

cphastart and cphastop

The cphaconf command

Description The cphaconf command configures ClusterXL.

Important - Running this command is not recommended. It should be run automatically, only by the Security Gateway or by Check Point support. The only exception to this rule is running this command with set_cpp option, as described below.

Usage

cphaconf [-i <computer id>] [-p <policy id>] [-b <db_id>] [-n <ClusterXL num>]
[-c <ClusterXL size>] [-m <service >] [-t <secured IF 1>...] start

cphaconf [-t <secured IF 1>...] [-d <disconnected IF 1>...] add
cphaconf clear-secured
cphaconf clear-disconnected
cphaconf stop
cphaconf init
cphaconf forward <on/off>
cphaconf debug <on/off>
cphaconf set_ccp <broadcast/multicast>
cphaconf mc_reload
cphaconf debug_data
cphaconf stop_all_vs

Syntax

Parameter

Description

set_ccp <broadcast/multicast>

Sets whether ClusterXL Control Protocol (CCP) packets should be sent with a broadcast or multicast destination MAC address. The default behavior is multicast. The setting created using this command will survive reboot.

Note: The same value (either broadcast or multicast) should be set on all ClusterXL members.

stop_all_vs

Stops the ClusterXL product on all Virtual Systems on a VSX Gateway.

cphastart and cphastop

Running cphastart on a cluster member activates ClusterXL on the member. It does not initiate full synchronization. cpstart is the recommended way to start a cluster member.

Running cphastop on a cluster member stops the cluster member from passing traffic. State synchronization also stops. It is still possible to open connections directly to the cluster member.

These commands should only be run by the Security Gateway, and not directly by the user.

How to Initiate Failover

Method

To Stop ClusterXL

To Start ClusterXL

Run:

cphaprob -d faildevice -t 0 -s ok register
cphaprob -d faildevice -s problem report

and:

cphaprob -d faildevice -s ok report
cphaprob -d faildevice unregister

Effect:

  • Disables ClusterXL
  • Does not disable synchronization

Effect:

  • Enables ClusterXL
  • Does not initiate full synchronization

Recommended method:
Run:

  • clusterXL_admin down
  • clusterXL_admin up
  • Disables ClusterXL
  • Does not disable synchronization

 

  • Enables ClusterXL
  • Does not initiate full synchronization

In SmartView Monitor:

  1. Click the Cluster object.
  2. Select one of the member Security Gateway branches.
  3. Right click the cluster member.
  4. Select Down.
  • Disables ClusterXL
  • Disables synchronization
  • Enables ClusterXL
  • Does not initiate full synchronization

In Load Sharing mode, the cluster distributes the load between the remaining active members.

In HA mode, the cluster fails over to next active member with the highest priority.

For more on initiating manual failovers, see: sk55081

Monitoring Synchronization (fw ctl pstat)

To monitor the synchronization mechanism on ClusterXL or third-party OPSEC certified clustering products:

The output of this command is a long list of statistics for the Security Gateway. At the end of the list there is a section called "Synchronization" which applies per Cluster member. Many of the statistics are counters that can only increase. A typical output is as follows:

Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:                   
 total : 3976,  retransmitted : 0, retrans reqs : 58,  acks : 97    
Sync packets received:
 total : 4290,  were queued : 58, dropped by net : 47
 retrans reqs : 0, received 0 acks
 retrans reqs for illegal seq : 0
 Callback statistics: handled 3 cb, average delay : 1,  max delay : 2
Delta Sync memory usage: currently using XX KB mem
Callback statistics: handled 322 cb, average delay : 2,  max delay : 8
Number of Pending packets currently held: 1
Packets released due to timeout: 18 

The meaning of each line in this printout is explained below.

 Version: new 

This line must appear if synchronization is configured. It indicates that new sync is working (as opposed to old sync from version 4.1).

Status: Able to Send/Receive sync packets 

If sync is unable to either send or receive packets, there is a problem. Sync may be temporarily unable to send or receive packets during boot, but this should not happen during normal operation. When performing full sync, sync packet reception may be interrupted.

Sync packets sent:                      
 total : 3976,  retransmitted : 0, retrans reqs : 58,  acks : 97 

The total number of sync packets sent is shown. Note that the total number of sync packets is non-zero and increasing.

The cluster member sends a retransmission request when a sync packet is received out of order. This number may increase when under load.

Acks are the acknowledgments sent for received sync packets, when an acknowledgment was requested by another cluster member.

Sync packets received:                 
  total : 4290,  were queued : 58, dropped by net : 47 

The total number of sync packets received is shown. The queued packets figure increases when a sync packet is received that complies with one of the following conditions:

  1. The sync packet is received with a sequence number that does not follow the previously processed sync packet.
  2. The sync packet is fragmented. This is done to solve MTU restrictions.

This figure never decreases. A non-zero value does not indicate a problem.

The dropped by net number may indicate network congestion. This number may increase slowly under load. If this number increases too fast, a networking error may be interfering with the sync protocol. In that case, check the network.

retrans reqs : 0, received 0 acks
 retrans reqs for illegal seq : 0
 Callback statistics: handled 3 cb, average delay : 1,  max delay : 2 

This message refers to the number of received retransmission requests, in contrast to the transmitted retransmission requests in the section above. When this number grows very fast, it may indicate that the load on the member is becoming too high for sync to handle.

Acks refer to the number of acknowledgments received for the "cb request" sync packets, which are sync packets with requests for acknowledgments.

Retrans reqs for illegal seq displays the number of retransmission requests for packets which are no longer in this member possession. This may indicate a sync problem.

Callback statistics relate to received packets that involve Flush and Ack. This statistic only appears for a non-zero value.

The callback average delay is how much the packet was delayed in this member until it was released when the member received an ACK from all the other members. The delay happens because packets are held until all other cluster members have acknowledged reception of that sync packet.

This figure is measured in terms of numbers of packets. Normally this number should be small (~1-5). Larger numbers may indicate an overload of sync traffic, which causes connections that require sync acknowledgments to suffer slight latency.

dropped updates as a result of sync overload: 0 

In a heavily loaded system, the cluster member may drop synchronization updates sent from another cluster member.

Delta Sync memory usage: currently using XX KB mem 

Delta Sync memory usage only appears for a non-zero value. Delta sync requires memory only while full sync is occurring. Full sync happens when the system goes up- after reboot for example. At other times, Delta sync requires no memory because Delta sync updates are applied immediately. For information about Delta sync see How State Synchronization Works.

 Number of Pending packets currently held: 1
   Packets released due to timeout: 18 

Number of Pending packets currently held only appears for a non-zero value. ClusterXL prevents out-of-state packets in non-sticky connections. It does this by holding packets until a SYN-ACK is received from all other active cluster members. If for some reason a SYN-ACK is not received, the Security Gateway on the cluster member will not release the packet, and the connection will not be established.

Packets released due to timeout only appears for a non-zero value. If the Number of Pending Packets is large (more than 100 pending packets), and the number of Packets released due to timeout is small, you should take action to reduce the number of pending packets. To solve this problem, see Reducing the Number of Pending Packets.