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! 👍💪

[scenarist]

I am experiencing the same issue. I have a ClusterXL deployment with two members, cp1 and cp2. I successfully upgraded the management server to R82 without any issues. Following that, I upgraded cp2 (the standby member) via CPUSE, after which I encountered the following errors:

At this stage, should I proceed with upgrading cp1 (the active member), or is there an additional step I need to perform first?

I also enabled MVC on the upgraded member (cp2), but the same errors continue to appear in SmartConsole.

cp6-2> show cluster state

HA module not started.

Cluster policy should be installed - please run cphastart

cp6-1> show cluster state

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

ID Unique Address Assigned Load State Name

1 (local) 10.11.12.1 100% ACTIVE cp6-1
2            10.11.12.2   0%     LOST cp6-2

[the_rock]

Just run cphastart on that member and it will be fine, then you can upgrade the other one. Before you upgrade other member, push policy and MAKE SURE to uncheck setting "if it fails" in install window.

Andy

Andy

[scenarist]

[Expert@cp6-2:0]# cphastart
[Expert@cp6-2:0]# exit
exit
cp6-2> show cluster state

HA module not started.

Cluster policy installation failed on gateway (Error code: 304).
cp6-2>

[Expert@cp6-2:0]# cphaprob mvc

ON

[Expert@cp6-2:0]#

[the_rock]

Can you try policy option i mentioned?

Andy

[scenarist]

okey. I change version to R82 in smartconsole under general settings t

is it safe now to install policy ?

[the_rock]

Yes.

[scenarist]

Great! Thank you very much. I am little bit scared because it is production system.

Now I will CPUSE upgrade cp1 to R82.

Great!

[the_rock]

Just remember this...cluster would NEVER work if there is no policy installed.

Andy

[ikafka]

Last week, I upgraded a cluster structure from R81.20 to R82 for a major customer. Previously, I used to  CPUSE. This time, I used the Central Deployment method ( on Smart Console).
It was really easy. I just started  and then sat back and watched. Definitely best practice! I recommend it.

[the_rock]

I did the same in the lab recently, no issues.

Andy