Configuring Policy Update Timeout

When policy is installed on a cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., the Cluster Members undertake a negotiation process to make sure all of them have received the same policy before they actually apply it.

This negotiation process has a timeout mechanism, which makes sure a Cluster Member Security Gateway that is part of a cluster. does not wait indefinitely for responses from other Cluster Members, which is useful in cases when another Cluster Member goes 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. when policy is being installed (for example).

In configurations, on which policy installation takes a long time (usually caused by a policy with a large number of rules), a cluster with more than two members, and slow members, this timeout mechanism may expire prematurely.

It is possible to tune the timeout with the kernel parameter fwha_policy_update_timeout_factor.

The default value of this kernel parameter is 1, which should be sufficient for most configurations.

For configurations where the situation described above occurs, setting the value of this kernel parameter to 2 should be sufficient.

Warning - Do not set the value of this kernel parameter to a number larger than 3.

See the R80.40 Quantum Security Gateway Guide - Chapter Working with Kernel Parameters on Security Gateway.