Virtual Systems are in "Unknown" state after reboot of VSX Cluster Member

Support Center > Search Results > SecureKnowledge Details

Solution ID	sk110074
Product	VSX, Enterprise Appliances, Data Center Security Appliances
Version	R77.30
OS	Gaia, Crossbeam XOS
Platform / Model	2000, 4000, 12000, 13000, 15000, 21000, 23000, IP1280, IP2450, Intel/PC, Power-1, UTM-1, VSX-1, X-Series
Date Created	11-Feb-2016
Last Modified	20-Jul-2017

Symptoms

After reboot of VSX Cluster Member, output of "cphaprob state" command shows:
- VSX Cluster Member is "Down"
- The following failure for the context of the affected Virtual Systems:
```
vsid <VSID>:
------
 Unable to open '/vs<ID>/dev/fw0': Connection refused
 Failed to query kernel for interface no. 0
```

After reboot of VSX Cluster Member, output of "vsx stat -v" command shows the following state of the affected Virtual Systems::

 ID    | Type & Name         | Security Policy   | Installed at    | SIC Stat
-------+---------------------+-------------------+-----------------+---------
<VSID> | S MemberName-VsName | Unknown           | Unknown         | Unknown

Restarting the affected Virtual System with "$FWDIR/scripts/vs_start.bash <VSID>" command resolves the issue - but only until the next reboot.

Cause

VSX Cluster Member fails to load the local VSX configuration in the following scenario:

VSX Cluster is managed by Multi-Domain Security Management Server.
Global Objects for Primary and Backup Domain Management Servers were defined and used in the policy.

Chain of events:

By design, Cluster Member tries to pull the policy/configuration from the peer member and from the Security Management Server / Domain Management Server based on the IP addresses of the relevant objects in SmartDashboard.
Each connection between Check Point machines is based on SIC.
VSX Cluster Member is able to obtain the SIC Name of the peer VSX Cluster Member, but pulling of VSX configuration is not allowed from peer VSX Cluster Members.
VSX Cluster Member fails to obtain the SIC Name of its Primary and Backup Domain Management Servers because (by design) their Global Objects do not have such attribute (SIC Name). This fails the pulling of VSX configuration from the Management Server.
As a result, the entire fetch process fails.

Solution

Note: To view this solution you need to Sign In .