Registering Critical Devices Listed in a File

Important - In a Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., you must configure all the Cluster Members in the same way.

Description

This command registers all the user-defined Critical Devices listed in the specified file.

This file must be a plain-text ASCII file, with each Critical Device 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. defined on a separate line.

Each definition must contain three parameters, which must be separated by a space or a tab character:

<Name of Device> <Timeout> <Status>

Where:

Parameter	Description
`<Name of Device>`	The name of the Critical Device. Maximal name length is 15 characters The name must not include white spaces (space or tab characters).
`<Timeout>`	If the Critical Device `<Name of Device>` fails to report its state to the Cluster Member Security Gateway that is part of a cluster. within this specified number of seconds, the Critical Device (and by design the Cluster Member), are seen as failed. For no timeout, use the value `0` (zero).
`<Status>`	The Critical Device `<Name of Device>` reports one of these statuses to the Cluster Member: `ok` - Critical Device is alive. `init`- Critical Device is initializing. The Cluster Member is Down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.. In this state, the Cluster Member cannot become Active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism.. `problem` - Critical Device failed. If this state is reported to ClusterXL 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., the Cluster Member immediately goes Down. This causes a failover 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..

Parameter

Description

<Name of Device>

The name of the Critical Device.

Maximal name length is 15 characters
The name must not include white spaces (space or tab characters).

<Timeout>

If the Critical Device <Name of Device> fails to report its state to the Cluster Member Security Gateway that is part of a cluster. within this specified number of seconds, the Critical Device (and by design the Cluster Member), are seen as failed.

For no timeout, use the value 0 (zero).

<Status>

The Critical Device <Name of Device> reports one of these statuses to the Cluster Member:

ok - Critical Device is alive.
init- Critical Device is initializing. The Cluster Member is Down State of a Cluster Member during a failure when one of the Critical Devices reports its state as "problem": In ClusterXL, applies to the state of the Security Gateway component; in 3rd-party / OPSEC cluster, applies to the state of the State Synchronization mechanism. A Cluster Member in this state does not process any traffic passing through cluster.. In this state, the Cluster Member cannot become Active State of a Cluster Member that is fully operational: (1) In ClusterXL, this applies to the state of the Security Gateway component (2) In 3rd-party / OPSEC cluster, this applies to the state of the cluster State Synchronization mechanism..
problem - Critical Device failed. If this state is reported to ClusterXL 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., the Cluster Member immediately goes Down. This causes a failover 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..

Syntax

Shell	Command
Gaia Clish The name of the default command line shell in Check Point Gaia operating system. This is a restricted shell (role-based administration controls the number of commands available in the shell).	N / A
Expert mode	`cphaconf set_pnote -f /<Path>/<Name of File> [-g] register`

Note - The "-g" flag applies the command to all configured Virtual Systems.