GAiA is Linux RH based, and it has system 2.6.18 kernel. And Check Point ClusterXL is still the same as before.
If you are upgrading to GAiA or installing in fresh in a cluster configuration, you may need to take care of so-called "magic mac" settings.
To remind you briefly, "magic mac" is an artificial MAC address used in CCP, Cluster Control Protocol, responsible for probing, messaging and sync communications in ClusterXL. Once you have more than one cluster in the same network, you have to change magic mac settings starting from the second cluster and up.
Some details about the change is mentioned in SK66527.
GAiA or SPLAT, it makes no difference. If you are using ClusterXL and not VRRP, follow the mentioned solution.
For those who do not have the access, here is a quick HOWTO:
First, make sure your magic mac are default. To check that, run fw ctl get int fwha_mac_magic and fw ctl get int fwha_mac_forward_magic commands, as in the example bellow:
# fw ctl get int fwha_mac_magic
fwha_mac_magic = 254
# fw ctl get int fwha_mac_forward_magic
fwha_mac_forward_magic = 253
The default settings are, as shown 254 and 253.
On the second cluster you will have to do the following:
On each of the Cluster Modules
1. cd $FWDIR/boot/modules
2. create the fwkern.conf file by: # vi fwkern.conf
3. Add the required parameters and values as given below:
fwha_mac_magic=250
fwha_mac_forward_magic=251
Mind the numbers marked bold should be unique on each cluster you are making changes and non equal to default.
4. Save the fwkern.conf
5. Verify the fwker.conf is correctly configured by: # more fwkern.conf
6. Reboot the Module
7. Verify the new mac magic setups correctly configured by:
# fw ctl get int fwha_mac_magic
# fw ctl get int fwha_mac_forward_magic
8. Verify the Cluster Module status by:
# cphaprob stat
And just a reminder, if you are using VRRP instead of ClusterXL, you do not have to do any of the above.
NOTE: refer to sk26202 for instructions about $FWDIR/boot/modules/fwkern.conf
ReplyDeleteOn Linux, there must not be any spaces around the '=' sign :
PARAMETER=VALUE
Thanks, valuable remark
ReplyDeleteHi Valeri
ReplyDeleteRegarding to clustering I have a question.I am new in checkpoint
We have 2 utm-1 1070(r70.1) in cluster mode.one of them had a hardware problem.
We have changed it with same model.I have upgraded it to same software level as before.
I have made an backup from faulty device and remove netconf.c from it and zip it and restore to new device.(based on RMA documentation)
I have pushed the policy from SMS server .it was successful.
I have checked the this command :
CPhaprob Stat
Fw ctl pstst
Cpstat fw
Routre , OSPF configuration
the resulat was good
I have turned off the Sec FW and this new firewall handle the traffic well. Next I have made both of them on and Sec go active and primary Standby
Everything is OK ,
After 2 days, secondary went to standby and primary went to active, but cannot handle the traffic.
I just wondering , what is the issue ? how can I check the reason ?Did I miss something during the backup restore? Could you please give me some advice ?
It's impossible to say what's wrong from the info you gave. I suggest you opening a support call with the vendor
ReplyDeleteThanks Valeri,
DeleteOnly i saw Policy installed and unistall every 1 sec(automatically) .Service stop . no inetrenet to access to outside ,....
I will create SR ASAP
Cheers
Medwin
I think it's important to point out this is only effective when using broadcast mode. In multicast mode the magic mac alterations aren't necessary.
ReplyDeleteJelle, I am sorry to tell you, but your statement is absolutely wrong
ReplyDeleteValeri, Thanks for your reply. I'm saying this because in the SK's about this (for example sk25977) the following is mentioned:
ReplyDeletePROBLEM OVERVIEW (Duplicate Source Cluster MAC Addresses):
When more than one cluster is connected to the same VLAN, if CCP and forwarding layer traffic uses multicast, this traffic reaches only the intended cluster.
If CCP and forwarding layer traffic (and in certain other cases) use broadcast, cluster traffic intended for one cluster is seen by all connected clusters, and is processed by the wrong cluster, which causes communication problems.
It's logical, since multicast will not use the broadcast mechanism, hence not reaching other than intended clusters. I have 2 clusters connected to the same VLAN, and no issues with this. I'd like to hear your opinion on this.
Please look into the solution mentioned in my post and also to clusterxl guide, it is all described there. You are talking about one of many issues, very rare.
ReplyDeleteValeri, your SK states it is a recommended setting. I'm not saying it's bad to set this, but in multicast configuration it should not be necessary... I have had this configuration running with multiple versions of Checkpoint and haven't had issues with this. Magic Mac unaltered....
ReplyDeleteYou're stating that my statement is absolutely wrong, but it's not. It doesn't hurt to change the magic mac and maybe prevent issues in upcomming canges, but it's certainly not mandatory.
Hi Jelle, thanks for your opinion.
DeleteNow, ClusterXL Administration Guide and my 10 year experience with it say this change is mandatory. It is best practice to eliminate any potential instability with ClusterXL. You may be OK without it, but in around 10% of the general cases. Guess you just got lucky.
Does the magic MAC need to be on both (all) members of the cluster before the cluster even goes into the proper state? I added this on a secondary cluster member, rebooted, but the secondary cluster member did not join the cluster once it rebooted.
ReplyDeleteAzog, same configuration should be on ALL cluster members.
ReplyDeleteI have changed the default magic mac values on my cluster but i plan to upgrade from SPLAT to Gaia due to another cluster having the same values. My question is will these default values be set again after the upgrade?
ReplyDeleteTheoretically they should survive, but it is always the best to check the file and re-introduce if necessary
DeleteIn CP clusterXL when there are few that sharing same subnet you should expect to get
ReplyDeletemessage in tracker, "cluster member detected a problem"
this when connecting multiple clusters to the same network segment, same VLAN, same switch
the solution is by assign unique ID to the Magic MAC on each cluster using kernel parameter "fwha_mac_magic"
if this is not regular security gateway by a VSX machine then need to notice this fact,
when using more then one VS on the same VLAN, the CCP packets generated from each VS are
transmitted in broadcast mode with the VSX machine source MAC address. the VSs can not
distinguish between CCP packets that destined to them or the other VSs on the same VLAN,
since each VS doesn't have a unique mac address but the VSX mac address.
this type of deployment is equivalent to configuring several cluster on the same VLAN,
but WITHOUT the ability to configure a magic mac to solve it.
Gyovel, VSX configuration you are describing is not supported. It is clearly stated in the ClusterXL guide.
DeleteHi Valeri,Could you pls share how packet flow in clusterxl enviroment ..like what mac it use and before failover and after failover.
DeleteHi Tushar,
Deleteall above has nothing to do with your question.
In ClusterXL HA active member uses it own physical MAC addresses to handle the traffic. If failover happens, the new active member sends gratuitous ARP to update arp tables of adjacent devices.
Hope this answers your question