top of page
Search

Palo Alto HA Suspended: CLI Checks When Active-Passive Stops Failing Over

  • Aug 15
  • 2 min read
Palo Alto network security troubleshooting lab
Palo Alto · Techclick CLI troubleshooting lab
P1: the secondary Palo Alto is Suspended. After a power event, nobody can fail over. Users are one chassis away from an outage.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

  • Name the first CLI command to run on Palo Alto for this ticket

  • Separate the layer that is actually broken from the layer people blame

  • Apply one scoped fix instead of a global disable

  • Prove the ticket closed with a session, log, or counter

Quick answer

Run show high-availability state on both peers. If one side is suspended, clear the suspend, confirm HA1/HA2 are up, then fail over only after running-config is synced.

Why this ticket shows up

HA pairs go suspended after a split-brain, a failed link-monitor, or an admin suspend that nobody documented. The dataplane can stay green while failover is dead.

Symptoms operators actually see

  • Dashboard shows Secondary / Suspended

  • No failover during a planned reboot

  • HA1 or HA2 flaps in system logs

  • Config sync last successful hours ago

CLI first — copy this block

Run these on the Palo Alto device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

show high-availability state
show high-availability all
show high-availability link-monitoring
show high-availability path-monitoring
show high-availability state-synchronization
show jobs processed | match commit

How to read that output

State must be Active / Passive, not Suspended. Link-monitor and path-monitor should be up. State-sync age should be seconds, not hours. If one peer is suspended, do not force failover until both sides agree on group 1 priority and running config.

Triage order

  1. Collect show high-availability state from both firewalls in the same minute.

  2. If a peer is suspended, use request high-availability state functional after you know why it suspended.

  3. Confirm HA1 control and HA2 data links are up; a down HA2 means sessions will not sync.

  4. Check path-monitor destinations — a dead monitor IP can keep a healthy box suspended.

  5. Sync running-config, then request high-availability state suspend on the active only during a change window.

Classic traps

What you see

Real cause

Fix

Secondary is green

It is still suspended

Read the State line, not the LED

Failover works in lab

Path-monitor uses a lab-only IP

Change monitor IP to a real next-hop

Config looks same

Candidate not committed on one peer

show jobs processed on both

Proof the ticket is closed

  • Both peers show Active/Passive

  • State sync age under 5 seconds

  • A test suspend/resume moves the floating IP

Say this in an interview

I never trust the HA widget. I read show high-availability state on both peers and I refuse to fail over a suspended box.

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/

Comments

bottom of page