topic Re: Reason for Firewall Failover in Firewall and Security Management

Reason for Firewall Failover

cassiolima — Mon, 02 Jun 2025 12:01:45 GMT

For some reason my firewall failed over, I wanted to know why. Using the command shows this:

ADMIN_DOWN PNOTE

What does this mean?

[Expert@firewall-01:0]# cphaprob state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 (local) 3.3.3.1 0% STANDBY fw-01
2 3.3.3.2 100% ACTIVE fw-02

Active PNOTEs: None

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 2)
Event time: Fri May 30 14:34:29 2025

Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: ADMIN_DOWN PNOTE
Event time: Fri May 30 13:26:03 2025

Cluster failover count:
Failover counter: 15
Time of counter reset: Thu Dec 26 17:03:43 2024 (reboot)

[Expert@firewall-01:0]# cphaprob show_failover

Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: ADMIN_DOWN PNOTE
Event time: Fri May 30 13:26:03 2025

Cluster failover count:
Failover counter: 15
Time of counter reset: Thu Dec 26 17:03:43 2024 (reboot)

Re: Reason for Firewall Failover

_Val_ — Mon, 02 Jun 2025 12:34:41 GMT

Actually, if I read your output correctly, there was no failover. At some point, your Standby member was down, and it came back up and assumed Standby role. Your Active GW never changed its role.

The admin_down pnote can be triggered on standby member by many different reasons: policy installation, reboot, or a manual operation. In most of those cases, if the Active role does not move to another GW, it is perfectly normal.

I suggest you look for more information in the following SKs:
https://support.checkpoint.com/results/sk/sk125152
https://support.checkpoint.com/results/sk/sk169359

Re: Reason for Firewall Failover

cassiolima — Mon, 02 Jun 2025 13:06:51 GMT

Tks @_Val_

I checked the logs :

May 30 13:35:58 2025 firewall-01 kernel:[fw4_1];CLUS-120200-1: Starting CUL mode because CPU-06 usage (81%) on the local member increased above the configured threshold (80%).
May 30 13:36:08 2025 firewall-01 kernel:[fw4_1];CLUS-120202-1: Stopping CUL mode after 10 sec (short CUL timeout), because no member reported CPU usage above the configured threshold (80%) during the last 10 sec.
May 30 13:37:30 2025 firewall-01 kernel:[fw4_1];CLUS-120102-1: admin_down PNOTE ON
May 30 13:37:30 2025 firewall-01 kernel:[fw4_1];CLUS-111400-1: State change: ACTIVE -> DOWN | Reason: ADMIN_DOWN PNOTE
May 30 13:37:30 2025 firewall-01 kernel:[fw4_1];CLUS-214704-1: Remote member 2 (state STANDBY -> ACTIVE) | Reason: No other ACTIVE members have been found in the cluster
May 30 13:37:30 2025 firewall-01 kernel:[fw4_1];CLUS-100102-1: Failover member 1 -> member 2 | Reason: ADMIN_DOWN PNOTE

Re: Reason for Firewall Failover

the_rock — Mon, 02 Jun 2025 13:08:28 GMT

Please run below command and send what it shows.

Andy

[Expert@CP-FW-01:0]# cphaprob show_failover

Cluster failover count:
Failover counter: 0
Time of counter reset: Sun Jun 1 18:16:45 2025 (reboot)

Cluster failover history (last 20 failovers since reboot/reset on Sun Jun 1 18:16:45 2025):

No. Time: Transition: CPU: Reason:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

No failover was detected since last reboot/reset

[Expert@CP-FW-01:0]#

As Val said, that message can mean it was triggered by any of below:

[Expert@CP-FW-01:0]# cphaprob -l list | more

Built-in Devices:

Device Name: Interface Active Check
Current state: OK

Device Name: Recovery Delay
Current state: OK

Device Name: CoreXL Configuration
Current state: OK

Registered Devices:

Device Name: Fullsync
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 50675.8 sec

Device Name: Policy
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 50673.9 sec

Device Name: routed
Registration number: 2
Timeout: none
Current state: OK
Time since last report: 53264 sec

Device Name: cxld
Registration number: 3
Timeout: 30 sec
Current state: OK
Time since last report: 53316.1 sec
Process Status: UP

Device Name: fwd
Registration number: 4
Timeout: 30 sec
Current state: OK
Time since last report: 53315.5 sec
Process Status: UP

Device Name: cphad
Registration number: 5
Timeout: 30 sec

Re: Reason for Firewall Failover

cassiolima — Mon, 02 Jun 2025 13:37:17 GMT

@the_rock

[Expert@firewall-01:0]# cphaprob show_failover

Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: ADMIN_DOWN PNOTE
Event time: Fri May 30 13:26:03 2025

Cluster failover count:
Failover counter: 15
Time of counter reset: Thu Dec 26 17:03:43 2024 (reboot)

Cluster failover history (last 20 failovers since reboot/reset on Thu Dec 26 17:03:43 2024):

No. Time: Transition: CPU: Reason:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1 Fri May 30 13:26:03 2025 Member 1 -> Member 2 11 ADMIN_DOWN PNOTE
2 Wed Jan 8 11:59:48 2025 Member 1 -> Member 2 47 USER DEFINED PNOTE
3 Fri Dec 27 12:44:02 2024 Member 2 -> Member 1 52 ADMIN_DOWN PNOTE
4 Fri Dec 27 12:40:27 2024 Member 1 -> Member 2 12 ADMIN_DOWN PNOTE
5 Fri Dec 27 12:32:35 2024 Member 2 -> Member 1 21 ADMIN_DOWN PNOTE
6 Fri Dec 27 12:21:59 2024 Member 2 -> Member 1 22 ADMIN_DOWN PNOTE
7 Fri Dec 27 12:20:01 2024 Member 1 -> Member 2 18 ADMIN_DOWN PNOTE
8 Fri Dec 27 12:19:36 2024 Member 2 -> Member 1 27 ADMIN_DOWN PNOTE
9 Fri Dec 27 12:18:34 2024 Member 1 -> Member 2 13 ADMIN_DOWN PNOTE
10 Fri Dec 27 12:18:05 2024 Member 2 -> Member 1 13 ADMIN_DOWN PNOTE
11 Fri Dec 27 12:02:26 2024 Member 1 -> Member 2 26 ADMIN_DOWN PNOTE
12 Fri Dec 27 12:00:22 2024 Member 2 -> Member 1 49 ADMIN_DOWN PNOTE
13 Thu Dec 26 19:26:39 2024 Member 1 -> Member 2 00 Reboot

[Expert@firewall-01:0]# cphaprob -l list | more

Built-in Devices:

Device Name: Interface Active Check
Current state: OK

Device Name: Recovery Delay
Current state: OK

Device Name: CoreXL Configuration
Current state: OK

Registered Devices:

Device Name: Fullsync
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 5212 sec

Device Name: Policy
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 5209.7 sec

Device Name: routed
Registration number: 2
Timeout: none
Current state: OK
Time since last report: 243335 sec

Device Name: cxld
Registration number: 3
Timeout: 30 sec
Current state: OK
Time since last report: 3.92311e+06 sec
Process Status: UP

Device Name: fwd
Registration number: 4
Timeout: 30 sec
Current state: OK
Time since last report: 3.92311e+06 sec
Process Status: UP

Device Name: cphad
Registration number: 5
Timeout: 30 sec
Current state: OK
Time since last report: 3.92308e+06 sec
Process Status: UP

Device Name: Init
Registration number: 6
Timeout: none
Current state: OK
Time since last report: 3.92308e+06 sec

Device Name: ted
Registration number: 7
Timeout: 600 sec
Current state: OK
Time since last report: 1.9 sec

Device Name: Local Probing
Registration number: 8
Timeout: none
Current state: OK
Time since last report: 1.20708e+06 sec

Device Name: DSD
Registration number: 9
Timeout: none
Current state: OK
Time since last report: 5190.4 sec

Re: Reason for Firewall Failover

the_rock — Mon, 02 Jun 2025 20:03:58 GMT

Seems like whatever was down recovered very quick.

Andy

Re: Reason for Firewall Failover

jimm — Fri, 06 Feb 2026 04:52:54 GMT

Seeing a gateway report as "down" would normally tell me it is incapable of becoming active. Is there a simple way to make this gateway go from "down" to "standby"?

Re: Reason for Firewall Failover

Chris_Atkinson — Fri, 06 Feb 2026 12:31:21 GMT

You will need to resolve whatever pnote / condition that is causing it be down. If you can share the common cluster outputs (perhaps in a new thread) we can guide accordingly.

Re: Reason for Firewall Failover

the_rock — Fri, 06 Feb 2026 12:33:25 GMT

Put it this way. Simplest way could be reboot of that firewall, but even that is not guarantee it would work. As @Chris_Atkinson said, you need to check what pnote is causing the issue.

Please send output from below commands from expert mode:

cphaprob roles

cphaprob state

cphaprob -a if

cphaprob -i list

cphaprob -l list

cphaprob syncstat