- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
Watch HereWhen the Agents Attack
A Live Look at Agentic Exposure Validation
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
I am looking to upgrade my VSX Cluster running 2 Virtual Systems from R80.10 to R80.40..i went through the following guide.
My query is that here it is not mentioned when the cluster member will be switched..Suppose i have 2 members in Active/Standby..i upgraded the Standby member to R80.40.. now for first member do i do a manual failover or it happens automatically in once MVC is switched on ?
Also, the policy to be installed after each member upgrades..is it only Cluster object policy or VS policy as well ?
Secondly..
at the bottom of this link a note states..
When Cluster Members of different versions are on the same network, Cluster Members of the new (upgraded) version remain in the state Ready, and Cluster Members of the previous version remain in state Active Attention.
Cluster Members in the state Ready do not process traffic and do not synchronize with other Cluster Members.
this is the condition before switching on MVC and will change once MVC is switched on.. is my understanding correct ?
The method described after that to remove the cables Physically and all that ..is it for the scenario where only one member is upgraded to test the latest version ?
sorry for the long post.. any help is appriciated.
The way I understand the documentation anyway, when you upgrade one cluster member to R80.40, the members on earlier versions will not properly recognize the upgraded member.
Once you enable the MVC mechanism, the other members will recognize it and start syncing connections.
I don't believe the failover occurs until you force it (either by upgrading or disconnecting the other members).
@PhoneBoy is totally correct.
Before you turn MVC on, upgraded member will be in READY state. Once MVC is turned ON, members will synchronise and cluster will appear in "normal" state ACTIVE/STANDBY.
There is no automatic failover. Depending on your cluster type (VSLS or HA) or you may chose own approach. On our VSLS VSX we did fail over one VS at a time by clusterXL_admin down on a specific VS. This way upgrade is extremely controlled. With HA cluster you of course will fail over all at once. But in principle we use the same clusterXL_admin down command on VS0 only
I do suggest to check your connections tables on both members before cutover - for some reason on our HA VSX cluster large chunk of connections was no synchronised. Still have no explanation to as why. What "saved" us was the fact the we allow"out of state" connections during upgrades. So technically no ongoing connections will be dropped.
One thing that it is missing from upgrade documents is turning off MVC after upgrade! It did byte us on the backside when we performed rollback to R80.30, created quite a mess..
Below are two articles I wrote about our VSX upgrade experience, you might want to read just in case to avoid same problems potentially
The way I understand the documentation anyway, when you upgrade one cluster member to R80.40, the members on earlier versions will not properly recognize the upgraded member.
Once you enable the MVC mechanism, the other members will recognize it and start syncing connections.
I don't believe the failover occurs until you force it (either by upgrading or disconnecting the other members).
@PhoneBoy is totally correct.
Before you turn MVC on, upgraded member will be in READY state. Once MVC is turned ON, members will synchronise and cluster will appear in "normal" state ACTIVE/STANDBY.
There is no automatic failover. Depending on your cluster type (VSLS or HA) or you may chose own approach. On our VSLS VSX we did fail over one VS at a time by clusterXL_admin down on a specific VS. This way upgrade is extremely controlled. With HA cluster you of course will fail over all at once. But in principle we use the same clusterXL_admin down command on VS0 only
I do suggest to check your connections tables on both members before cutover - for some reason on our HA VSX cluster large chunk of connections was no synchronised. Still have no explanation to as why. What "saved" us was the fact the we allow"out of state" connections during upgrades. So technically no ongoing connections will be dropped.
One thing that it is missing from upgrade documents is turning off MVC after upgrade! It did byte us on the backside when we performed rollback to R80.30, created quite a mess..
Below are two articles I wrote about our VSX upgrade experience, you might want to read just in case to avoid same problems potentially
Thank you for the detailed explanation..very useful
I just having a hard time contemplating the note section at the bottom of
Why will there be any need to physically remove cables , shut interfaces etc when the system will auto correct itself once MVC is switched on
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 13 | |
| 12 | |
| 9 | |
| 7 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Thu 09 Jul 2026 @ 10:00 AM (CEST)
Schutz souveräner Workloads: Check Point & die AWS European Sovereign CloudThu 09 Jul 2026 @ 11:00 AM (CEST)
The Cloud Architects Series: Check Point Edge Protection SD-WAN & SASEThu 09 Jul 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #9 - What's New with Check Point Email SecurityFri 10 Jul 2026 @ 11:00 AM (IDT)
CheckMates Live Netherlands - Sessie 48: Nieuwe Check Point Workspace SecurityTue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 09 Jul 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #9 - What's New with Check Point Email SecurityFri 10 Jul 2026 @ 11:00 AM (IDT)
CheckMates Live Netherlands - Sessie 48: Nieuwe Check Point Workspace SecurityTue 14 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E11: READY OR NOT: Securing the AI Enterprise 3/5 - AI Workforce SecurityThu 30 Jul 2026 @ 10:00 AM (PDT)
AI Security Masters E12: READY OR NOT: Securing the AI Enterprise 4/5 - AI GatewayThu 20 Aug 2026 @ 10:00 AM (PDT)
AI Security Masters E13: READY OR NOT: Securing the AI Ent 5/5 - AI Research & Threat LandscapeAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY