Using Virtual Switches in a VSX Cluster
In a VSX
Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing., Virtual Switches are also clustered for redundancy and are defined as Active/Active.
By means of the ClusterXL Control Protocol (CCP), the physical interface connected to the Virtual Switch Virtual Device on a VSX Gateway or VSX Cluster Member that functions as a physical switch. Acronym: VSW. is monitored. In the event of a failover, all Virtual Systems on Standby become Active, and send Gratuitous ARP Requests from the warp interface between the Virtual System Virtual Device on a VSX Gateway or VSX Cluster Member that implements the functionality of a Security Gateway. Acronym: VS. and the Virtual Switch.
|
Item |
Description |
|
1 |
Active VSX Cluster Member |
|
2 |
Standby VSX Cluster Member |
|
3 |
Virtual Switch Cluster |
|
4 |
Active Virtual Switch |
|
5 |
Virtual System 1 |
|
|
Physical Link |
|
|
In the above figure, a simplified VSX Cluster contains two VSX Cluster Members, one Active, and the other Standby. The Virtual Switches within each VSX Cluster are Active/Active. When the physical interface connected to either Virtual Switch fails to respond, a failover occurs.
Working with VSLS for Scalable Platforms
VSLS is a Virtual System Load Sharing VSX Cluster technology that assigns Virtual System traffic to different Active Cluster Members. Acronym: VSLS. solution for the Scalable Platforms that uses both Standby Chassis to handle traffic. Each Virtual System works as an independent cluster. For each Virtual System, one Standby Chassis is Active and the other Standby Chassis becomes the Standby. The selection of the Active Chassis is based on interface availability, SGM availability, and Virtual System stability.
A Virtual System in the DOWN state fails over to the Standby Virtual System in the other Standby Chassis. By default, a Virtual System in the DOWN state does not put the SGM in the DOWN state. Because of this, there is no effect on other Virtual System states.
The SGM continues to receive traffic from the SSM. This behavior is different from Standby Chassis High Availability, where a Virtual System in the DOWN state causes the SGM to go DOWN.
Notes:
-
If VS0 goes DOWN, its related SGM also goes DOWN.
To change the VSLS behavior, run in gClish:
> g_update_conf_file fwkern.conf fwha_mbs_vsls_only_vs0_decide_state=0
A Virtual System in the DOWN state causes the SGM to go DOWN.Reboot the Standby Chassis.
This behavior is now the same as for standard Standby Chassis High Availability.
-
When an SGM contains a DOWN Virtual System, the SMO
See "SMO". and Standby Chassis Monitor tasks move to a different valid SGM. Because these tasks can move to a different SGM, connections to the Virtual Systems can become disconnected. -
We recommend that you work with UIPC. This is because the UIPC task does not move to a different SGM.
Activating Standby Chassis VSLS
To use Standby Chassis VSLS features, run:
set chassis high-availability mode 3
Note- This command can cause Standby Chassis failover.
Selecting the Active Chassis for a Virtual System
VSLS dynamically assigns an Active Chassis to each Virtual System based on criteria in this order of priority:
-
Availability of functional interfaces for the Virtual System
VSLS selects the Standby Chassis with the most connected interfaces to be the Active Chassis.
-
Availability of UP SGMs
If both Standby Chassis have the same number of connected interfaces, VSLS uses this ratio to select the Active Chassis:
SGM Ratio = Fewest_UP_SGMS/Most_UP_SGMSIf the SGM Ratio is less than the predefined threshold (default=50%), VSLS selects the Standby Chassis with the most available SGMs. If the SGM Ratio is greater or equal to the threshold, VSLS does not select an Active Chassis based on SGM availability.
Example:
Standby Chassis1 has two UP SGMs and Standby Chassis 2 has five UP SGMS. The ratio is 2/5 (40%), which is less that the default threshold of 50%. VSLS selects Standby Chassis 2 as the Primary Standby Chassis.
-
Virtual System with a problem
When a Virtual System fails, VSLS automatically fails over to the related Virtual System on the other Standby Chassis, which becomes the Active Chassis.
-
Primary Standby Chassis
If none of the above criteria causes VSLS to select an Active Chassis, the Primary Standby Chassis automatically becomes the Active Chassis.
To change the SGM threshold value, run:> set chassis vsls sgm_ratio <percent_value>
Virtual System Failover
With VSLS, a Virtual System can fail over to the Standby Chassis independently of the other Virtual Systems. When VSLS selects a different Standby Chassis for a Virtual System based on the selection criteria, only that Virtual System fails over. There is no effect on the other Virtual Systems.
Virtual System failover works the same way as a regular Layer2/Layer3 failover. The Virtual System sends GARP/NDS packets in Layer3, and MAC learning packets in Layer2.
Example:
For VS1, Standby Chassis2 is both the Active and the Primary Standby Chassis. If an interface used by VS1 on Standby Chassis2 is disconnected, VS1 fails over to Standby Chassis1 based on the dynamic selection procedure. When the port is reconnected, VS1 fails back to Standby Chassis2.
SGM Failover
When an SGM fails, it no longer receives traffic. When one Virtual System fails on an SGM, this Virtual System can do a Virtual System Standby Chassis Failover. If a Virtual System Standby Chassis failover does not occur, the failed Virtual System on the SGM continues to receive traffic.
Configuring the VSLS Primary Standby Chassis
When you create a new Virtual System, VSLS automatically assigns a Primary Standby Chassis based on the system default. You can change the default Primary Standby Chassis when it is necessary. When you change the default Primary Standby Chassis, it changes for all Virtual Systems that do not have a manually defined Primary Standby Chassis. This can cause Virtual Systems to failover to a different Active Chassis.
You can manually define the Primary Standby Chassis for specified Virtual Systems. Manually defined Virtual Systems do not change their Primary Standby Chassis when you change the default Primary Standby Chassis.
To change the system default Primary Standby Chassis:
-
Change the context to VS0. Run:
> set virtual-system 0 -
Run:
> set chassis high-availability vs chassis_priority <option><option>is an integer between 0 and 2.0 - Automatic (VSLS automatically assigns the Primary Standby Chassis)
1 - Define Standby Chassis1 as the default Primary Standby Chassis
2 - Define Standby Chassis2 as the default Primary Standby Chassis
To manually define a Primary Standby Chassis for a Virtual System:
-
Go to the Virtual System context to be changed. Run:
> set virtual-system <vsid> -
Run:
> set chassis high-availability vs chassis_priority <option><option>is an integer between 0 and 20 - Use the system default Primary Standby Chassis
1 - Define Standby Chassis1 as the Primary Standby Chassis
2 - Define Standby Chassis2 as the Primary Standby Chassis
To show the Primary Standby Chassis for all Virtual Systems:
Run:> show configuration vsls
Example output:
------------------------------------------------- | Default Mode: Automatic | | Virtual Systems: 10 |------------------------------------------------- | VS | VS-Name | Standby Chassis 1 | Standby Chassis 2 | ------------------------------------------------- | 0 | 61000-VSLS | Default | | | 1 | VS1 | Manual | | | 2 | VS2 | Default | | | 3 | VS3 | | Default | | 4 | VS4 | Default | | | 5 | VS5 | | Default | | 6 | VS6 | Default | | | 7 | VS7 | | Default | | 8 | VS8 | Default | | | 9 | VS9 | | Manual | ------------------------------------------------- | Total: | 6 | 4 | ------------------------------------------------- |
This example shows that:
-
The default Primary Standby Chassis Mode is Automatic (0)
-
The deployment has 10 Virtual Systems including VS0
-
VS1 and VS9 have manually assigned Primary Standby Chassis (Standby Chassis1 and Standby Chassis2 respectively)
-
All others use the default Primary Standby Chassis, which are assigned to different Standby Chassis to effectively distribute the traffic load
-
Standby Chassis1 is configured as the Primary Standby Chassis for VS0, VS1, VS2, VS4, VS6, and VS8
-
Standby Chassis2 is configured as the Primary Standby Chassis for VS3, VS5, VS7, and VS9
Monitoring VSLS
Using 'asg stat'
Use the asg stat command without arguments to see general VSX and system information. You can run this command from Gaia gClish The name of the global command line shell in Check Point Gaia operating system for Security Gateway Modules. Commands you run in this shell apply to all Security Gateway Module in the Security Group. or Expert Mode The name of the elevated command line shell that gives full system root permissions in the Check Point Gaia operating system..
Example output:
-------------------------------------------------------------------------- |
The output shows that:
-
System is running in VSLS Mode
-
System has 10 Virtual Systems configured, including VS0
-
System has five SGMs in UP state
-
All SGMs on Standby Chassis1 are UP
-
Only one SGM on Standby Chassis 2 is UP
Using 'asg stat vs all'
Use the asg stat vs all command to see which Virtual System are Active on each Standby Chassis and the status of their health. You can run this command from gClish or Expert Mode.
Example output:
Output: VSLS----------------------------------------------------------------------- | VSX System Status - 61000 | ----------------------------------------------------------------------- | Standby Chassis Mode | VSLS | | Up time | 4 days, 16:05:08 hours | | SGMs | 1 / 3 (!) || Virtual Systems | 4 || Version | R76SP.40 (Build Number 2) |----------------------------------------------------------------------- | VSID | VS Type & Name | Standby Chassis 1 | Standby Chassis 2 | Health | ----------------------------------------------------------------------- | 0 | V 61000-VSLS | DOWN (P) | ACTIVE | Problem | | 1 | S VS1 | DOWN | ACTIVE (P) | Problem | | 2 | S VS2 | DOWN (P) | ACTIVE | Problem | ----------------------------------------------------------------------- | Active Virtual Systems | 0 | 3 | |----------------------------------------------------------------------- | Errors: | | VSID's not on Primary chassis: 0 2 | ----------------------------------------------------------------------- | Synchronization | | Within chassis: Enabled (Default) | | Between chassis: Disabled (Auto) | | Reason: Standby Chassis states doesn't allow Sync between chassis || Exception Rules: (Default) | -----------------------------------------------------------------------
|
Using 'asg stat vs'
Use the asg stat vs command to show status information, SGM states, and problems for a specified Virtual System. You can run this command from gclish or Expert Mode. Select the Virtual System context before you run this command.
In gclish, run:
> asg stat vs |
In Expert Mode, run:
# vsenv <context> # asg stat vs |
Example output:
-------------------------------------------------------------------------- | VSX System Status - 61000 | -------------------------------------------------------------------------- | VS ID 1 | | VS Name VS1 | | Standby Chassis Mode VSLS | | FW Policy Date 09Jun14 19:12 | -------------------------------------------------------------------------- | Standby Chassis 1 (Primary) STANDBY |-------------------------------------------------------------------------- | SGM ID State Process Health || 1 DOWN Inactive fwk | | 2 (local) UP Enforcing Security OK | | 3 UP Enforcing Security OK | | 4 UP Enforcing Security OK | -------------------------------------------------------------------------- | Standby Chassis 2 ACTIVE |-------------------------------------------------------------------------- | SGM ID State Process Health || 1 UP Enforcing Security OK | | 2 UP Enforcing Security OK | | 3 UP Enforcing Security OK | | 4 UP Enforcing Security OK | -------------------------------------------------------------------------- | Active Chassis: 2 | | Primary chassis has a problem. Secondary chassis health is better. | -------------------------------------------------------------------------- | Standby Chassis 1 Standby Chassis 2 | | Ports 1 / 1 1 / 1 | | Bonds 0 / 0 0 / 0 | | FWKs 3 / 4 4 / 4 | | SGMs 4 / 4 4 / 4 |-------------------------------------------------------------------------- |
The example above shows:
-
VS1 on Standby Chassis1- SGM1 is DOWN.
-
The Primary Standby Chassis for this Virtual System (Standby Chassis1) has a problem with the Firewall, but is otherwise working properly.
-
VS1 failed over to Standby Chassis2, which is not the defined Primary Standby Chassis for this Virtual System.
-
All other SGMs are working properly.
SGM health status:
-
OK- This SGM does not have problems.
-
SGM- The SGM has a problem.
-
fwk- The Firewall kernel has a problem.
-
Policy- The policy date for this SGM is different from the Firewall policy date.
-
Interface- The number of interfaces on this SGM is different from the related SGM on the other Standby Chassis.
-
Problem- This SGM has one or more problems.
-
Pnote- This SGM has a problem that generated a pnote.
The bottom section shows the Active Chassis and the reason why the Primary Standby Chassis is not Active, if applicable. Possible reasons:
-
Primary Standby Chassis health is good.
-
Primary Standby Chassis has a problem. Secondary Standby Chassis health is better.
-
Primary Standby Chassis is above Active SGM threshold.
-
Primary Standby Chassis is below Active SGM threshold.
-
Both Standby Chassis have fwk problems. Continue using the Primary Standby Chassis.
-
Both Standby Chassis have fwk problems. Primary Standby Chassis health is better.
-
Both Standby Chassis have fwk problems. Secondary Standby Chassis health is better.
-
Both Standby Chassis have interface problems. Continue using the Primary Standby Chassis.
-
Both Standby Chassis have interface problems. Primary Standby Chassis health is better.
-
Both Standby Chassis have interface problems. Secondary Standby Chassis health is better.
-
Both Standby Chassis have problems. Continue using the Primary Standby Chassis.
-
Both Standby Chassis have problems. Secondary Standby Chassis health is better.
Using SNMP
SNMP information for VSLS is located in:
|
|
VSLS SNMP monitors:
-
SGM ratio threshold value
-
System Primary Standby Chassis
-
Active Chassis for each Virtual System
-
Primary Standby Chassis for each Virtual System
-
Number of configured interfaces for each Virtual System
-
Number of UP interfaces for each Virtual System
-
Number of working FWK instances for each Virtual System
-
Total number of FWK instances for each Virtual System
SNMP for VSLS supports these modes:
-
Default - SNMP collects data from all SGMs for all Virtual Systems
-
Virtual Systems - SNMP monitors each Virtual System separately