Cluster XL - MAC ADDRESS MOVEs

[Geomix7]

Hello guys ,

I will described below the scenario and please advice if anyone else faced this issue.

involved: DNS server - 2 Clusters with 4 members (R80.20) - Nexus switch 

DNS send the packet to 1st layer firewall with correct MAC address.

14:28:31.177248 XX:XX:XX:XX:e6:86 > XX:XX:XX:XX:96:b8, ethertype IPv4 (0x0800), length 156: XX.XX.XX.70.domain > XX.XX.XX.65.10253: 1178 NXDomain 0/1/0 (114)

Then the 1st layer firewall received the packet correctly.

14:28:31.191342 XX:XX:XX:XX:e6:86 > XX:XX:XX:XX:96:b8, ethertype IPv4 (0x0800), length 156:XX.XX.XX.70.domain > XX.XX.XX.65.10253:  1178 NXDomain 0/1/0 (114)

Afterwards the next packet translated to the below by the 4th member of the cluster.

14:28:31.191358 02:00:00:00:00:00 > XX:XX:XX:XX:90:64, ethertype IPv4 (0x0800), length 156: XX.XX.XX.70.domain > XX.XX.XX.65.10253:  1178 NXDomain 0/1/0 (114)

Notes:

1.Captures on DNS and switch shows that DNS never send those MAC address 02:00:00:00:00:00

2.All Packets that includes mac address 02:00:00:00:00:00 are outbound traffic from FW

3. CCP mode broadcast

4.Confirm from switch that this MAC is generated on FW

4. we cannot find and relate any errors on FW

Any advises are welcome!

Thank you

[Wolfgang]

@Geomix7 ,

can you please explain more detailed your environment.

You wrote something about a 4th member of the cluster, sounds like a cluster with 4 nodes. But at the beginning of your writing you wrote 2 clusters with 4 members.... Do you have 2 clusters and both with 2 nodes or anything else?

How about your ClusterXL mode. HA or LoadSharing, vmac ?

What is the problem?

Please be aware that sometimes sending and receiving MACs are different. It depends on the ClusterXL configuration.

Wolfgang

[Geomix7]

Dear Wolfgang ,
We have 2 clusters which each one has 4 nodes.
Each cluster is in HA mode and also is setup with magic MAC.
The problem is that we can see many mac moves with specific mac 02:00:00:00:00:00 which appeared randomly on all nodes.We are trying to figure out what is the root cause of this issue.

[Maarten_Sjouw]

02:00 are normally used by VRRP only when using extended VMAC, but then the rest of the mac is not all 0's, as VRRP will use a VMAC derived from the IP of the interface.

[Geomix7]

Dear Maarten,

We are not have enable VRRP implementation.

[_Val_]

AFAIK, Check Point does not use port 10253 for any of the communications. 

[Geomix7 · Accepted solution]

Dear All ,

After many hours of remote sessions please find below the solution:

We had implemented the  ccl_preserve_src_MAC=1 This command changed the MAC address format to the old format (like R77.30).

After that the MAC moves of MAC address 0200.0000.0000 has been stopped and issue was resolved.

Thank you

[MartinTzvetanov]

yeah, I had a case when upgrade from 77.30 to 80.20 and VMAC. In R80x the VMAC is calculated differently than older version and the problem I faced was internet traffic not coming back. 10 minutes after this we found that it's an ARP problem and the router facing Internet doesn't know what to do with the packets. Clearing the arp-table fixed the problem.

[David_C1]

I am seeing just about the same issue. I don't ever recall setting the ccl_preserve_src_MAC parameter. I have three clusters connected to the same vlan. Two were R80.40 with JHFA Take 48, one was R80.20 with JHFA 134. It was almost entirely DNS traffic that exhibited this behavior (there was a very small amount of Identity Awareness traffic). Based on support recommendation, I upgraded everything to R80.40 with JHFA Take 67. I still have the issue with the DNS traffic, but no longer with the IA traffic. sk168076 describes a similar issue to what I'm seeing. I am waiting to hear back from support.

[Geomix7]

Hello David ,

We had permanently solved this issue by setting the ccl_preserve_src_MAC parameter on one cluster to 1 and to the other cluster to 0.

[David_C1]

I fixed this by:

1. Setting the parameter ccl_preserve_src_MAC to 1 on each cluster member

2. Found that this did stop the 02:00:00:00:00:00 mac address from appearing, but I had another issue, which was an unbelievable amount of DNS traffic bouncing between cluster members

3. On a whim, I did a cpstop/cpstart on the standby member. This stopped the DNS traffic. I failed over and did the same on the active member

4. I reverted the parameter ccl_preserve_src_MAC back to 0 on both members, and the mac address 02:00:00:00:00:00 did not come back

So a bit of a mystery to me, but my gateways are in a better place.

Dave