|
|
|
In This Section: |
This chapter presents the procedures for configuring VSX in various cluster deployment scenarios. In addition to the basic scenarios, conceptual material and illustrative examples are presented for several advanced features, including the Bridge mode and dynamic routing.
You will use SmartDashboard for most of the basic cluster configurations. You will need the command line interface to add more members, remove members, and upgrade members. Many advanced cluster management procedures require the command line.
The majority of the basic cluster configuration process is performed using SmartDashboard, both in Security Management and Multi-Domain Security Management models. However, you will need to use the command line interface to add additional members, remove members and upgrade existing members to VSX clusters. Many advanced cluster management, including Load Sharing definitions, require the command line.
This section describes how to create a new VSX cluster using the VSX Cluster Wizard. The wizard guides you through the following steps to configure a VSX cluster.
After completing the VSX Cluster Wizard, you can modify most cluster and member properties directly from SmartDashboard.
To create a new cluster:
If you are using Multi-Domain Security Management, open SmartDashboard from the Domain Management Server in which you are creating the cluster.
The General Properties page of the VSX Cluster Wizard opens.
The Cluster General Properties page contains basic identification properties for VSX clusters.
This window contains the following properties:
|
Note - All cluster members must use the type of platform, with the same specifications and configuration. |
The Virtual Systems Creation Templates allows you to select a Virtual System Creation Template that automatically applies predefined, default topology and routing definitions to Virtual Systems when they are first created. This feature ensures consistency among Virtual Systems and speeds up the provisioning process.
You always have the option of overriding the default creation template when creating or modifying a Virtual System
The available creation templates are as follows:
The VSX Cluster Members window defines the members of the new cluster. You must define at least two cluster members, and up to as many as eight members. You can add new members later.
To add a new cluster member:
The VSX Cluster Interfaces window lets you define physical interfaces as VLAN trunks. The list displayed contains all interfaces currently defined on the gateway machine or cluster.
To configure a VLAN trunk:
Select an interface to define it as a VLAN trunk. You can clear an interface to remove the VLAN trunk assignment.
|
Important - You cannot define the management interface as a VLAN trunk. To use a VLAN as the management interface, you must define the VLAN on the Security Gateway before you use SmartDashboard to create the VSX Gateway. |
If you selected the custom configuration option, the VSX Cluster Members window appears. In this window, you define the synchronization IP address for each member.
To configure the cluster members:
To use a VLAN as a synchronization interface:
fwkern.conffwha_monitor_all_vlan=1
The VSX Gateway Management page allows you to define several security policy rules that protect the cluster itself. This policy is installed automatically on the new VSX cluster.
|
Note - This policy applies only to traffic destined for the cluster. Traffic destined for Virtual Systems, other virtual devices, external networks, and internal networks is not affected by this policy. |
The security policy consists of predefined rules covering the following services:
For example, you may wish to allow UDP echo-request traffic in order to be able to ping cluster members from the management server.
Click New Source Object to define a new source.
For more about security policies, see the R76 Security Management Administration Guide.
To complete the VSX Cluster Wizard:
It can take several minutes to complete. A message appears indicating successful or unsuccessful completion of the process.
If the process ends unsuccessfully, click View Report to view the error messages. See to the troubleshooting steps for more information
Use the VSX Gateway Conversion wizard in SmartDashboard to convert a Gaia High Availability cluster of Security Gateways to a VSX cluster. The settings of each Security Gateway are applied to the VSX Gateway (VS0). For more about using the Conversion wizard, see sk79260.
You can only convert a cluster that uses the Gaia operating system.
|
Important - There is no loss of connectivity during the conversion process. You cannot use the conversion wizard to convert a Load Sharing cluster of Security Gateways. |
Once you create a cluster using the wizard, you can modify the topology and other parameters using the VSX Cluster Properties window. This window also allows you to configure many advanced features not available with the wizard.
To work with a VSX cluster definition, double-click on the cluster object in the SmartDashboard Network Object tree. The VSX Cluster Properties window opens, showing the General Properties page.
Most cluster objects and properties can be defined using the SmartDashboard GUI. Several definitions, however, require CLI commands, while others may be performed using either method.
A brief explanation for each of the definition pages follows. More detailed explanations for features that are not specific to VSX (NAT, IPS, VPN, etc.) are available in the online help or in the appropriate product Administration Guide.
See the General Properties page to view general properties and to activate Check Point products for use with this cluster and its members.
You can modify the following properties:
The Cluster Members page lets you view and modify several properties for individual cluster members, including IP addresses for members and the internal communication network. You can also view where cluster and member objects in the object database are used.
The Cluster Members page shows all the VSX cluster members on the VSX Gateway.
To edit a cluster member:
From the Cluster Member page, select a member and click Edit.
The Cluster Member Properties window opens. These are the settings that you can edit:
This window is only available if the Check Point VPN product is enabled on the General Properties page.
Click Where used to show information about the selected member in the objects database.
VSX creates an internal communication network and automatically assigns it an IP address and net mask from a predefined pool. You can change this IP address here if you have not yet defined a Virtual System. Although traffic from this address is never sent to any networks, you must ensure that this IP address is unique and not in use anywhere on your defined network.
You can enable or disable state synchronization in the ClusterXL window and choose options to track changes in the state of cluster members on this page. All other properties are ClusterXL configuration properties are disabled. You can modify the ClusterXL configuration using the vsx_util
The Creation Templates page displays the creation template used to create Virtual Systems. You can change from the current creation template to the Custom Configuration template and change the shared physical interface if the Shared Interface template is active.
You cannot change back from the Custom Configuration template once you have completed the definition and saved it to the configuration to cluster.
The Physical Interfaces page allows you to add or delete a physical interface on the VSX Gateway, and to define interfaces to be used as VLAN trunks.
The Synchronization window displays the state synchronization network. There are no configurable properties.
The Topology page contains interface and routing definitions.
The Interfaces section defines interfaces and links to devices. You can add new interfaces as well as delete and modify existing interfaces.
To add an interface:
The Interface Properties window opens.
Click Actions > Copy to Clipboard to copy the Interfaces table in CSV format.
To change an interface:
The Interface Properties window opens.
To delete an interface:
The Routes section of the Topology window defines routes between network devices, network addresses, and virtual devices. Some routes are defined automatically based on the interface definitions. You can add new routes as well as delete and change existing routes.
To add a default route to the routing table:
The Default Gateway window opens.
The default route is added to the routing table.
The Route Configuration window opens.
To add a new route to the routing table:
The Route Configuration window opens.
To change a route:
The Route Configuration window opens.
To delete a route:
A confirmation window opens.
Enable this option to allow VSX to automatically calculate the network topology based on interface and routing definitions (enabled by default). VSX creates automatic links, or connectivity cloud objects linked to existing internal or external networks.
The VPN Domain section in the Topology page defines the set of hosts that use a VPN tunnel to communicate with peer Virtual Systems.
Define a VPN Domain to include a virtual device as part of the VPN connection. The domain defines the Virtual System interfaces that are in the VPN. You can define a VPN Domain in different ways:
To specify the VPN domain:
The VPN Domain per Remote Access Community window opens.
The Set VPN Domain window opens.
The NAT > Advanced page lets you configure NAT rules for packets originating from a Virtual System.
To enable and configure NAT for a Virtual System:
or
The VSX Bridge Configuration page allows you to specify the loop detection algorithm when working in the Bridge mode.
Enable the Check Point ClusterXL option to enable the Active/Standby Bridge Mode loop detection algorithms contained in ClusterXL.
Enable the Standard Layer-2 Loop Detection Protocols to use standard loop detection protocols, such as STP or PVST+.
Cooperative Enforcement works with Check Point Endpoint Security servers. This feature utilizes the Endpoint Security server compliance capability to verify connections arriving from various hosts across the internal network. The Cooperative Enforcement window contains several configuration properties for defining this feature. For more information, please refer to the online help and the R76 Firewall Administration Guide.
You can change the cluster management IP address and/or subnet by executing the vsx_util change_mgmt_ip and vsx_util change_mgmt_subnet commands.
You can change the internal communication network IP address by using the vsx_util change_private_net command.
This section presents procedures for adding and deleting cluster members, as well as for upgrading existing cluster members to VSX.
|
Important - Verify that no other administrators are connected to the management server before proceeding. The |
To add a new member to an existing cluster:
vsx_util add_member Note - In a Multi-Domain Security Management environment, this operation will skip any Domain Management Servers locked by an administrator. If this should occur, run the operation again for the relevant Domain Management Servers once they become available.
vsx_util add_member_reconfNote - In a Multi-Domain Security Management environment, the operation will skip any Domain Management Servers locked by an administrator. If this should occur, run the operation again for the relevant Domain Management Servers when they become available.
vsx_util vsls
|
Important - Verify that no other administrators are connected to the management server before proceeding. The |
You perform this operation using the management server command line. It is strongly recommended that you back up the database prior to removing a member.
To remove a member from a cluster:
vsx_util remove_memberyyremove member operation finished successfully
|
Note - In a Multi-Domain Security Management environment, the operation will skip any Domain Management Servers locked by an administrator. If this should occur, run the operation again for the relevant Domain Management Servers when they become available. |
This section describes the procedures for upgrading cluster members that were initially installed using an earlier version of VSX. You perform the upgrade process using the vsx_util upgradevsx_util reconfigure
|
Important - Verify that no other administrators are connected to the management server before proceeding. The |
Performing the following steps to upgrade the cluster and its members:
vsx_util upgradeEnter the following information when prompted:
Finished upgrading/database saved successfullyNote - In a Multi-Domain Security Management environment, the operation will skip any Domain Management Servers locked by an administrator. If this should occur, run the operation again for the relevant Domain Management Servers when they become available.
vsx_util reconfigureThis action installs the existing security policy and configuration on the newly upgraded members.
Finished upgrading/database saved successfullyNote - In a Multi-Domain Security Management environment, the operation will skip any Domain Management Servers locked by an administrator. If this should occur, run the operation again for the relevant Domain Management Servers when they become available.
vsx_util upgradevsx_util reconfigureFor example, for a deployment with two clusters, each cluster having three members, run vsx_util upgradevsx_util reconfigure
vsx_util upgradevsx_util reconfigure vsx_util upgradevsx_util reconfigurevsx_util reconfigureThis section presents procedures for converting cluster members from one cluster type (High Availability or VSLS) to the other. Changing the cluster mode involves the use of the vsx_util convert_cluster
Do these procedures to convert a cluster from VSLS to High Availability:
To redistribute all active Virtual Systems to one member:
vsx_util vslsWhen the convert_cluster
To convert existing cluster members to the VSX Gateway High Availability mode:
cpconfig cpstop cpstart To convert the cluster to High Availability:
vsx_util convert_clustercpstop cpstart To convert an existing High Availability cluster to VSLS Load Sharing:
cpconfig cpstop cpstart vsx_util convert_clusterLSy
|
Note - You cannot convert a VSX cluster to the VSLS mode if it contains Virtual Systems in the Active/Active Bridge mode or Virtual Routers. |
The following screen printout shows an example of the output from the vsx_util convert_cluster
vsx_util convert_cluster ************************************************* Note: the operation you are about to perform changes the information in the ************************************************* Enter Security Management Server/main Domain Management Server IP address (Hit 'ENTER' for 'localhost'): Enter Administrator Name: Enter Administrator Password: Enter VSX cluster object name: Enter desired ClusterXL mode: HA-High Availability, LS-Load Sharing All modules must be in the 'Per VS State' mode to conclude this operation When converting a cluster, there are two options for distributing the existing 1. Distribute all Virtual Systems so that each cluster member is equally loaded. 2. Set all Virtual Systems as Active on the same cluster member. After converting the cluster, the command vsx_util redistribute_vsls may be Enter distribution option (1-2) [1]: 1 Converting the cluster to ClusterXL Load Sharing mode... The cluster was successfully converted to ClusterXL Load Sharing mode Installing new policy... ... Policy installation finished successfully. |
VSX Gateway High Availability is the default cluster configuration. If Load Sharing (VSLS) is not active, a cluster functions in the VSX Gateway High Availability mode. All members of a cluster must be configured to use the same clustering mode.
To configure members for VSX Gateway High Availability:
In the Gaia First Time Configuration Wizard Products page, select ClusterXL.
This section presents the various procedures for configuring VSLS deployments. You use the vsx_util vsls to perform various VSLS configurations tasks.
To start vsx_util vsls:
In order to use VSLS for VSX, you must first activate the Per Virtual System State mode on each cluster member. You can then create a Load Sharing cluster, either by creating a new cluster object, or by converting an existing High Availability cluster to Load Sharing mode. After completing this process, you can modify Virtual Systems as required.
The Per Virtual System State mode enables active Virtual Systems to be placed on different cluster members, and for Virtual System-specific failover. This setting is mandatory for VSLS. On each cluster member, do the following:
|
Note - The following virtual devices are not supported when the Per Virtual System state is enabled:
|
cpconfigEnable Check Point Per Virtual System Statey Would you like to enable Per Virtual System state?To create a new VSLS cluster:
The VSX Cluster Wizard opens.
You use the vsx_util vsls command to perform various Virtual System Load Sharing configuration tasks, including:
To work with the vsx_util vsls command:
Enter Administrator Name: aa Enter Administrator Password: Enter VSX cluster object name: vsx VS Load Sharing - Menu ________________________________ 1. Display current VS Load sharing configuration 2. Distribute all Virtual Systems so that each cluster member is equally loaded 3. Set all VSs active on one member 4. Manually set priority and weight 5. Import configuration from a file 6. Export configuration to a file 7. Exit Enter redistribution option (1-7) [1]: |
The primary advantage of VSLS is the ability to distribute active, standby and backup Virtual Systems amongst cluster members in order to maximize throughput and user response time. You can choose to distribute Virtual Systems according to one of the following options:
To distribute Virtual Systems for equal member loading:
The process update process may take several minutes or longer to complete, depending on the quantity of Virtual Systems and cluster members.
The process update process may take several minutes or longer to complete, depending on the quantity of Virtual Systems and cluster members.
You can modify these settings in one of two ways:
To automatically assign weights to all Virtual Systems:
The process update process may take several minutes or longer to complete, depending on the quantity of Virtual Systems and cluster members.
To manually assign priorities and weights for individual Virtual Systems:
The process update process may take several minutes or longer to complete, depending on the quantity of Virtual Systems and cluster members.
To view the current VSLS status and Virtual System distribution amongst members, select "1. Display current VS Load Sharing configuration" from the VSLS menu. The output is similar to the below example"
----+---------+-----------+-----------+-----------+--------+ VSID| VS name | gw150 | gw151 | gw152 | Weight | ----+---------+-----------+-----------+-----------+--------+ 2 | vs1 | 0 | 1 | 2 | 10 | 3 | vs2 | 2 | 0 | 1 | 10 | 4 | vs3 | 1 | 2 | 0 | 10 | 5 | vs5 | 0 | 2 | 1 | 10 | 6 | vs4 | 1 | 0 | 2 | 10 | ----+---------+-----------+-----------+-----------+--------+ Total weight | 20 | 20 | 10 | 50 | ----+---------+-----------+-----------+-----------+--------+ Legend: 0 - Highest priority 1 - Next priority 2 - Lowest priority |
Virtual System priority refers to a preference regarding which member hosts a Virtual System's active, standby, and backup states. This preference is expressed as an integer value.
Priority |
Definition |
|---|---|
0 |
Highest priority, indicating the member designated to host the Virtual System active state. |
1 |
Second highest priority, indicating the member designated to host the Virtual System standby state. |
> 1 |
Lower priorities, indicating members designated to host a Virtual System's backup state. The cluster member assigned priority 2 will be the first to switch the Virtual System to the Standby state in the event of a failure of either the Active or Standby Virtual System. A cluster member assigned priority 3 would be the next in line to come online in the event of another failure. |
Each Virtual System is assigned a weight factor, which indicates its traffic volume relative to the total traffic volume (the sum of all weight factors) on a given cluster member. VSX uses the weight factor to determine the most efficient distribution of Virtual Systems amongst cluster members. System resource allocation is not affected by the weight factor, nor does VSX take weight into consideration for any other purpose.
By default, all Virtual Systems are assigned an equal weight factor of 10.
When working with large scale VSLS deployments consisting of many Virtual Systems, multiple cluster members, using the vsx_util command to perform configuration tasks can be quite time consuming. To allow administrators to efficiently configure such deployments, VSX supports uploading VSLS configuration files containing configuration information for all Virtual Systems directly to management servers and cluster members.
This capability offers the following advantages:
VSLS configuration files are comma separated value (CSV) files that are editable using a text editor or another applications, such as Microsoft Excel. You can use the configuration file to rapidly change the weight and cluster member priority for each Virtual Systems in the list.
|
Note - You cannot use the VSLS configuration file to add or remove cluster members. You must use the appropriate vsx_util commands to accomplish this. You can use the VSLS configuration file to change member priorities for Virtual Systems after adding or removing a member. |
The VSLS configuration file is a comma separated value (CSV) text file that contains configuration settings for all Virtual Systems controlled by a management server. All lines preceded by the # symbol are comments and are not imported into the management database.
# Check Point VSX - VS Load Sharing configuration file # # Administrator : aa # SmartCenter/Main Domain Management Server : 192.168.50.160 # Generated on : Thu Jul 23 13:08:42 2009 # # # # VSID, Weight, Active member, Standby member, Backup member #1 # Virtual System name: vs1 2,10,gw150,gw151,gw152 # Virtual System name: vs2 3,10,gw151,gw152,gw150 # Virtual System name: vs3 4,10,gw152,gw150,gw151 # Virtual System name: vs4 6,10,gw151,gw150,gw152 # Virtual System name: vs5 5,10,gw150,gw152,gw151 |
The configuration file contains one line for each Virtual System, consisting of the following data as shown below:
Each line contain the VSID, the weight assigned the Virtual System, one primary member and one standby member. Additional backup members are listed following the standby member.
The most common way to use VSLS configuration files is to initially define your cluster environment and Virtual Systems using SmartDashboard.
To export a VSLS configuration to a text file:
/home/admin/MyConfiguration
You can insert the following commands in the VSLS Configuration file to display audit trail information while validating and processing data. Each of the commands act as a toggle, whereby the first occurrence of a command enables the action and the next occurrence disables it. These options his allow you to efficiently debug very long configuration files by displaying or logging only suspicious sections of the data.
Command |
Action |
|---|---|
!comments |
Sequentially displays comment lines (those preceded with the '#' character) contained in the configuration file. You can insert comments into the configuration file to indicate which Virtual Systems are currently being processed or to provide status information as the parser processes the data. |
!verbose |
Displays whether or not each data line has been successfully verified and the configuration parameters for each Virtual System. |
!log |
Saves !comments and !verbose information in the vsx_util.log file. |
To import a VSLS configuration from a text file:
/home/admin/MyConfiguration
During the import process, the parser reads the configuration file and attempts to validate the contents. Errors are displayed on the screen together with the offending line number. If either the !comments or !verbose processing options are enabled, the appropriate information appears on the screen.
The process update process may take several minutes or longer to complete, depending on the quantity of Virtual Systems, Domain Management Servers and cluster members.
This section explains configurations and procedures for Virtual Systems in Bridge mode. With native layer-2 bridging instead of IP routing, you can add Virtual Systems without affecting the existing IP structure.
When in Bridge mode, Virtual System interfaces do not require IP addresses. You can assign an IP address to the Virtual System itself (not the interfaces) to enable layer-3 monitoring. This feature enhances network fault detection.
VSX supports these Bridge mode models:
This section presents the procedures for enabling and configuring the STP Bridge mode for Virtual Systems and VSX Gateways.
The same procedures are applicable for a VSX cluster for PVST + Load Sharing.
Define and configure the Spanning Tree structure according to your network requirements. (For PVST + Load Sharing, configure the structure for each VLAN.)
See your hardware documentation for the specific procedures for your network deployment.
When you create a new VSX Gateway to use as a cluster member, configure it as a cluster member when you first define the gateway.
cpconfigWould you like to install a Check Point clustering product ynTo enable the Active/Active Bridge mode for existing cluster members:
cpconfig (If a numerical value appears here, cluster membership has already been enabled).
To enable the Active/Active Bridge mode for a cluster:
The VSX Cluster Properties window opens.
To configure a Virtual System to use bridge mode, define it as a Virtual System in bridge mode when you first create it. You cannot reconfigure a non-Bridge mode Virtual System to use bridge mode later.
Define and configure the Spanning Tree structure for each VLAN according to your network deployment. Please refer to your network hardware documentation for specific procedures.
To configure a VSX cluster for PVST + Load Sharing, perform the procedures described in the STP Bridge Mode section.
This section presents the procedures for enabling and configuring the Active/Standby Bridge Mode for Virtual Systems and VSX Gateways.
When you create a new cluster member, enable the cluster options during the first configuration.
cpconfigyTo enable the Active/Standby Bridge Mode on existing Virtual Systems:
cpconfig To enable the Active/Standby Bridge Mode for a cluster:
The VSX Cluster Properties window opens.
The Active/Standby Bridge Mode loop detection algorithms in ClusterXL is enabled.
To configure a Virtual System to use bridge mode, define it as such when you first create the object.
To configure a Virtual System for the Active/Standby Bridge Mode:
The Virtual System Network Configuration window opens.
The IP address must be unique and on the same subnet as the protected network.
This section presents several advanced cluster scenarios and procedures for their configuration.
The recommended cluster architecture contains interfaces connect to a Layer-2 segment that is isolated from other clusters. When configuring a cluster with only two members, you should connect the secured interfaces of the sync network using a crossover cable.
However, in a deployment where multiple clusters need to connect to the same Layer-2 segment, the same MAC address may be used by more than one cluster for Cluster Control Protocol (CCP) communication. This may direct traffic to the incorrect cluster. In this case you will need to modify the source MAC address(es) of the clusters.
This section describes how source MAC addresses are assigned, and explains how to change them. This procedure applies to both ClusterXL and OPSEC certified clustering products using the High Availability mode.
Cluster members use CCP to communicate with each other. In order to distinguish CCP packets from ordinary network traffic, CCP packets are given a unique source MAC address.
Default Value Of Fifth Byte |
Purpose |
|---|---|
|
CCP traffic |
|
Forwarding layer traffic |
When multiple clusters are connected to the same Layer-2 segment, setting a unique value to the fifth byte of the MAC source address of each cluster allows them to coexist on the same Layer-2 segment.
To change a cluster's MAC source address, run these commands on each cluster member:
fw ctl set int fwha_mac_magic <value>
fw ctl set int fwha_mac_forward_magic <value>
Parameter |
Default value |
|---|---|
|
|
|
|
Use any value, as long as the two gateway configuration parameters are different. To avoid confusion, do not use the value 0x00.
You can configure the above parameters to persist following reboot.
fwkern.conf$FWDIR/boot/modules/Parameter=<value in hex>By default, ClusterXL only monitors two VLANS for failure detection and failover. These are the highest and lowest VLAN tags defined for a given interface.
For example, if the topology for interface eth1 includes several VLAN tags in the range of eth1.10 to eth1.50, ClusterXL only monitors VLANs eth1.10 and eth1.50 for failure. Failures on any of the other VLANs are not detected in the default configuration.
|
Note - The command line option |
When both the highest and lowest VLANs fail, all the VLANs are considered down, and a failover occurs. This means that if a VLAN which is not listed as the highest or lowest goes down, the trunk is still considered "up", and no failover occurs.
There are instances in which it would be advantageous to monitor all the VLANs in the trunk, not just the highest and lowest, and initiate a failover when any one of the VLANs goes down.
To enable monitoring of all VLANs, enable the fwha_monitor_all_vlan$FWDIR/boot/modules/fwkern.conffwha_monitor_all_vlan=1
|
Note - Monitoring all VLANS is enabled automatically when the Per VLAN state option is enabled. |
The default ClusterXL Control Protocol transport mode is multicast. Use the cphaconf set_ccp
To enable broadcast or multicast mode:
cphaconf set_ccp {broadcast|multicast}