What happens when your network firewall breaks in the middle of a critical video call or a bank transfer? Every single connection drops, users scream, and your boss is furious. High Availability (HA) solves this by giving your firewall a hot backup that takes over instantly — but only if the two firewalls are perfectly synchronised on every active session.
Jump to a section
A simple way to picture Troubleshooting High Availability and State Synchronization
A busy wedding reception kitchen, set up in a large tent. Two identical mobile kitchens, Kitchen A and Kitchen B, are parked side-by-side. Both are fully stocked and connected to the same prep tables. The head chef runs the show from Kitchen A. Every dish that gets plated — every salmon fillet, every chocolate tart — is logged on a shared clipboard hanging on the wall between the two kitchens. This clipboard represents the state table of every active connection. Kitchen A is the active firewall. Kitchen B is the passive standby firewall, ready to take over instantly.
Suddenly, Kitchen A’s gas line springs a leak. The head chef shouts "Switch to Kitchen B!" The sous chef in Kitchen B looks at the shared clipboard. It shows exactly which orders were in progress: table four’s steak mid-grill, table six’s starter just plated. Kitchen B fires up its stoves and continues cooking without missing a beat. The waiters never notice a delay.
But if the clipboard were missing or outdated — if Kitchen B didn’t know which orders were half-finished — then when Kitchen A failed, Kitchen B would have to start from scratch. Guests would wait forever for their main course. Some orders might even be cooked twice. This is exactly what happens in a firewall cluster when state synchronisation fails. The clipboard is the synchronisation mechanism. If it breaks, the backup cannot seamlessly take over. Troubleshooting HA means checking that clipboard — the synchronisation link — before anything else.
High Availability, or HA, is the practice of pairing two identical firewalls so that one takes over if the other fails. In the Palo Alto Networks world, this is called an HA pair. One firewall is the active unit, handling all traffic. The other is the passive unit, sitting idle but ready. The two are connected by a dedicated HA link — a physical cable that connects their dedicated HA ports. This link carries two critical types of data: heartbeats and state information.
A heartbeat is a tiny "I'm alive" message that each firewall sends to its partner every second. If the passive firewall stops receiving heartbeats from the active firewall, it assumes the active has failed and promotes itself to active. This process is called failover. The goal is for failover to happen in under a second, so users don't notice the switch.
But failover alone is not enough. Imagine the active firewall was handling 10,000 active connections — people downloading files, streaming video, making VoIP calls. If the active fails and the passive takes over without knowing about those connections, every single one of those connections is dropped. The users have to re-establish their connections from scratch. That defeats the purpose of HA.
This is where state synchronisation comes in. Every firewall keeps a state table — a list of every active session, including source IP, destination IP, port numbers, and the current state of the conversation (e.g., "three-way handshake completed", "data transfer in progress"). The active firewall sends updates about every new session, every closed session, and every change in session state to the passive unit over the dedicated HA link. This is called state synchronisation or session sync.
The HA link must be fast and reliable. If it is congested or faulty, the passive firewall's state table becomes stale. In the event of a failover, the new active will have an incomplete picture of who is talking to whom, and it may incorrectly drop legitimate traffic.
Palo Alto firewalls also support link monitoring and path monitoring. Link monitoring checks whether the physical cables connected to the firewall are up. If a critical link goes down, the firewall can trigger a failover even if the firewall itself is still running. Path monitoring goes a step further: it checks whether the firewall can reach a specific IP address (like a next-hop router). If that IP becomes unreachable, the firewall treats it as a path failure and triggers failover.
There are three modes of HA in Palo Alto firewalls:
Active/Passive mode: One firewall is active, one is passive. The passive unit does not process any traffic. This is the most common setup for businesses that need high reliability.
Active/Active mode: Both firewalls process traffic simultaneously. This requires more careful configuration and is typically used in very large data centres.
Active/Active with flow-control: A less common variant that balances sessions between both firewalls in a more controlled manner.
Failover is triggered by several conditions:
Heartbeat failure: No heartbeat received from the active for a configured interval (default is typically 9 seconds, but configurable).
Link failure: A monitored physical link goes down.
Path failure: A monitored IP address becomes unreachable.
Panic or crash: The active firewall experiences a software or hardware failure.
When failover occurs, the old active becomes passive (if it recovers) and the old passive becomes active. This role reversal is called preemption if you configure the original active to take back control once it recovers.
Troubleshooting HA involves checking logs, verifying HA link status, confirming that state synchronisation is enabled and working, and ensuring that the passive firewall's state table matches the active's. Palo Alto provides commands like 'show high-availability state', 'show high-availability link-status', and 'show running session info' to diagnose problems.
The most common problems beginners encounter are: misconfigured HA link IPs, incorrect HA interface setup, firewall versions mismatched (both must run the same PAN-OS version), and session sync not enabled or failing due to high load on the HA link.
In summary, HA is useless without reliable state synchronisation. You must check the synchronisation link, the heartbeat settings, and the state table consistency to guarantee that your backup firewall is truly ready to take over without dropping a single connection.
1. Verify HA Pair Health
Log into the active firewall via CLI and run 'show high-availability state'. Check that the local state is 'active-primary' and the peer state is 'passive'. If the peer state shows 'non-operational' or 'error', the pair is broken. Check the HA log ('show log ha') for specific error messages like 'ha1 link down' or 'session-sync failure'. This step ensures the baseline health of the pair before deeper troubleshooting.
2. Check HA Link Status and Configuration
Run 'show high-availability link-status' to see the status of the control link (ha1) and data link (ha2). Both should show 'up'. If ha1 is down, the firewalls cannot exchange heartbeats and will not recognise each other. If ha2 is down, session synchronisation will not work. Also verify that the IP addresses assigned to ha1 and ha2 interfaces are on the same subnet on both firewalls. Mismatched IPs is the single most common beginner mistake.
3. Verify Session Synchronisation Health
On the active firewall, run 'show high-availability session-sync statistics'. Look for the 'sync percentage' field. It should be 100% or very close. If it is below 100%, run 'show high-availability session-sync' to see which sessions are failing to sync. Common causes include an overloaded ha2 link, mismatched MTU, or running out of session table space on the passive unit. If the percentage is low, do not rely on failover — fix the sync first.
4. Test Manual Failover
On the active firewall, run 'request high-availability suspend'. This forces the active to go passive. The peer should become active within 2-6 seconds. Immediately run 'show session info' on the new active to see if sessions still exist. Then test traffic from a client — can you browse the internet, send a ping? If sessions drop at this stage, the issue is likely incomplete session sync or a missing route on the new active firewall.
5. Investigate Failover Trigger Conditions
Check the configured failover conditions in 'configure high-availability' > 'failover conditions'. Verify that link monitoring is enabled for the correct interfaces and that path monitoring has the correct destination IPs. If a failover happened unexpectedly, run 'show log ha' and filter for 'failover' or 'link-down' to find the trigger. If the firewall failed over because of a flapping interface, disable link monitoring for that interface or increase the failure threshold.
You are an IT administrator for a mid-sized company that processes credit card payments for an online store. Your network relies on a pair of Palo Alto PA-5250 firewalls in an Active/Passive HA configuration. One Tuesday morning, the on-call engineer receives alerts that customers are reporting "Your session has timed out" errors on the checkout page. Users are being forced to re-enter their payment details mid-transaction.
You log into the firewall management interface. Your first instinct is to check the HA status. You run 'show high-availability state' on the active firewall. The output says "Active" for the local device and "Passive" for the peer. The HA link status says "up". The heartbeat count looks normal. But you notice a suspicious statistic: the field "Session sync" says "partial". That is a red flag.
You dig deeper. You run 'show high-availability sync-status' on the active unit. It shows that 15% of sessions are not synchronised to the passive unit. This is the root cause. When the firewall processes a new payment session, it sends the session state to the passive via the HA link. Because the HA link is running at 90% utilisation, the packets carrying session information are being dropped. The passive firewall never learns about many sessions. If a failover occurs — or even if there is a brief hiccup in traffic forwarding — the sessions that were not synchronised get dropped.
You then check the HA link itself. You verify the physical cable is Cat6 and not old Cat5 which cannot handle the speed. You check the MTU (Maximum Transmission Unit) settings — the size of packets allowed on the link. Mismatched MTU causes fragmentation and packet loss. You find that the HA link MTU on the active is 1500 bytes but the passive is set to 9000 bytes. That mismatch is silently corrupting session sync traffic.
Your step-by-step troubleshooting actions:
Confirm both firewalls run the same PAN-OS version and patch level. Mismatched firmware is a leading cause of sync failures.
Verify the HA link interface is configured correctly on both devices, including the same IP subnet for the HA control link and the same IP subnet for the HA data link (if using separate links).
Check the HA link utilisation in the monitoring dashboard. If utilisation exceeds 70%, you need to either increase bandwidth (use a faster interface) or reduce session sync traffic by using session-sync-filtering (only sync certain types of sessions).
Inspect the 'show high-availability session-sync statistics' command to see if the backup is receiving all sessions.
Test failover manually by issuing 'request high-availability suspend' on the active unit. Watch the passive unit become active. Can users still make new credit card payments?
After fixing the MTU mismatch, you re-check the sync status: 100% of sessions are now synchronised. You run a manual failover test. No users report issues. The problem is solved.
The real-world lesson: HA only works if state synchronisation works. Checking the HA link health, MTU, utilisation, and session sync percentage should be your first three steps in any HA troubleshooting.
The PCNSE exam is notorious for testing HA troubleshooting with specific command outputs and tricky scenario questions. You will not be asked to configure HA from scratch. You will be given a problem description and asked to identify the root cause or the correct next step.
Exam topics you must know cold:
The difference between 'show high-availability state' and 'show high-availability session-sync statistics'. The first shows the general state (active/passive). The second shows the percentage of sessions synchronised. The exam loves asking why a firewall fails over but drops connections — the answer is almost always "session sync is incomplete".
The three types of failover triggers: heartbeat failure, link monitoring failure, and path monitoring failure. The exam will present a scenario: "The active firewall is running but its ISP link is down. Should it fail over?" The answer is: only if you have configured link monitoring or path monitoring for that specific interface or IP.
The default timer settings for heartbeat intervals. The standard settings are: heartbeat interval = 2 seconds, dead timer = 6 seconds (3 missed heartbeats). If the question mentions that failover took 10 seconds, they are testing whether you know the timer values.
Active/Passive vs Active/Active. The exam will ask: "Which mode guarantees session preservation?" The answer is Active/Passive if session sync is enabled. In Active/Active, if one firewall fails, the other may have incomplete session information.
The command 'show running session info' on both firewalls. If the session counts differ, session sync is broken.
The role of the HA control link (for heartbeats and management) versus the HA data link (for session synchronisation). The exam will present a scenario where state sync is failing but heartbeats are fine. The trap is that the test-taker assumes everything is working because heartbeats are up. The correct answer is: check the HA data link.
Common exam traps:
They give you a 'show high-availability state' output that says "peer-not-reachable" but the HA link is physically up. The correct answer is: the HA control link IP addresses are misconfigured.
They say "failover happens but sessions are lost" and list two options: "enable preemption" or "check session sync status". The correct answer is always check session sync status. Preemption causes a second failover later, not session loss.
They ask: "Which log shows HA failover reasons?" The answer is the HA log, visible via 'show log ha'. The system log does not contain this detail.
They ask: "What happens if both firewalls become active simultaneously?" This is called a split-brain condition. The correct description: both units forward traffic independently, causing network loops and duplicate NAT translations. The fix is to configure a floating IP for management access and reset one unit.
Key definitions to memorise:
Heartbeat: A keep-alive message sent every 2 seconds.
Preemption: The original active firewall automatically reassumes the active role after recovery (if configured).
Session sync: The process of copying session state from active to passive.
Link monitoring: Checking physical link status.
Path monitoring: Checking reachability to a specific IP address.
Pandemonium: A state where both firewalls believe they are active — also called split-brain.
The PCNSE exam will also test your ability to read a 'show high-availability link-status' output. You must be able to tell which link is the control link versus data link based on the interface names. Practice with CLI outputs from the PAN-OS documentation.
High Availability without working state synchronisation is just a fancy way to drop every connection during a failover.
Always verify session sync percentage using 'show high-availability session-sync statistics' before testing failover.
The HA control link handles heartbeats and management, while the HA data link carries session synchronisation traffic — both must be healthy.
A failover triggered by heartbeat loss takes approximately 6 seconds by default (heartbeat interval of 2 seconds times 3 missed beats).
Link monitoring only checks if the cable is plugged in; path monitoring checks if a remote IP is reachable and is more reliable.
Both firewalls in an HA pair must run identical PAN-OS versions and be the exact same hardware model.
The 'show high-availability state' command tells you roles but not session sync health — never rely on it alone.
Active/Passive mode preserves sessions during failover if session sync is enabled; Active/Active mode may drop sessions even with sync enabled.
These come up on the exam all the time. Here's how to tell them apart.
Active/Passive HA
Only one firewall processing traffic at any time
All sessions are synchronised to the passive unit
Simpler to troubleshoot and maintain
Active/Active HA
Both firewalls process traffic simultaneously
Session synchronisation is more complex and may still drop sessions on failure
Requires careful load-balancing and can cause asymmetric routing issues
Link Monitoring
Checks the physical state of a network interface
Triggers failover if the cable is unplugged or interface goes down
Cannot detect failures beyond the immediate link (e.g., an upstream switch failure)
Path Monitoring
Checks reachability to a specific remote IP address via ICMP or other probes
Triggers failover if the target IP becomes unreachable
Detects upstream failures, such as an ISP router going offline
HA Control Link (ha1)
Used for heartbeats and management communication
Relatively low bandwidth requirement
Must be configured with a unique IP subnet on both firewalls
HA Data Link (ha2)
Used for session state synchronisation traffic
High bandwidth requirement (can saturate under heavy traffic)
Should be a dedicated high-speed interface for best performance
Preemption Enabled
Original active firewall automatically reassumes active role after recovering
Can cause unnecessary failover traffic if the recovered unit is unstable
Useful in environments where specific hardware is preferred
Preemption Disabled
Original active firewall stays passive after recovering
Current active unit continues unless it fails again
More stable in networks with flapping hardware
Mistake
If the HA link is up, state synchronisation must be working perfectly.
Correct
The HA link being up only means the physical cable is connected and the interfaces are up. Session synchronisation could be disabled, mismatched, or overloaded even with a healthy link.
Beginners confuse link status (layer 1/2) with session sync (layer 4-7 functionality). They stop investigating once they see 'link up'.
Mistake
In Active/Passive HA, the passive firewall processes management traffic like SSH logins and web UI access.
Correct
The passive firewall does not process any data or management traffic in Active/Passive mode. It only communicates with the active via the HA link. You must access the management IP of the passive separately if needed.
People assume 'passive' means 'less busy but still functional'. In Palo Alto HA, passive literally means idle except for HA sync.
Mistake
A failover will never drop connections if the HA pair is properly configured.
Correct
Even with perfect session sync, a failover can drop connections if the new active firewall needs to re-establish ARP entries, or if the session timeout expires during the few milliseconds of failover. Some UDP-based and old TCP sessions may still drop.
Marketing hype leads beginners to expect 100% seamless failover. In reality, there is a tiny window of packet loss, and some protocols are not state-synchronised (e.g., multicast streams).
Mistake
Link monitoring and path monitoring are the same thing.
Correct
Link monitoring checks whether the physical cable is plugged in and the interface is up. Path monitoring checks whether the firewall can reach a specific IP address beyond the local router. Path monitoring is more robust because it detects upstream failures.
The names sound similar. Beginners assume 'link' covers everything, but a link can be up while the router on the other end is dead.
Mistake
You can mix different firewall models in an HA pair as long as they run the same PAN-OS version.
Correct
Palo Alto requires both firewalls in an HA pair to be identical model numbers (e.g., both PA-5250). Mixing models is not supported even if they appear similar.
People bring cost-saving suggestions and assume common sense applies. Palo Alto locks HA to identical hardware for performance and feature parity.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This usually means the HA link is connected but the firewalls cannot authenticate to each other. Check the HA pre-shared key or certificate settings on both units. They must match exactly, including case and any trailing spaces.
By default, a failover triggered by heartbeat loss takes about 6 seconds (3 missed heartbeats at 2-second intervals). A failover triggered by link or path monitoring can be configured to happen in as little as 1 second.
No. Palo Alto requires dedicated physical ports for HA functions. The control link (ha1) and data link (ha2) must be separate interfaces. Some models allow using an aggregated Ethernet interface for ha2 for increased bandwidth.
The firewalls will still exchange heartbeats over the control link (ha1) and will remain in active/passive roles. However, session synchronisation will stop. If a failover occurs while ha2 is down, all active sessions will be dropped because the passive firewall has no state information.
Yes, the firewalls synchronise configuration, not just sessions. When you commit changes on the active firewall, they are automatically pushed to the passive via the HA link. You do not need to manually configure the passive.
Split-brain is a rare condition where both firewalls believe they are active and start forwarding traffic simultaneously, causing network loops and duplicate NAT entries. To fix it, you must manually power down one unit or use the 'request high-activity-as-primary' CLI command to force one unit back to passive.
You've finished Troubleshooting High Availability and State Synchronization. Continue through the PCNSE study guide to build a complete picture of the exam.
Done with this chapter?