For R80.10 and higher versions, refer to the Installation and Upgrade Guide of the version, to which you upgrade. (R80.10, R80.20, R80.30, R80.40, R81)
For R77.30 and lower versions, Refer to the main sk97552 (VSX Reconfigure and Upgrade Matrix to R77.10 / R77.20 / R77.30).
When to use this procedure
- After unrecoverable hardware or software failure.
- Adding a new cluster member.
Note: Renewable in the procedure below denotes a VSX cluster member, which should be reconfigured.
Backup the involved machines at the same time:
- Security Management Server / Multi-Domain Security Management Server
- Renewable VSX cluster member
Note: Refer to "Related Documentation" section below - "How to Backup".
- After a hardware failure on VSX machine, install replacement machine with identical hardware configuration.
- Install additional memory on the appliance (if needed)
- Verify that all cluster members have same physical components
- Make sure the CPUSE Agent is installed with the latest build
- Remove all the DATA ports and Sync interfaces and leave only the MGMT interface for the 'vsx_util reconfigure'.
- Perform clean installation of R77.30 / R80.10 / R80.20 / R80.30 / R80.40 / R81 on the Renewable VSX cluster member (refer to "Related Documentation" section below).
- Run Gaia First Time Configuration Wizard on the Renewable VSX cluster member (refer to sk71000 and sk69701).
In case of recovery from a failure, you must use the same Management IP address as was used by the previous cluster member (prior to the failure).
In case of adding new member, you will need to set the member IP address as specified in the 'vsx_util add_member' procedure.
Note: You do not need to establish SIC with the gateway - the vsx_util reconfigure process will do this for you.
- If any hotfixes were installed, then install them on the Renewable VSX cluster member.
For hotfix installation instructions, refer to the release notes that were provided with the hotfix, or contact Check Point Support.
Important Note: Installation of Jumbo Hotfixes requires an active Software-Blades License and cannot be completed with the default Trial License Configuration.
- Merging configuration files with cluster nodes:
- $FWDIR/boot/modules/vpnkern.conf - For versions R80.20 and higher, add the content of this file to $FWDIR/boot/modules/fwkern.conf (sk166179)
- $FWDIR/conf/resctrl - relevant only for versions R80.30 and lower (sk162434)
- Configure same number of CPUs for SND and configure MultiQ (If configured).
- Validation of number of CPUs and Hyper Threaded
Note: Please make sure CoreXL is disabled on VS0.
- Prevent the Renewable VSX cluster member from becoming Active before the reconfigure process ends:
[Expert@HostName]# cphaconf fini
[Expert@HostName]# touch /dev/shm/during_vsx_reconfigure
- Install the required licenses on the Renewable VSX cluster member using the cplic put command.
- In case Bonding, SNMP, IPV6 need to be configured, then configure it now on the Renewable VSX cluster member. Refer to the R77 Gaia Administration Guide.
- Make sure that nobody is logged into any of the CMAs/MGMT which are being managed.
- Start the reconfigure process on the Security Management Server / Main Domain Management Server.
In case of recovery from a failure, Run the
'vsx_util reconfigure' command and follow on screen instructions.
In case of adding new member, Run the
'vsx_util add_member_reconf' command and follow on screen instructions. (Make sure you run 'vsx_util add_member' procedure before, as mentioned in step 4.)
- Before reboot the Renewable VSX cluster member:
If you have vital configuration in Gaia OS / FireWall / SecureXL / CoreXL / etc. e.g:
- Relevant Only for R80.10:
- In case we are using 64 bit per VS - align the configuration before reboot (It Should be same as other cluster members) - refer to sk94627.
# vs_bits 64
- Relevant to all R80.X versions:
- In case of using Dynamic Routing / DHCP relay / Proxy ARP reconfigure the required Gaia OS settings in Clish.
- Verify that reconfigured cluster member should not be an active member for VSs
- For VSLS cluster - Enabling VSLS on Renewable VSX cluster member via cpconfig - Check Point Per Virtual System State
- Validation of custom configuration file on VS and VSX level: each file must be validated with existing cluster member:
- Reboot the Renewable VSX cluster member
- Connect Data and SYNC interfaces
- Validate cluster state
- Configuration (include configuration that was manually added to VS level)
- Failover to this member, verify traffic flow - depends on customer permission
- Check for hidden drops using "# fw ctl zdebug drop" - Depends on customer permission
- Check failover from this cluster node - depends on customer permission