Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Wyman
Contributor

ClusterXL Upgrade - When to Turn Off CCP Broadcast?

Jump to solution

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.

 

 

2 Solutions

Accepted Solutions
_Val_
Admin
Admin
HeikoAnkenbrand
Champion
Champion

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 

View solution in original post

(1)
11 Replies
_Val_
Admin
Admin
Wyman
Contributor

Thanks Val.

the_rock
Leader
Leader

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.

0 Kudos
_Val_
Admin
Admin

@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

0 Kudos
the_rock
Leader
Leader

Never seen it flood any domains, no. 

0 Kudos
genisis__
Advisor

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). 

0 Kudos
the_rock
Leader
Leader

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.

0 Kudos
genisis__
Advisor

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

 

0 Kudos
HeikoAnkenbrand
Champion
Champion

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 

View solution in original post

(1)
Timothy_Hall
Champion
Champion

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...

 

"Max Capture: Know Your Packets" Video Series
now available at http://www.maxpowerfirewalls.com
0 Kudos
(1)
genisis__
Advisor

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).

0 Kudos