Magic MAC different in GuiDBedit vs on the gateway

[cdooer]

We're having some trouble connecting to a VPN cluster, and it seems to be acting very erratic. For instance, sometimes when you connect to the cluster with the VPN client, it gets to the point where it's 'Downloading Topology'. Then it just disconnects, and that specific gateway is unreachable for approx 5 mins (can't get to it with HTTPS or SSH). I noticed that the value for the Magic MAC is different in GuiDBedit compared with what it shows in CPView on the gateway itself. Would that cause an issue?

[_Val_]

Which version, for starters?

[cdooer]

Sorry, R80.30

[_Val_]

@cdooer nothing to be sorry about, just covering the basics. You can safely ignore GUiDBEdit value for magic mac a.k.a. clusterID. GW side settings is what matters. 

With the symptoms described, start looking to other details. make sure GW does not reboot, or experience cluster flapping, or is having intermittent performance issues. If you do not know where to start, please open a TAC case.

[cdooer]

Will do. I also have another new R80.30 cluster on the same network, same VLAN, and it's also showing a magic MAC of 1. Wondering if that could cause an issue?

[_Val_]

Yes, it might. Having two different clusters in the same broadcast domain, with the same clusterID is not good and might cause instabilities (see "cluster flapping" above). 

Please refer to sk25977 for full details of how work it around. 

[cdooer]

So I was told today that with the new Gaia 3.10 kernel, the magic mac doesn't matter anymore. So it doesn't matter if multiple clusters on the same broadcast domain have the same one. Anyone care to comment?

[_Val_]

You are running R80.30. In R80.40 clusterID is no longer important. with R80.30 it still is.

[cdooer]

We're still fighting with this, and it's with TAC, but Checkpoint confirmed this morning that in the 3.10 kernel of the R80.30 build, the magic mac no longer matters. Just in case anyone else had the same question.

dp