ClusterXL Upgrade - When to Turn Off CCP Broadcast?

[Wyman]

Hi. I'm looking at the instructions for performing a zero downtime upgrade of our HA cluster to R80.40 and, although it says to turn on CCP broadcast at step 1, it doesn't say if we need to set it back to auto at the end of the upgrade. If we do need to set it back to auto, at what stage of the process do we do that:

1) At the very end, after the policy has been installed on both upgraded gateways?

2) After upgrading the second cluster member but before policy is installed on both upgraded gateways?

*Documentation: https://dl3.checkpoint.com/paid/71/711f035424209604dfe7d9c3860f2e50/CP_R80.40_Installation_and_Upgra... - Page 544

Thanks in advance.

[_Val_ · Accepted solution]

Option 1

[Wyman]

Thanks Val.

[the_rock]

Honestly, Val is 100% correct, but to add to it, I saw lots of customers running in unicast mode on clusterXL HA (active standby) and never changing mode during upgrade and still works fine.

[_Val_]

@the_rock working fine, apart from flooding the broadcast domains, you mean 🙂

With R80.40 and up, CCP multicast is encrypted, and this is how it should work from now on, in my view

[the_rock]

Never seen it flood any domains, no. 

[genisis__]

I just did a R77.30 to R80.40 migration and use "set cluster member mvc on"

Also I noted when configuring clone group 'mvc' is reported in the clone monitor page, and I suspect is a cosmetic bug (we are running JHFA91 so it could possible be resolved in a later jumbo such as 102). 

[the_rock]

I guess the mode also depends on type of switch people use.. I recall in the old days there was a known issue with certain types of switches if you used multicast mode.

[genisis__]

mode is default, so its selected unicast.  the mvc entry is only seen in the WEBUI and not observed in the CLI.

[HeikoAnkenbrand · Accepted solution]

With R80.40, the unicast CCP mode is always used automatically as default.
With MVC it is possible to upgrade from version R77.30 or higher to R80.40.

This has always worked without any problems.

Tip:
I would always install the last JHF on both gateways R80.40 JHF102. Also at the older gateway R77.30 JHF351.

More read here:
R80.40 - Multi-Version Cluster (MVC) Upgrade 

[Timothy_Hall]

I think the original recommendation to set CCP to broadcast during a Zero Downtime upgrade procedure was to ensure proper handling of CCP traffic by the attached switches during the upgrade, as some switches would not always reliably forward multicast packets.  If that happened during an upgrade it would cause the cluster members to repeatedly bounce from active/ready to down/active and back to active/ready again which would cause traffic handling issues.

However if upgrading into R80.40 or later from R77.30+, you should not be using the Zero Downtime upgrade method or messing around with the CCP transport mode even though doing so is still supported.  Use Multi-Version Cluster instead which is the replacement for the old "Full Connectivity Upgrade" (FCU); in R80.40 the default mode for CCP is "Automatic" and will normally auto-select to the new CCP unicast mode which avoids all the multicast & broadcast issues/floods.  Please see my post here:  https://community.checkpoint.com/t5/Security-Gateways/Enable-MVC-During-Cluster-Upgrade/m-p/118524/h...

[genisis__]

Exactly what I used this week!

One thing I did note is that R80.40, by default turns on CCP encryption. I then noticed ccp traffic drops in the logs and had to add a rule for this.

Once I disabled the encryption I removed the rule and we were all good (still had a rule in place for clone group and echo-request between the nodes).