Gateway Stanby Member is Lost

[ikafka]

Hi,

I wanted to check after upgrading the stanby member because I was going to take the traffic to the stanby device and upgrade the active one. But the stanby device seems lost.

My management server version: 81.10 

Active device version: 80.30

Stanby debice version: 81.10 (new upgrade) 

[Expert@kafka-fw1:0]# cphaprob state

Cluster Mode:   High Availability (Active Up) with IGMP Membership

ID         Unique Address  Assigned Load   State          Name

1 (local)  10.99.0.5       100%            ACTIVE(!)      kafka-fw1
2          10.99.0.6       0%              LOST           kafka-fw2


Active PNOTEs: IAC

Last member state change event:
   Event Code:                 CLUS-110305
   State change:               ACTIVE -> ACTIVE(!)
   Reason for state change:    Interface Mgmt is down (Cluster Control Protocol packets are not received)
   Event time:                 Fri Jun  2 14:02:54 2023

Last cluster failover event:
   Transition to new ACTIVE:   Member 1 -> Member 2
   Reason:                     FULLSYNC PNOTE - cpstop
   Event time:                 Tue Apr 14 19:24:46 2020

Cluster failover count:
   Failover counter:           1
   Time of counter reset:      Mon Apr 13 10:46:37 2020 (reboot)

[_Val_]

You need to enable MVC mode. If you upgraded your standby to R81.10 while your active member is still R80.30, they cannot sync and form a cluster unless you enable MVC - Multi-Version Clustering mode. Look into the upgrade guide, there is a chapter about it there.

[ikafka]

I just checked, we use this command on the active device. In this case this note in the guide:"The change made with this command survives reboot."  I can not disconnect internet connection now. I will do it at the appropriate time and share the result.  

[ikafka]

FW-2 did set cluster member mvc on. 

kafka-fw2> show cluster members mvc

ON

But it is still the same status "lost". What could I be missing? When I check it from the smart console, it gives me this warning. And the version information is correct.

verison info: 

[the_rock]

You could always check in object list by that IP and see what shows up, but as I mentioned in my first response, from my experience, I never bother with MVC and failing over to upgraded member was always fine and I must have done this at least 30 times and never had a single problem. But, if you dont feel comfortable with it, I guess contact TAC and see what they say.

Andy

[the_rock · Accepted solution]

I would not worry about it one bit if I were you. I did cluster upgrades many times and every single time, status showed what you pasted (never bother with MVC mode) and when failing over to upgraded member, all worked fine, without a single issue. Once upgraded, all you need to do is change version in the cluster properties to new one and then uncheck below option, as per my screenshots. But. having said this, @_Val_ is 100% correct, MVC solves this beforehand.

Andy

 

 

[ikafka]

I agree with you. I have never needed MVC in my previous upgrades. This devices is a bit sensitive. We cannot tolerate even ping loss. That is why I wan to %0 risk. I will do a a study and I will inform you. 

Thanks.

[the_rock]

Ok, understood. Well, in that case, I strongly recommend to engage TAC

https://help.checkpoint.com

Andy

[ikafka · Accepted solution]

Thanks @the_rock 

I installed policy separately and now FW-2 and FW-2 is state down. I changed selected version R81.10 and MVC state off. I will only take traffic other fw-2  and upgrade fw-1. So the LOST problem  with policy publish and install has solved. (with the the uncheck you specified) Thanks @the_rock and @_Val_ 

[the_rock]

MAKE SURE to recheck that option in policy push window "if it fails..." once both members are upgraded.

Andy

[the_rock]

Good job! 👍💪