- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
I have 2 checkpoint 6200's (CLuster XL) and 1 HPE 5710 switch (stacked)
I am connecting cp1-eth6 to switch 1 and cp2-eth6 to switch 2.
How do i configure my switch ports?
when i run cphaprob stat it shows that one of my interfaces is down
do we have any sample configuration i can reference?
as the HP switch is my route to LAN i would like these to be trunk ports. I have created SVI on checkpoint.
any help is appreciated.,
Check Point ClusterXL clusters are not multi-chassis when it comes to things like bonding etc, so the switch should not use LACP when configuring a single interface on each cluster member. If you were to create an LACP bond on each cluster member, you would then create two corresponding LACP bonds on the switches, not a single one.
The switches know which gateway is holding the VIP because the active gateway will be the one that responds to ARP requests from network devices looking for the VIP.
Not sure if below may apply to you, as its not HPE switch, but rather Cisco:
By the way, which interface shows as down? Can you send output of below commands please?
cphaprob roles
cphaprob state
cphaprob -i list
cphaprob syncstat
cphaprob -a if
Andy
[Expert@xyz-cp01:0]# cphaprob roles
ID Role
1 (local) Non-Master
2 Master
[Expert@xyz-cp01:0]#
[Expert@xyz-cp01:0]# cphaprob state
Cluster Mode: High Availability (Active Up) with IGMP Membership
ID Unique Address Assigned Load State Name
1 (local) 10.222.222.1 0% DOWN xyz-cp01
2 10.222.222.2 100% ACTIVE xyz-cp02
Active PNOTEs: LPRB, IAC
Last member state change event:
Event Code: CLUS-110800
State change: STANDBY -> DOWN
Reason for state change: Incorrect configuration - Local cluster member has fewer cluster interfaces configured compared to other cluster member(s)
Event time: Mon Jan 16 11:25:28 2023
Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: Interface is down (Cluster Control Protocol packets are not received)
Event time: Mon Jan 16 11:19:29 2023
Cluster failover count:
Failover counter: 15
Time of counter reset: Sat Jan 14 10:07:58 2023 (reboot)
[Expert@xyz-cp01:0]#
[Expert@xyz-cp01:0]# cphaprob -i list
Built-in Devices:
Device Name: Interface Active Check
Current state: problem
Registered Devices:
Device Name: Local Probing
Registration number: 8
Timeout: none
Current state: problem
Time since last report: 2882.3 sec
[Expert@xyz-cp01:0]#
[Expert@xyz-cp01:0]# cphaprob syncstat
Delta Sync Statistics
Sync status: OK
Drops:
Lost updates................................. 0
Lost bulk update events...................... 0
Oversized updates not sent................... 0
Sync at risk:
Sent reject notifications.................... 0
Received reject notifications................ 0
Sent messages:
Total generated sync messages................ 666662
Sent retransmission requests................. 0
Sent retransmission updates.................. 0
Peak fragments per update.................... 2
Received messages:
Total received updates....................... 84545
Received retransmission requests............. 0
Sync Interface:
Name......................................... Sync
Link speed................................... 1000Mb/s
Rate......................................... 10400 [Bps]
Peak rate.................................... 10400 [Bps]
Link usage................................... 0%
Total........................................ 1745 [MB]
Queue sizes (num of updates):
Sending queue size........................... 512
Receiving queue size......................... 256
Fragments queue size......................... 50
Timers:
Delta Sync interval (ms)..................... 100
Reset on Sat Jan 14 15:48:22 2023 (triggered by fullsync).
[Expert@xyz-cp01:0]#
[Expert@xyz-cp01:0]# cphaprob -a if
CCP mode: Manual (Unicast)
Required interfaces: 2
Required secured interfaces: 1
Interface Name: Status:
eth1 UP
Sync (S) UP
Mgmt Non-Monitored
eth6.30 (P) DOWN (2262.7 secs)
S - sync, HA/LS - bond type, LM - link monitor, P - probing
Virtual cluster interfaces: 2
eth1 X.X.X.X
eth6.30 10.54.1.1
[Expert@xyz-cp01:0]#
[Expert@xyz-cp01:0]#
so i have 2 ports on my switch -- Do people typically configure these with LACP? How does the switch not detect a loop?
Does anyone have a sample config? I'm doing active /standby cluster xl if that helps.
I have call with customer shortly and they use clusterXL (HA), so will ask the. I assume eth6.30 is whats connected to your switch? Have you tried bouncing the status or tried another cable just to make sure that can be ruled out?
i removed the LACP configuration and it seems to be working now . still curious how the switch knows where to route the traffic. ie. where the VIP is located (checkpoint 1 or 2)
It would know, because VIP is ALWAYS tied to whichever member is master.
Check Point ClusterXL clusters are not multi-chassis when it comes to things like bonding etc, so the switch should not use LACP when configuring a single interface on each cluster member. If you were to create an LACP bond on each cluster member, you would then create two corresponding LACP bonds on the switches, not a single one.
The switches know which gateway is holding the VIP because the active gateway will be the one that responds to ARP requests from network devices looking for the VIP.
thank you - i was using single LACP on my switch - that was my error .
By the way, I found an issue another client had back in May 2022 and issue was misconfigured vlan on the switch side. Not implying by any means thats your issue, but might be worth checking.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 27 | |
| 23 | |
| 15 | |
| 14 | |
| 12 | |
| 10 | |
| 6 | |
| 6 | |
| 5 | |
| 4 |
Wed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 19 Nov 2025 @ 11:00 AM (EST)
TechTalk: Improve Your Security Posture with Threat Prevention and Policy InsightsThu 20 Nov 2025 @ 05:00 PM (CET)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - AMERThu 20 Nov 2025 @ 10:00 AM (CST)
Hacking LLM Applications: latest research and insights from our LLM pen testing projects - EMEAThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY