|
|
|
This section lists the ClusterXL error messages.
This log message can happen if the working mode of the cluster members is not the same, for example, if one member is running High Availability, and another Load Sharing Multicast or Unicast mode. In this case, the internal ClusterXL mechanism tries to synchronize the configuration of the cluster members, by changing the working mode to the lowest common mode. The order of priority of the working modes (highest to lowest) is: 1. Synchronization only 2. Load Sharing 3. High Availability (Active Up) 4. High Availability (Primary Up).
This log message can occur during policy installation on the cluster. It means that a serious configuration problem exists in that cluster. Probably some other cluster has been configured with identical parameters and both of them have common networks.
This is caused when the cluster member that printed this message stops hearing certain types of messages from cluster member X. Make sure that cphaprob state command shows all cluster members as Active or Standby, and that fw ctl pstat command shows that Sync is configured correctly and working properly on all cluster members. In such a case, it is fair to assume that there was a temporary connectivity problem that was fixed in the meantime. There may be several connections that may suffer from connectivity problems due to that temporary synchronization problem between the cluster members. On the other hand, this can indicate that the other cluster member is really down.
A member of the same cluster as the reporting member has more than three virtual IP addresses defined on the same interface. This is not a supported configuration and will harm ClusterXL functionality.
Several problems of this sort can happen during a full sync session when there are connections that are opened and closed during the full sync process. Full sync is automatic as far as possible, but it is not fully automatic for reasons of performance, A Security Gateway continues to process traffic even when it is serving as a full sync server. This can cause some insignificant problems, such as a connection that is being deleted twice, a link to an existing link, and so forth. It should not affect connectivity or cause security issues.
Cluster in not synchronized. Usually happens when Support non-sticky connections checkbox is cleared in the cluster object's 3rd Party Configuration page.
The critical device (also known as Problem Notification, or pnote) mechanism can only store up to 16 different devices. An attempt to configure the 17th device (either by editing the $FWDIR/conf/cphaprob.conf file or by using the cphaprob -d ... register command) will result in this message.
Each device registered with the pnote mechanism must have a unique name. This message may happen when registering new pnote device, and means that the device <NAME> is already registered as with pnote number <NUMBER>.
Indicates an attempt to unregister a device which is not currently registered.
A log indicating that there is a different policy id between the two or more members was not sent. Make sure that all cluster members have the same policy (using fw stat). It is recommended to re-install the policy.
This message can be received when ClusterXL hears CCP packets of clusters of version 4.1. In that case it can be safely ignored.
The following error messages can appear in Logs & Monitor Active mode. These errors indicate that some entries may not have been successfully processed, which may lead to missing synchronization information on a cluster member and inaccurate reports in the Logs & Monitor logs.
Indicates a configuration problem on a clustered member. Either synchronization is misconfigured, or there is a problem with transmitting packets on the sync interface. To get more information on the source of the problem
Indicates that a clustered member has dropped Logs & Monitor Active mode updates in order to maintain sync functionality.
This message appears when the local member receives a retransmission request for a sequence number, which in no longer in its sending window. This message can indicate a sync problem if the sending member did not receive the requested sequence.
These messages may appear only during full sync. While performing full sync the delta sync updates are being saved and are applied only after the full sync process has finished. It is possible to limit the memory used for saving delta sync updates by setting the fw_sync_max_saved_buf_mem variable to this limit.
This message may appear due to high load resulting in the sync buffer being filled faster than it is being read.
This message may appear due to a problem starting the full sync process, and indicates a severe problem. Contact Technical Support.
This message could appear under extremely high load, when a synchronization update was permanently lost. A synchronization update is considered to be permanently lost when it cannot be retransmitted because it is no longer in the transmit queue of the update originator. This scenario does not mean that the Security Gateway will malfunction, but rather that there is a potential problem. The potential problem is harmless if the lost sync update was to a connection that runs only on a single member as in the case of unencrypted (clear) connections (except in the case of a failover when the other member needs this update).
The potential problem can be harmful when the lost sync update refers to a connection that is non-sticky (see Non-Sticky Connections), as is the case with encrypted connections. In this case the other cluster member(s) may start dropping packets relating to this connection, usually with a TCP out of state error message (see TCP Out-of-State Error Messages). In this case it is important to block new connections under high load, as explained in Blocking New Connections Under Load.
The following error message is related to this one.
These messages appear when there was a temporary sync problem and some of the sync updates were not synchronized between the members. As a result some of the connections might not survive a failover.
The previous error message is related to this one.
Previous versions used a kernel table called non_sync_ports to implement selective sync, which is a method of choosing services that do not need to be synchronized. Selective sync can now be configured from SmartConsole. See Choosing Services That Do Not Require Synchronization.
When the synchronization mechanism is under load, TCP packet out-of-state error messages may appear in the Information column of the Logs & Monitor logs. This section explains how to resolve each error.
These messages occur when a FIN packet is retransmitted after deleting the connection from the connection table. To solve the problem, in SmartConsole Global properties for Stateful Inspection, enlarge the TCP end timeout from 20 seconds to 60 seconds. If necessary, also enlarge the connection table so it will not fill completely.
This message occurs when a SYN is received on an established connection, and the sequence verifier is turned off. The sequence verifier is turned off for a non-sticky connection in a cluster (or in SecureXL). Some applications close connections with a RST packet (in order to reuse ports). To solve the problem, enable this behavior to specific ports or to all ports. For example, run the command:
fw ctl set int fw_trust_rst_on_port <port>
To configure the Security Gateway to trust a RST coming from every port, in case a single port is not enough.
