The valid kernel parameters to change the magic Mac are: fwha_mac_magic fwha_mac_forward_magic And the procedure should be: 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 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 ** the 250/251 should be the SAME on both cluster member , but should be DIFFERENT for each different cluster ** We do not recognize the second parameter, if you think it is relevant please let me know where you took it from.
Ok, to me, this TAC answer seems different than what the Check Point sk36913 says. Below is a cut and paste from that sk...
---------------------- (BEGIN of sk36913) ----------------------
|The Cluster Control Protocol (CCP) packets that are sent between the members of the same cluster reach the neighbor cluster (connected to the same network) and "confuse" it.|
|The "confusion" rises from the fact that CCP packets in Check Point clusters have the same Source MAC address - |
Refer to any version ClusterXL Administration Guide -> Chapter ClusterXL Advanced Configuration -> Working with VLANS and Clusters -> Connecting Several Clusters on the Same VLAN
The 5th field of Source MAC Address -
This is controlled with the following kernel parameters :
Note: in this case, the numbers will be shown in Decimal format
Default values on non-VSX :
Default values on VSX :
|The Cluster Control Protocol (CCP) packets that are sent
between the members of the same cluster reach the neighbor cluster
(connected to the same network) and "confuse" it
|It is not recommended to connect interfaces of multiple
clusters to the same network segment (same VLAN, same switch). A
separate VLAN and/or switch is recommended for each cluster. A crossover
link may be used for the sync (secured) interfaces. |
If there is a need to connect the interfaces (secured or non-secured) of multiple clusters to the same network segment, you need to make changes to:
Steps to change Source MAC Addresses:
(For all ClusterXL modes, both High Availability and Load Sharing)
How the Source Cluster MAC Address is assigned:
Cluster members communicate with each other using the Cluster Control Protocol (CCP). CCP packets are distinguished from ordinary network traffic by giving CCP packets a unique Source MAC address.
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.
To ensure that the source MAC address in packets coming from different clusters that are connected to the same VLAN can be distinguished, change the source MAC address of the cluster interface that is connected to the VLAN in all but one of the clusters. Configure the following security gateway parameters to set more than one cluster on the same VLAN (these parameters apply to both ClusterXL and OPSEC certified clustering products. Note that CCP traffic is transmitted only through the Sync interface of OPSEC certified clustering products:
Module parameters with default values of 5th byte:
These parameters apply to both ClusterXL and OPSEC certified clustering products. Changing the values of these module configuration parameters alters the fifth part of the source MAC address of Cluster Control Protocol and forwarded packets. Use any value as long as the two module configuration parameters are different. To avoid confusion, do not use the value 0x00 or 0xFF.
For example you may want to configure these parameters as the following:
When Performance Pack is used to enhance the performance of ClusterXL Load Sharing Multicast Mode, it is recommended that the chosen numbers be consecutive, with the lower one being even (e.g., 0x10 and 0x11, or 0xBE and 0xBF, in the example above 'a' and 'b').
PROCEDURE (configuration surviving reboot per sk26202):
To be performed on each cluster member that is connected to the same network segment.
Very important: when editing multiple clusters, please make sure that values are different (values should be same for 2 members of one cluster), for example 'fe' and 'fd' for same cluster members, but for different cluster it would be i.e., 'ba' and 'bb' values.
Steps to change Destination Multicast MAC Addresses:
(For ClusterXL Load Sharing Multicast Mode clusters only)
PROCEDURE (For user-defined multicast MAC address):
I trust the engineer enough to go with what he says.
Now, just one more confusing note in case you see it. In sk26202, it says the following to make the change permanent. It was referenced in sk36913 (above). I tried this below, it didnt work for me.
|Global kernel parameters exist to control (customize) the behavior of Security Gateway (kernel parameters are located in |
This control (customization) can be done on-the-fly using the
***SOLUTION UPDATE: I did what the TAC engineer said to do in the email above, with exception of one thing. I put in the HEX number instead of the DECIMAL number. What I did worked, and it now shows up correctly in the ARP table of my Cisco switch. Below, in yellow, is what I changed on my second cluster. In orange, is the default original cluster.
Vlan Mac Address Type Ports ---- ----------- -------- ----- 2 0000.0000.fe00 DYNAMIC Gi1/0/13 2 0000.0000.fe01 DYNAMIC Gi1/0/14 1 0000.0000.fb00 DYNAMIC Gi1/0/8 1 0000.0000.fb01 DYNAMIC Gi1/0/7
Now, when I hook this up and verify everything is all as it should be, I see the following on the Cisco switch:
Switch#sh mac-address-table dyn Mac Address Table ------------------------------------------- Vlan Mac Address Type Ports ***NOTES*** ---- ----------- -------- ----- 2 0000.0000.fe00 DYNAMIC Gi1/0/13 (Sync - Cluster#1 Device#1 Virtual MAC) 2 0000.0000.fe01 DYNAMIC Gi1/0/14 (Sync - Cluster#1 Device#2 Virtual MAC) 2 0091.5yh8.9e4b DYNAMIC Gi1/0/14 (Sync - Cluster#1 Device#2 Real MAC) 2 0091.5yh8.a19b DYNAMIC Gi1/0/13 (Sync - Cluster#1 Device#1 Real MAC) 1 0000.0000.fb00 DYNAMIC Gi1/0/8 (Public - Cluster#2 Device#1 Virtual MAC) 1 0000.0000.fb01 DYNAMIC Gi1/0/7 (Public - Cluster#2 Device#2 Virtual MAC) 1 0000.0000.fe00 DYNAMIC Gi1/0/23 (Public - Cluster#1 Device#1 Virtual MAC) 1 0000.0000.fe01 DYNAMIC Gi1/0/24 (Public - Cluster#1 Device#2 Virtual MAC) 1 002a.6r4t.104d DYNAMIC Gi1/0/7 (Public - Cluster#2 Device#2 Real MAC) 1 002a.6r4t.10c5 DYNAMIC Gi1/0/8 (Public - Cluster#2 Device#1 Real MAC) 1 0091.5yh8.a194 DYNAMIC Gi1/0/23 (Public - Cluster#1 Device#1 Real MAC) 3 0000.0000.fa00 DYNAMIC Gi1/0/15 (Sync - Cluster#2 Device#1 Virtual MAC for CCP Traffic) 3 0000.0000.fb00 DYNAMIC Gi1/0/16 (Sync - Cluster#2 Device#2 Virtual MAC) 3 0000.0000.fb01 DYNAMIC Gi1/0/15 (Sync - Cluster#2 Device#1 Virtual MAC) 3 001c.6r4t.08ae DYNAMIC Gi1/0/16 (Sync - Cluster#2 Device#2 Real MAC) 3 001c.6r4t.0932 DYNAMIC Gi1/0/15 (Sync - Cluster#2 Device#1 Real MAC)