Automated MAC magic value in R80.10 might lead to same Cluster-ID`s along all Clusters

[Linus_Espach]

Dear Check Point,

according to the different manuals I`ve read concerning SRC-MAC of CCP- and Forward-Packages and it is not recommended to set <MAC magic> any more by hand.

(See sk-25977-Change Source MAC Addresses - Gateway Mode - Gaia R80.10 - Procedure)

It is stated there, that the algorithm for the MAC magic is the following:

"During the initial configuration of the cluster members, they apply the following algorithm to set the MAC magic value:

• Try to set the 5th byte of the Source MAC address to 1.
  If CCP packets with such value in the 5th byte of the Source MAC address are detected, then select the next value.
• Try to set the 5th byte of the Source MAC address to 2.
  If CCP packets with such value in the 5th byte of the Source MAC address are detected, then select the next value.
• And so on and so forth, until an unused value is detected (it takes up to ~30 seconds).

Note: All members of the same cluster will set the same value."

I am wondering, because this (locally limited) algorithm will, for each Cluster with a separated/dedicated sync-network, find the same value for its <MAC magic> (so the Cluster-ID).

According to the same SK there should be a unique Cluster-ID for all (managed) Clusters within the domain: "Enter a unique value for each cluster in the domain."

The above algorithm will not find the other Clusters if they have separated sync-networks. So as far as I understand, there will be the same Cluster-ID along many clusters ( in this case always the ID 1).

Could you please clarify this for me?

Best regards

[Vladimir]

CCP is blasted on all cluster interfaces, not over isolated SYNC link or network.

I.e.:

[Expert@HostName]# cphaprob -a if

The CCP mode will appear at the end of the line.

Example:

 
Required interfaces: 4
Required secured interfaces: 1

eth0       UP                    non sync(non secured), multicast
eth1       UP                    sync(secured), multicast
eth2       UP                    non sync(non secured), multicast
eth3       UP                    non sync(non secured), multicast

[Olavi_Lentso]

What happens with two clusters with automatic magic, when they haven't had a common VLAN before, but at some momet they will be connected into the same VLAN?

Do members of one of the clusters adjust their magic or the learning process is only performed during the initial configuration and no further adjustments is made when another cluster "appears suddenly"?

[Linus_Espach]

Sure, probe-requests are sent along all interfaces, but as far as I understood this procedure, it is limited to L-2 communication. Therefor, if you have Clusters among different networks (I.e. VPN, or separated / routed networks) this will fail.

[HeikoAnkenbrand]

More see here:

R80.30 cheat sheet - ClusterXL

[PhoneBoy]

The Magic MAC should be the same among all members of the same cluster and unique for each cluster on the same Layer 2 network.
It's possible (and expected) that clusters on different Layer 2/3 networks might have the same Magic MAC.
If suddenly a new cluster shows up on the same Layer 2 network and the Magic MACs collide, this will be detected and adjusted on the fly.

[Olavi_Lentso]

I would like to know more about the situation where 2 or more already operational clusters are going to have a shared layer 2/3 network. How the clusters decide, which of them wins the fight and could keep the existing ID and which one must change it's ID. What impact is expected while VMAC being ON or OFF?

[Albert_Wilkes]

just stumbled across your question - sorry if this answer is for R80.30, surely there's one in the adminguide for .10 as well. I would assume the underlying mechanism of the packets on the wire hasn't changed - if it had it'd certainly pose problems when upgrading firewalls.

https://sc1.checkpoint.com/documents/R80.30/WebAdminGuides/EN/CP_R80.30_ClusterXL_AdminGuide/html_fr...

... Chapter "Connecting Several Clusters on the Same VLAN"