- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi!
Im trying to find information about the new feature starting from R80.40:
I cannot find detailed information about this setting in the R80.40 VSX documentation except that the behaviour can be changed with: vsx_util vsls - 5. Toggle VSLS mode between Active Up and Primary Up"
Anyone who knows more about this or where I can find the information?
yeah, it was always a bummer during upgrades 🙂 or even regular restarts when you wanted to keep it on a specific cluster member, so you would always have to keep playing with vsx_util
You're spot on - documentation does not exist to explain it 🙂
Wild guess: primary up would mean higher priority would always be active if it's available, whereas active up would keep current active member even though member with higher priority becomes available.
Or in more practical example, say if you are upgrading VSX1 that has higher priority then after upgrade VSX2 will remain active even it has lower priority. Just like regular cluster setting
That was my guess too. The documentation says:
When the failed VSX Cluster Member or Virtual System comes back online, the system returns to its original Load Sharing configuration.
So that would be Primary Up mode, and Active Up (which is not mentioned) is that it stays on the current host.
Nice feature by the way! 🙂
yeah, it was always a bummer during upgrades 🙂 or even regular restarts when you wanted to keep it on a specific cluster member, so you would always have to keep playing with vsx_util
Hey,
I am failing to understand the exact behaviour here. Is this only for VS0 as indicated here:
VSX cluster questions: Failover & updatable objec... - Check Point CheckMates
or all VS ? and if it is for all VS - what does the priority setting do here? Only apply for vsls redistribute?
I am trying to accomplish that the cluster does NOT failback to the rebooted node. This has only caused issues for us.
Another question, does this really bring down all virtual systems ? have you seen it on other clusters or was it a one of and for how long did you see it?
Thanks!
Henrik
Hi. The mode is applied on all VSes. So if you chose "Active UP" it will maintain currently active VS and will ignore any priority / weight settings. Indeed this should help you avoiding failback after reboots.
Changing the mode did bring down all VSes in our case. But it was only one cluster in our case. How long - I don't remember exactly but lets say outage was roughly 5mins before all settled again.
Regards, Kaspars
A small but important update! We tried it in production.. please remember to book an outage window if you are switching modes! As this is what happened 😲😱
First you will be asked to use option "6" after changing modes which does not make sense at all:
But then menu structure changes from 8 items to 9 and option "6" actually makes sense:
Now! Running it will cause multiple VS failovers and eventually all VSes will go down briefly as shown in the first screenshot
Just an update - I was playing with this in the lab using R81.20. This issue of all members going down during the mode change did not happen there. I believe the mechanism by which they change the mode is better now and will not cause an outage.
Hello all,
I have a question about failover status after vsx member is recovered.
In this example there is a cluster of 2 members (Active-Standby) in vsls "Primary UP" mode.
vsx1 priority 0 (active) , vsx2 priority 1 (standby)
1) via vsx_util vsl (opt.3) move all VS from currently Active (vsx1) to Standby (vsx2).
This causes failover of every VS and their the traffic, and the "active" is the vsx2 now
2) reboot vsx1
3) -that's the unclear point-
After vsx1 reboot, will it be active automatically, and cause failover of the traffic from vsx2, (because of vsls "Primary UP" mode),
or there will not be any traffic failover, because it was configured in vsx_util (step 1 -above), and as per documentation "the system returns to its original Load Sharing configuration"?
After reboot all VSes will return to VSX1 as it has higher priority and "Primary-UP" mode.
"Active-UP" mode would have preserved VSX2 as active after reboot.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 28 | |
| 15 | |
| 13 | |
| 13 | |
| 12 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 5 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY