- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Announcing Quantum R82.10!
Learn MoreOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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 |
|---|---|
| 16 | |
| 12 | |
| 8 | |
| 7 | |
| 6 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY