topic Re: Quantum Spark 2560 failover after every configuration change in Firewall and Security Management

Quantum Spark 2560 failover after every configuration change

Branko — Fri, 03 Apr 2026 12:02:55 GMT

Hello,

I have a problem with Quantum Spark 2560.

Whenever I perform any configuration change on the device, the standby member first goes to Down state and then, after a short time, returns back to Standby. This behavior looks like a cluster instability during changes.

Additionally, I am observing that a similar failover happens every night around 04:00, even when no manual changes are performed. In the logs (/var/log/messages), right before the failover occurs, I consistently see entries related to policy installation. In /var/log/messages - Cluster policy installation started

Has anyone experienced similar behavior with Quantum Spark 2560 appliances?
Is this expected behavior during config changes or policy installs, or could it indicate a problem with cluster synchronization or stability?

Any insights or suggestions on what to check would be greatly appreciated!

Re: Quantum Spark 2560 failover after every configuration change

Chris_Atkinson — Sat, 04 Apr 2026 01:28:47 GMT

Please share "cphaprob stat" output from both members...

Out of interest which build of R82.00.10 is used does it end with 2133?

Re: Quantum Spark 2560 failover after every configuration change

the_rock — Sat, 04 Apr 2026 02:28:43 GMT

Locally or centrally managed? Maybe there is specific cron job running?

Re: Quantum Spark 2560 failover after every configuration change

Branko — Mon, 06 Apr 2026 06:03:18 GMT

Hello,

cphaprob stat output gw1:

Cluster Mode: High Availability (Active Up)

Sync Mode: Sync Enabled

ID Unique Address Assigned Load State

1 (local) 172.29.95.241 100% ACTIVE(!)
2 172.29.95.242 0% STANDBY

Active PNOTEs: LPRB, IAC

Last member state change event:
Event Code: CLUS-110305
State change: ACTIVE -> ACTIVE(!)
Reason for state change: Interface LANBOND0.216 is down (Cluster Control Protocol packets are not received)
Event time: Mon Apr 6 06:54:05 2026

Last cluster failover event:
Transition to new ACTIVE: Member 2 -> Member 1
Reason: Incorrect configuration - Local cluster member has fewer cluster interfaces configured compared to other cluster member(s)
Event time: Mon Apr 6 06:53:52 2026

Cluster failover count:
Failover counter: 48
Time of counter reset: Wed Mar 4 12:38:59 2026 (reboot)

cphaprob stat output gw2:

Cluster Mode: High Availability (Active Up)

Sync Mode: Sync Enabled

ID Unique Address Assigned Load State

1 172.29.95.241 100% ACTIVE(!)
2 (local) 172.29.95.242 0% STANDBY

Active PNOTEs: LPRB

Last member state change event:
Event Code: CLUS-114802
State change: DOWN -> STANDBY
Reason for state change: There is already an ACTIVE member in the cluster (member 1)
Event time: Mon Apr 6 06:54:38 2026

Last cluster failover event:
Transition to new ACTIVE: Member 2 -> Member 1
Reason: Incorrect configuration - Local cluster member ha s fewer cluster interfaces configured compared to other cluster member(s)
Event time: Mon Apr 6 06:53:52 2026

Cluster failover count:
Failover counter: 48
Time of counter reset: Wed Mar 4 12:38:59 2026 (reboot)

Version:

The current firmware version is R82.00.10 (998001654)

Re: Quantum Spark 2560 failover after every configuration change

Branko — Mon, 06 Apr 2026 06:10:51 GMT

Hello,

It is locally managed, and there is one cronjob: 0 4 * * * /pfrm2.0/bin/download_update_ip2country.sh

That is exactly why I suspected that whenever configuration change is applied to active, standby changes state to down for 5-10 mins and then from down to standby after some time...

So I wanted to ask if this is normal for qunatum spark?

Re: Quantum Spark 2560 failover after every configuration change

Chris_Atkinson — Mon, 06 Apr 2026 06:48:02 GMT

Based on the outputs I would encourage you to check VLAN 216 config on the relevant trunk ports and to upgrade the firmware to the latest build.

Re: Quantum Spark 2560 failover after every configuration change

Tom_Hinoue — Mon, 06 Apr 2026 07:41:31 GMT

No, it is definitely not normal for the member to flap down/standby upon configuration change, and I doubt the geolocation updatable object update can cause this behavior.

First hand, as Chris mentioned, I also recommend you to upgrade to latest R82.00.10 B2133.

[Some questions to help understanding the issue]
What do you use for your internet connection? Static IP/DHCP/PPPoE?
Do you have any IPv6 interfaces configured?
Is the WAN configured as a cluster with VIP?
Do you have any monitored/non-HA interfaces?