- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Blueprint Architecture for Securing
The AI Factory & AI Data Center
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Hi guys.
How are you?
I have a question, I would appreciate if you could help me.We detected a flapping in a switch that is used to connect the synchronism interfaces.
These interfaces share the same vlan, which is dedicated to forward this sync traffic between the cluster members.
The cluster is in load sharing mode and has a unicast configuration.
The virtual cluster interfaces all have the same VMAC address.
The switch is a Cisco Catalyst, as I had found a SK that reported a known bug for the Cisco Nexus series.
The cluster version is R81.10, so it already has kernel 3.10.
Thank you very much.
Regards.
Some questions for context:
Do you see a mac-flap or an interface up/down, how is portfast configured?
What model of appliance & type of interface is used for Sync?
Can you also confirm the JHF level the system is installed with?
Hi Chris!
We could only see the flapping in the logs, although we do not rule out that there may be some drop and because the buffer was full we could not notice it.
The model is a Cisco Catalyst 2960X with the IOS 15.2 operating system.
Currently they have installed the JHF take 45, with two portfix that TAC provided us, due to other problems that the cluster has had.
Thank you.
Regards.
Is VMAC option checked on cluster object under clusterxl tab?
Hi!!
Yes, the VMAC option is enabled in the cluster object.
Which SK are you referring to?
Hi Val!
The SK I refer to is next, but it is about the Cisco Nexus.
Regards!
I read that article and I see workaround CP has, but not sure if thats something most clients would do, to switch from unicast to broadcast. Even in HA active-standby, CCP mode by default is ALWAYS unicast and works fine. I worked with customer before who also had Cisco Nexus (not sure exact model number), but they never had this issue, though they had cluster XL HA, not load-sharing.
Here are some questions I have:
1) Were you guys always using same switch?
2) If answer to 1 is yes, when did this issue happen originally?
3) If answer to 1 is no, what was behavior previously?
4) How often does the problem happen?
Andy
Hi Andy!
Thank you for your comments.
We had our doubts also with that SK.
Yes, the switch that was used was always the same, although we do not know since when this error started, this flapping happens constantly.
Regards
Ok, fair enough. In that case, me personally, I would either change whats suggested in the sk (though probably not the best idea) OR call Cisco and see what they can offer you as a solution/workaround. There really does not seem to be any other logical option, at least : - )
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 66 | |
| 19 | |
| 13 | |
| 12 | |
| 11 | |
| 10 | |
| 9 | |
| 7 | |
| 7 | |
| 7 |
Tue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY