Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Copper

Cluster XL - MAC ADDRESS MOVEs

Jump to solution

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

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Copper

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

View solution in original post

0 Kudos
10 Replies
Highlighted
Gold

@GGiorgakis ,

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

 

0 Kudos
Highlighted
Copper
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.
0 Kudos
Highlighted
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.
Regards, Maarten
0 Kudos
Highlighted
Copper
Dear Maarten,

We are not have enable VRRP implementation.
0 Kudos
Highlighted
Admin
Admin

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

0 Kudos
Highlighted
Copper

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

View solution in original post

0 Kudos
Highlighted
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.
0 Kudos
Highlighted

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.

0 Kudos
Highlighted
Copper

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.

 

0 Kudos
Highlighted

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

0 Kudos