Verifying Magic Mac - r81.10

[cdooer]

Hey everyone. We've started consolidating firewall clusters, and are moving some of them onto the same VLAN/subnet. We're noticing some performance issues, and we're seeing a ton of unexpected packets being dropped because they are out of state. I'm wondering if we're running into conflicting magic mac's? Trying to run the command "cphaprob mmagic" doesn't get me anywhere, as it seems to indicate it's not a valid command. 

CPHAPROB -a if shows me this, which makes me think I'm running manual mode, and should switch to automatic;

FIREWALL1> cphaprob -a if

CCP mode: Manual (Unicast)
Required interfaces: 7
Required secured interfaces: 1

But CPVIEW shows I've got a Magic Mac ID of 254. which makes me think it's already running automatic?

Any definitive way to figure out of this could be causing my issues?

[the_rock]

Let me connect to customers VPN and I will verify, as they also have R81.10 clusterXL HA.

[the_rock]

I could be mistaken, but Im fairly sure it is adjusted automatically in R81+. I could not find any kernal valus you could change for it.

Andy

[the_rock]

K, I take that back, I was wrong (would not be first or last time lol)

According to @_Val_ 's link below, value is still there in even new versions:

 https://checkpoint-master-architect.blogspot.com/2012/05/gaia-clusterxl-magic-mac-settings-same.html

See below:

fw ctl get int fwha_mac_forward_magic
GetLicFromFile: Failed to open file: /opt/CPshrd-R81.10/conf/cp.pnp
pnp_init_blades: Failed to get data from PnP file: /opt/CPshrd-R81.10/conf/cp.pnp
fwha_mac_forward_magic = 253

[Timothy_Hall]

To add on to what Phoneboy said, Gaia 3.10 introduced several changes to ClusterXL.  Gaia 3.10 became mandatory on gateways starting in R80.40 but there was a R80.30 Gaia 3.10 gateway release that saw limited use.  As SK167206 states there is no more magic mac in Gaia 3.10 and any leftovers you might see are not relevant.  In addition the automatic CCP mode configuring itself to unicast mode in almost all situations, instead of the old default multicast, further reduces the chances of different clusters seeing each other's CCP traffic.

[dunkelmorten]

I know it has been posted that MAC magic is no longer relevant, but still this raises concerns on my end.

Having a customer running multiple VSX cluster on R81.10 but several of them are connected to same VLAN for Sync (in contrast to recommendation) with each cluster having dedicated /30 subnet. On the Cisco switches connected to the VSX we are recognizing plenty of "%FWM-6-MAC_MOVE_NOTIFICATION" messages on the VLAN used for cluster sync.

All cluster members are showing "CCP mode: Manual (unicast)".
As mac magic settings can still be checked I have done so and all are showing same value: 254

Any idea where these MAC move notifications could be coming from if mac magic is no longer used?

[the_rock]

Definitely something to consider @dunkelmorten . Personally, I cant speak for VSX, as none of customers I work with use it, but as far as regular gateway, never had to touch this since R80.

Best,

Andy

[dunkelmorten]

Thank you.

Will probably need to raise a support case for investigations. Does make sense to me right now.

[PhoneBoy]

Doubt it's even relevant to the issue since Magic Mac isn't used since R80.40.
See: https://support.checkpoint.com/results/sk/sk167206 

[the_rock]

Any luck with this @cdooer ? As @Timothy_Hall and @PhoneBoy said, since magic mac is not relevant starting R80.40 version, its most likely not a problem in your situation. I see even in my R81.20 lab, kernel value is there, but its pointless changing it. 

Can you maybe give us some more insight as to what issue is as far as performance?

Andy