Index › Resilience & Scale
Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer

Resilience & Scale

← Back to full guide index

~4 min read
Prerequisites: Firewall Fundamentals & Admin — HA/clustering builds on interface and config-management fundamentals.

High Availability (HA) 47

Learning objectives

  • Explain what an HA pair synchronizes vs. what stays local to each peer
  • Distinguish active/passive from active/active deployment and when to choose each
  • List the failure-detection mechanisms that can trigger a failover

Pairs (or up to 16-member clusters) of firewalls synchronize configuration and session state so a single device failure doesn't take down the network.

Why

A firewall is a mandatory choke point — if it goes down, traffic either stops or (worse) bypasses inspection. HA removes that single point of failure.

How

Two firewalls form an HA pair (or up to 16 as HA-cluster peers), synchronizing network/object/policy config and session state over dedicated HA links. A heartbeat connection detects peer failure. Failover triggers on: monitored interface failure (link monitoring), unreachable destinations (path monitoring), missed heartbeats, or critical hardware/software component failure. Firewall-local settings (management IP, admin profiles, logs, ACC data) are not synced — Panorama is needed for a consolidated cross-pair view.
Active/passive HA uses heartbeat links and failover to move traffic after a fault.
Active/passive HA uses heartbeat links and failover to move traffic after a fault.

Pros

  • Sub-second-to-seconds failover keeps traffic flowing through hardware/software failures
  • Active/active or active/passive modes fit different throughput and design needs
  • Multiple failure-detection mechanisms (link, path, heartbeat, packet-path health) catch different failure modes

Cons

  • Decrypted SSL sessions are not synced — they drop and must re-establish after failover
  • Not supported (or limited to active/passive) on some cloud platforms (e.g. no HA on GCP VM-Series; AWS ELB deployments skip firewall HA entirely)
  • Local-only data (logs, ACC, mgmt IP) means Panorama is effectively required for a unified operational view
  • Doubles hardware/licensing cost per protected segment

Exam trap

Config and session state sync over HA links, but firewall-local data (management IP, admin profiles, logs, ACC statistics) does not sync — and decrypted SSL sessions specifically drop and must re-establish after failover, since decryption state isn't part of the sync. Don't assume a failover is fully seamless for encrypted traffic.
Self-check

Q1. An HA pair fails over mid-session. Users report their encrypted (decrypted-and-reencrypted) sessions dropped, while plaintext sessions continued uninterrupted. Is this expected behavior?

A: Yes — decrypted SSL session state is not synchronized between HA peers, so those sessions must re-establish on the new active firewall, while already-classified plaintext session state generally survives the failover.

Q2. After a successful failover, an admin logs into what was the passive firewall and finds the ACC dashboard shows none of the traffic history from before the failover. Why?

A: ACC data, logs, and the management IP are firewall-local and are not synchronized across the HA pair — Panorama is needed to get a consolidated, pair-wide operational view.

Source: ngfw/administration/high-availability

NGFW Clustering 48

PA-7500 / PA-5540-5580 (newer PAN-OS)

Learning objectives

  • Explain how clustering differs architecturally from legacy active/active HA
  • Identify what HSCI replaces and why that simplifies cabling and failover
  • Recognize that clustering buys redundancy, not additive throughput

A newer alternative to legacy HA for data-center-scale deployments: two firewalls run a dual-active dataplane behind a single active control plane, appearing to the network as one device.

Why

Data centers need very high bandwidth/reliability, and legacy active/active HA's three separate links (HA1/HA2/HA3) and floating IPs add complexity that slows failover and complicates multi-chassis link aggregation.

How

The cluster blends active/active and active/passive HA into one model over a single High-Speed Chassis Interconnect (HSCI) link. Neighboring devices see the pair as a single L2/L3 device. It supports multichassis link aggregation (MC-LAG) and integrates with Cisco VPC, Arista MLAG, and Juniper QFX. Capacity is that of one node (not doubled) — the goal is redundancy, not scale-out throughput.
NGFW clustering connects two active dataplanes over HSCI under a single active control plane.
NGFW clustering connects two active dataplanes over HSCI under a single active control plane.

Pros

  • Failover in under one second — faster than legacy HA
  • Single HSCI connection instead of three separate HA links — simpler cabling/config
  • No floating IPs required; fewer IP addresses consumed overall
  • Configured through Panorama for ease of deployment

Cons

  • Hardware-specific — only supported on select high-end chassis platforms (PA-7500, PA-5540/50/60/70/80 on newer PAN-OS)
  • Combined capacity is still one node's worth, not additive — it buys resilience, not extra throughput
  • Requires a specific, fairly recent Panorama + Clustering Plugin version combination

Exam trap

Clustering combines active/active and active/passive concepts over a single HSCI link — don't confuse it with legacy HA's three separate HA1/HA2/HA3 links. And remember capacity is that of one node, not doubled: clustering is for resilience and fast failover, not scale-out throughput.
Self-check

Q1. A design team wants to double their effective firewall throughput by deploying two chassis in an NGFW cluster. Is this a valid expectation?

A: No — clustering provides redundancy and sub-second failover, but combined capacity remains that of a single node; it does not add throughput.

Q2. What single link replaces the HA1/HA2/HA3 links used by legacy active/active HA in an NGFW cluster deployment?

A: The High-Speed Chassis Interconnect (HSCI) link.

Source: ngfw/administration/ngfw-clustering

Virtual Systems (vsys) 49

Perpetual license beyond base count

Learning objectives

  • Explain what a vsys isolates and what it still shares with other vsys on the same box
  • Describe the admin role hierarchy for vsys (Superuser, Device admin, vsysadmin, vsysreader)
  • Identify the network objects a vsysadmin cannot configure

Separate, logically-independent firewall instances running inside one physical (or VM) firewall — each with its own policy, admins, and traffic separation.

Why

MSSPs need to serve multiple customers, and large enterprises need to separate business units, without buying a physical firewall per tenant.

How

Each vsys is independently managed and its traffic is kept separate from other vsys on the same box. Role-based admin (Superuser, Device admin, vsysadmin, vsysreader) scopes who can see/configure which vsys — a vsysadmin/vsysreader cannot touch shared network-level objects (interfaces, VLANs, virtual routers, IPSec/GRE tunnels, DHCP, DNS proxy, QoS). One vsys can be designated a "User-ID hub" to share IP-to-username mappings across all vsys.
Virtual systems partition one NGFW into independent policy domains with shared User-ID mappings.
Virtual systems partition one NGFW into independent policy domains with shared User-ID mappings.

Pros

  • One HA pair can serve many tenants/business units — big capex/opex savings vs. one firewall each
  • Segmented administration: each tenant controls its own policy without touching others'
  • Enables per-department/customer billing or chargeback for firewall services

Cons

  • Base vsys count varies by platform; scaling beyond it needs a paid Virtual Systems license
  • Not supported on every platform (e.g. PA-220 and PA-800 don't support vsys at all)
  • HA pairs must match vsys capability on both peers, adding a design constraint
  • All vsys still share the same physical dataplane capacity — noisy-neighbor performance impact is possible

Exam trap

A vsysadmin/vsysreader role cannot touch shared network-level objects — interfaces, VLANs, virtual routers, IPSec/GRE tunnels, DHCP, DNS proxy, QoS — those stay under Device administrator control. Also remember vsys is not universal: platforms like the PA-220 and PA-800 don't support it at all.
Self-check

Q1. A vsysadmin for "Tenant A" complains they cannot modify a VLAN interface shared with "Tenant B". Is this a misconfiguration?

A: No — shared network-level objects (interfaces, VLANs, virtual routers, tunnels, DHCP, DNS proxy, QoS) are outside a vsysadmin's scope by design; only a Device administrator or Superuser can change them.

Q2. An MSSP wants to onboard a new customer on a PA-220 using a dedicated vsys for isolation. Will this work?

A: No — the PA-220 (like the PA-800) does not support virtual systems at all; a platform that supports vsys must be used instead.

Source: ngfw/administration/virtual-systems

Module Quiz

1. After an active/passive HA failover, an admin logs into the new active firewall and needs to know what carried over automatically. Which data is synchronized between HA peers by default?

Config, objects, and policy sync over HA links; management IP, logs/ACC data, and decrypted SSL state stay local to each peer.

2. During a scheduled maintenance failover on an active/passive pair, users report their HTTPS sessions (which were being decrypted for inspection) disconnected and had to reconnect, while unencrypted sessions kept flowing. Is this expected?

Decryption state is not part of HA sync, so decrypted sessions drop and re-establish under the new active firewall's policy — a known, expected HA limitation.

3. An engineer is configuring failure-detection for a new HA pair and needs mechanisms that trigger a failover for reasons other than a missed peer heartbeat. Which two mechanisms fit? (Choose two.)

Link monitoring watches interface state and path monitoring watches destination reachability; heartbeat is the peer keepalive mechanism, and Policy Optimizer has nothing to do with HA failover.

4. A data-center team running legacy active/active HA across HA1/HA2/HA3 links wants faster, simpler failover and asks whether NGFW Clustering is worth migrating to. What's the accurate pitch for Clustering?

Clustering replaces HA1/HA2/HA3 with a single HSCI link and fails over in under a second — the value is simplicity and speed, not added throughput.

5. A capacity-planning team assumes deploying an NGFW cluster across two chassis doubles their effective dataplane throughput versus a single chassis. Is this assumption correct?

Clustering is built for resilience and fast failover, not scale-out — combined capacity is not additive across cluster members.

6. Which single link does NGFW Clustering use in place of the separate HA1, HA2, and HA3 links required by legacy active/active HA?

A single HSCI link carries what used to require three separate HA links, simplifying cabling and reducing failover time.

7. An MSSP wants to serve five separate customers on one physical firewall, with each customer administering only their own policy and objects, without buying a firewall per customer. Which capability directly addresses this requirement?

Vsys partitions one physical firewall into logically independent, separately-administered instances — exactly the MSSP multi-tenancy use case.

8. A vsysadmin scoped to "Tenant A" opens a support ticket complaining they cannot modify a VLAN interface shared with "Tenant B." Which objects remain outside a vsysadmin's control by design, requiring a Device administrator instead?

Vsysadmins manage their own policy/objects, but shared network-level infrastructure remains a Device administrator responsibility — this is expected behavior, not a bug.

9. An MSSP is scoping hardware for a new customer that needs dedicated vsys-based isolation. Which platform in this list does NOT support Virtual Systems at all, regardless of licensing?

The PA-220 (and PA-800) do not support vsys at all — a platform must be chosen that supports it before scaling vsys count with a license.
← Software Firewalls: VM-Series & Public CloudManagement & Ops →