- 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
Hi All!
I am preparing to deploy a Spark SMB 2000 cluster HA locally manage. Both devices working at on same license, same NTP time and date, and same firmware version 81.10.17 latest build.
When I attach internet connection to a second device which is on set up from factory setting ( only attached WAN and short connection via LAN port from management PC to LAN1 port) I activate license sucessfully on this device.
After finish First time wizard, i'm putty session to CLI expert mode and input command "fw ctl multik stat" to check core instances ipv4 on both devices and I noticed that after provide this command I see an inconsistent number of core ipv4 instances on both devices:
On primary device is showing proper value 20 ipv4 core instances:
[Expert@Primary]# fw ctl multik stat
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 0 | 56 | 251
1 | Yes | 1 | 124 | 353
2 | Yes | 2 | 145 | 405
3 | Yes | 3 | 85 | 343
4 | Yes | 4 | 114 | 427
5 | Yes | 5 | 116 | 355
6 | Yes | 6 | 143 | 423
7 | Yes | 7 | 97 | 387
8 | Yes | 8 | 126 | 398
9 | Yes | 9 | 123 | 391
10 | Yes | 10 | 141 | 394
11 | Yes | 11 | 127 | 421
12 | Yes | 12 | 96 | 410
13 | Yes | 13 | 119 | 341
14 | Yes | 14 | 123 | 390
15 | Yes | 15 | 115 | 410
16 | Yes | 16 | 118 | 359
17 | Yes | 17 | 126 | 364
18 | Yes | 18 | 109 | 403
19 | Yes | 19 | 159 | 476
[Expert@Primary]# cat /opt/fw1/boot/boot.conf
KERN_INSTANCE_NUM 20
COREXL_INSTALLED 1
KERN6_INSTANCE_NUM 2
On secondary device is showing wrong instances value, even when i tried rebooting
[Expert@Secondary]# fw ctl multik stat
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 0 | 1 | 12
1 | Yes | 1 | 2 | 12
2 | Yes | 2 | 1 | 2
3 | Yes | 3 | 1 | 12
4 | Yes | 4 | 1 | 11
5 | Yes | 5 | 4 | 13
6 | Yes | 6 | 2 | 14
7 | Yes | 7 | 4 | 11
8 | Yes | 8 | 1 | 11
9 | Yes | 9 | 3 | 11
[Expert@Secondary]# FW_BOOT_DIR=/opt/fw1/boot fwboot corexl enable 20
rebooting after input this command and login again as expert mode
[Expert@Secondary]# cat /opt/fw1/boot/boot.conf
KERN_INSTANCE_NUM 16
COREXL_INSTALLED 1
KERN6_INSTANCE_NUM 2
[Expert@Secondary]# fw ctl multik stat
ID | Active | CPU | Connections | Peak
----------------------------------------------
0 | Yes | 0 | 1 | 2
1 | Yes | 1 | 1 | 5
2 | Yes | 2 | 3 | 6
3 | Yes | 3 | 0 | 5
4 | Yes | 4 | 3 | 6
5 | Yes | 5 | 1 | 5
6 | Yes | 6 | 1 | 7
7 | Yes | 7 | 1 | 5
8 | Yes | 8 | 2 | 4
9 | Yes | 9 | 2 | 5
10 | Yes | 10 | 2 | 4
11 | Yes | 11 | 1 | 3
12 | Yes | 12 | 0 | 4
13 | Yes | 13 | 2 | 3
14 | Yes | 14 | 3 | 6
15 | Yes | 15 | 2 | 5
Any ideas what happening?
Okay, I found maybe a solution and perhaps this will solve the problem for me.
I'm leaving this for someone else. It looks like a database corruption issue, luckily it's a secondary device.
I restored the device call as Secondary to factory revert default settings with firmware version 81.10.10, then configured a new settings, including a new internet connection from the command-line interface (CLI), and activated the license via the graphical user interface (GUI). After activation, the license was obtained and is active. Next, I logged into expert mode and checked the output of the command `fw ctl multik stat`, which showed me all the IPv4 cores :). Then of course I created a full backup system, as a test, restarted this device, and then checked again from the CLI in expert mode show me correctly displays the IPv4 core instances. Then I updated the system in one step to the latest version 81.10.17 build 721 and voila, all IPv4 instances are still active 🙂
I would get TAC involved here.
I created a ticket in TAC
Did you try the procedure from sk174423?
Yes, it is written in the subject of this post that after issuing the command FW_BOOT_DIR=/opt/fw1/boot fwboot corexl enable 20 and after restarting it does nothing happen
Let us know what TAC says.
TAC says if this is a new confoguration that he cannot help us, so we must contacting to local partner team
I read the sk Chris referenced and it definitely looks promising.
Hi,
Can you please run in Expert mode:
cat /proc/cpuinfo | grep processor
and share the output from both gateways?
Thanks.
On pirmary output:
[Expert@Primary]# cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15
processor : 16
processor : 17
processor : 18
processor : 19
processor : 20
processor : 21
processor : 22
processor : 23
On secondary: output:
[Expert@Secondary]# cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15
processor : 16
processor : 17
processor : 18
processor : 19
processor : 20
processor : 21
processor : 22
processor : 23
Thanks.
Can you please attach the file $FWDIR/log/boot_log.elg from the Secondary?
Hi Sigal,
I send to you boot log to private message.
Despite the problems and attempts to create an HA cluster beetwen both devices, today an HA cluster was created at some point, but it shows the error so was I expected, so I see that there is a real problem with these IPv4 processors
Look at this error:
Last member state change event:
Event Code: CLUS-113905
State change: STANDBY -> ACTIVE(!)
Reason for state change: Mismatch in the number of CoreXL FW instances has been detected
Event time: Mon Nov 3 10:14:36 2025
Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: Available on member 1
Event time: Mon Nov 3 10:14:36 2025
Cluster failover count:
Failover counter: 1
Time of counter reset: Wed Oct 29 17:56:13 2025 (reboot)
Based on the logs, it seems like the secondary gateway is installed with R81.10.15 and not with R81.10.17.
Can you please check it?
Thanks.
Hi Sigal,
I'm pretty sure that is R81.10.17, let see output command software-version on secondary device:
[Expert@Secondary]# show software-version
This is Check Point's 2000 Appliance R81.10.17 - Build 721
Okay, I found maybe a solution and perhaps this will solve the problem for me.
I'm leaving this for someone else. It looks like a database corruption issue, luckily it's a secondary device.
I restored the device call as Secondary to factory revert default settings with firmware version 81.10.10, then configured a new settings, including a new internet connection from the command-line interface (CLI), and activated the license via the graphical user interface (GUI). After activation, the license was obtained and is active. Next, I logged into expert mode and checked the output of the command `fw ctl multik stat`, which showed me all the IPv4 cores :). Then of course I created a full backup system, as a test, restarted this device, and then checked again from the CLI in expert mode show me correctly displays the IPv4 core instances. Then I updated the system in one step to the latest version 81.10.17 build 721 and voila, all IPv4 instances are still active 🙂
Thanks for that upodate! 👍
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 4 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
Thu 13 Nov 2025 @ 10:00 AM (CET)
Cloud Architect Series - Guarding Generative AI: Next-Gen Application Security with CloudGuard WAFThu 13 Nov 2025 @ 06:00 PM (COT)
Tegucigalpa: Risk Management al Horno: ERM, TEM & Pizza Night para la Comunidad CheckMatesThu 13 Nov 2025 @ 10:00 AM (CET)
Cloud Architect Series - Guarding Generative AI: Next-Gen Application Security with CloudGuard WAFFri 14 Nov 2025 @ 10:00 AM (CET)
CheckMates Live Netherlands - Veriti, Threat Exposure ManagementWed 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 13 Nov 2025 @ 06:00 PM (COT)
Tegucigalpa: Risk Management al Horno: ERM, TEM & Pizza Night para la Comunidad CheckMatesThu 13 Nov 2025 @ 06:00 PM (COT)
Tegucigalpa: Risk Management al Horno: ERM, TEM & Pizza NightAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY