MAC Address 0000.0000.0101 and 0000.0000.0100

[Niklas_Davidsso]

Hey! 

So i have a problem, i have 7ish ClusterXL sites. 

and when i try to preform a migration on my ISP they get a loop from my Firewalls.

after i tracked it i see this problem on every ClusterXL site. 

They all have the same MAC Address 

Site X

 0000.0000.0100 dynamic ip,ipx,assigned,other TenGigabitEthernet2/1/4
 0000.0000.0101 dynamic ip,ipx,assigned,other TenGigabitEthernet1/1/4

Site Y

0000.0000.0100 DYNAMIC Gi0/20
0000.0000.0101 DYNAMIC Gi0/43

Anyone knows how to disabel this fake address ? 

[_Val_]

You do not want to disable those "fake" MAC addresses, because they represent in fact ClusterID

CCP uses artificial MAC to send ClusterXL probing and status exchange communications. Those MACs are used to identify multiple members of the same cluster.

They are not used to carry any production traffic. For more details, refer to ClusterXL ATRG:https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...,

or attend CCSE courses.

[Niklas_Davidsso]

well i want to limit them on specific interface, that connects to my WAN.

I will have a look at the Link Val!

[_Val_]

Unless you have connectivity issues on WAN router, there is not harm. If you do, look at ATRG to find a workaround. 

[Niklas_Davidsso]

The ISP sees the MAC 0000.0000.0101 for example coming in from two diffrent ports.

And there Anti Loop trigers shuting down my WAN. so there is a issue.

Most of all i just want to exclude the CCP from my WAN interfaces.

[_Val_ · Accepted solution]

Disable IGMP snooping on the ports that are making issues. All cluster members are using the same "Magic macs" as ID for CCP communications.

Here is another reference for you for that matter: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Niklas_Davidsso]

Will the "Fake" Mac address stop if i turn it over to broadcast?

[_Val_]

That is also an option, but you will be flooding your segment with CCP broadcast packets.

[Niklas_Davidsso]

bond0 UP sync(secured), multicast, bond High Availability
eth2 DOWN (2.94402e+06 secs)non sync(non secured), multicast (eth2.513 )
eth1 UP non sync(non secured), multicast (eth1.104 )
eth1 UP non sync(non secured), multicast (eth1.2 )
eth2 UP non sync(non secured), multicast (eth2.913 )

and there is no way just to exclude eth2 from this?

[_Val_]

It is a global parameter, no way to switch more per interface.

[Niklas_Davidsso]

Thank you Val for the help! 

I will implement the broadcast and test that, 

i am runing a 80.20 already on that way (80.10 on the rest of my clusters)  and it seems that 80.20 broad is preferd already.

so it might be a non issue when upgrading. 

[_Val_]

However, if you have multiple ClusterXL cluster in the same broadcast domains, having default Cluster ID is problematic.

Look here for resolution: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...