Palo Alto NGFW Architecture & SP3 — How a Packet Actually Flows

Why architecture matters — in interview rooms and at 2 AM

Picture an Indian Speed Post sorting centre. The old way: a parcel crosses eight conveyor stations — one weighs it, the next x-rays it, the next checks the label, the next scans the barcode, and so on. Each station re-reads the parcel from scratch. Now picture a single counter where one trained operator opens the parcel, weighs it, x-rays it, reads the label, and routes it — all in one motion. Same work, one pass, no duplicated effort.

That second picture is Palo Alto's SP3 architecture. It's why a PA-5220 can deliver 9 Gbps of threat-prevention throughput with App-ID, IPS, URL filtering, and AV all enabled simultaneously — while legacy "UTM" boxes from the same era topped out around 1–2 Gbps with the same features turned on.

You'll be asked about this in the first round of nearly every Palo Alto interview. More importantly, when you're on a 2 AM bridge call and the customer says "throughput tank ho gayi PA-5220 pe", the diagnosis lives in this same architecture — usually in session-offload behavior we'll cover further down.

The three planes — management, control, data

A PAN-OS firewall is one chassis but three independent planes running on separate CPU and memory. This separation is the most important architectural fact to commit to memory.

The management plane runs the WebUI you log into, the SSH CLI, the XML API, the commit process, the routing daemon (yes — OSPF / BGP run on MP, not DP), and ships logs to Panorama or syslog. It runs on a regular Intel CPU with its own RAM.

The dataplane is where the firewall actually does its job. It's purpose-built — network processors handle Layer 1–4, security processors do signature matching and SSL crypto, and a flow engine offloads established sessions. On larger models (PA-5450, PA-7050, PA-7080) you get multiple dataplanes per chassis — flows are distributed across them.

Between them sits a small control plane — the messaging fabric that lets MP push config updates to DP and lets DP send "I saw this user-to-IP mapping" lookups back to MP. On smaller boxes (PA-400 series) the control logic is folded into the management CPU; on larger boxes it's distinct silicon.

SP3 — single pass + parallel processing, without the marketing

Palo Alto Networks coined the term Single Pass Parallel Processing (SP3) in their original whitepaper. Marketing strips it down to "fast and secure" — which tells you nothing. Here's what it actually means.

Single pass software

On every other firewall of the early 2010s, a packet got parsed by the IPS engine, then re-parsed by the URL filter, then re-parsed by AV, then re-parsed by the DLP module. Each engine ran in series. Each ran its own decode. A 1500-byte HTTP packet got fully reassembled and re-walked four times.

PAN-OS instead does one stream-based decode. The packet is reassembled once into an application stream. Then App-ID, URL category, AV signatures, IPS signatures, file-type checks, and DLP patterns all match against the same stream, in parallel, in a single hardware pass. The hardware then makes a single allow/drop/log decision.

This is why enabling URL filtering on a PA-5220 costs ≈10% throughput — not 40%. The URL match is happening in the same hardware pass as everything else.

Parallel processing hardware

Inside the DP, Palo Alto uses dedicated silicon for different jobs running concurrently:

• Network Processors (NPUs) — Layer 1–4 work: parse headers, look up sessions in the session table, decrement TTL, apply NAT, transmit.
• Security Processors (SPUs) — Layer 7 work: pattern match against signature databases for AV / IPS / Anti-Spyware, decode App-ID protocols, run regex.
• Crypto Engines — SSL/TLS encrypt + decrypt offload, IPSec ESP encrypt + decrypt. Without these, decryption-heavy boxes would melt their CPUs.
• Flow Engine / Offload — once a session is fully classified (App-ID done, Content-ID scanning settled), the flow engine can take over packet forwarding entirely, bypassing the SPU for subsequent packets in that session.

That last bullet — the flow engine offload — is where most production performance lives or dies. We'll dissect it below.

Day in the life of a packet — the six stages

Every Palo Alto knowledge-base article and every PCNSE study guide refers back to one diagram: the day in the life of a packet. Memorize this. Recite it under interview pressure.

Here's the full table — print this and pin it above your desk for the first month on the job:

If a packet is killed silently in production, the diagnosis always traces back to one of these six stages. Knowing which stage = knowing which CLI command to run. We'll build the full diagnostic ladder in Blog 15 — Traffic Not Passing; for now, just remember the order.

Slowpath vs Fastpath — why the first packet costs more

"Slowpath" doesn't mean slow as in lagging. It means the firewall does everything from scratch for the first packet of a flow: route lookup, NAT policy match, security policy match, session creation. For a TCP three-way handshake, only the SYN goes through slowpath; the SYN-ACK and ACK already have a session.

"Fastpath" is the lookup-and-forward path. The firewall finds the session row, applies the stored NAT translation, decrements TTL, and ships the packet out the egress interface. No policy re-evaluation. No App-ID recomputation. That's why a PA-5220 can do millions of packets per second on fastpath but only thousands of session creations per second on slowpath.

The interview punchline: Connections-per-second (CPS) is a slowpath metric; throughput is a fastpath metric. A box rated 6 Gbps throughput with 130,000 CPS will choke if you slam it with 200,000 short HTTP transactions a second — even at 100 Mbps total bandwidth.

Session offload — the hidden performance lever

Here's where senior engineers separate themselves from L1 troubleshooters. Even fastpath is not free — every packet still hits the SPU for re-evaluation against active App-ID and Content-ID inspectors. To go faster, PAN-OS supports session offload to the Flow Engine.

Three conditions must hold simultaneously for a session to offload:

1. App-ID has reached a final verdict. Not "in progress", not "unknown-tcp", not "incomplete". A concrete application label.
2. Content-ID inspectors are settled. All the security profiles attached to the session's matched rule have finished their early-stream work.
3. No deep inspection still required. If SSL decryption is active or a WildFire file submission is mid-flight, the session stays on the SPU.

Per the official Palo Alto KB on session offload: "A session where APP-ID has not been completed cannot be offloaded. A session where content inspection is not yet finished cannot be offloaded."

PA-Series hardware — slots, line cards, and where the silicon lives

Palo Alto's hardware family ranges from the desk-sized PA-410 to the chassis-class PA-7080. For job-hunting, you only need to remember three families:

• PA-400 / PA-440 / PA-460 series — branch / SMB. Single dataplane, fixed config, no line cards. Throughputs 800 Mbps – 3 Gbps.
• PA-3200 / PA-5200 / PA-5400 series — campus / mid-enterprise / data centre edge. Multiple dataplanes (PA-5220 has 3, PA-5260 has 3, PA-5450 modular). Throughputs 5 – 40 Gbps with App-ID + threat prevention.
• PA-7000 / PA-7050 / PA-7080 — chassis-class core. Modular line cards — each Network Processing Card (NPC) is effectively its own dataplane equivalent. Up to 10 NPCs per chassis. Multi-hundred-Gbps throughput.

The PA-5450 introduced a new architecture: Management Processor Card (MPC), Networking Card (NC), and Data Processor Card (DPC) are now physically replaceable blades. If a DPC fails on a PA-5450, you swap that single card — no full chassis RMA. This is per the official PA-5400 hardware reference guide.

VM-Series — dataplane cores in the cloud

On VM-Series (Palo Alto's virtual NGFW for AWS, Azure, GCP, KVM, ESXi), the same plane separation exists — but now you choose how many vCPUs go to MP vs DP. The licence ties to total vCPU count; the split between MP and DP is configurable on supported tiers.

set system setting dp-cores 6
commit

admin@PA-VM> show plugins vm_series mode

Mode: standalone
DP cores: 6
MP cores: 2
Total cores: 8
Status: Reboot required if dp-cores changed.

The default on a fresh 8-vCPU deployment is 2 MP + 6 DP — sane for most workloads. If you're seeing high MP CPU because of heavy log forwarding to a Panorama collector, reduce DP to 5 and bump MP. If you're a decryption-heavy edge box, keep MP at 2 and push everything else to DP. The official VM-Series customization docs cover the per-licence-tier maximums.

Verification — the commands you'll actually run

show running resource-monitor minute

Resource monitoring sampling data (per minute):

DP 0:
CPU load (%) during last 60 seconds:
core   0   1   2   3   4   5
       28  31  29  34  27  30   (avg ~30%)

MP:
CPU load (%) during last 60 seconds:
core   0   1
       18  22  (avg ~20%)

show session info

Number of sessions supported:           2097152
Number of allocated sessions:           421,308
Number of active sessions:              418,742
Number of active TCP sessions:          312,890
Number of active UDP sessions:          104,221
Number of active ICMP sessions:           1,631
Session table utilization (%) :             20%
Hardware session offload :                    True
Hardware UDP session offload :                True
Number of sessions in offload :          287,994

show session all filter application unknown-tcp | match "id "

(no lines returned — 0 sessions stuck at unknown-tcp)

# If you see thousands of "id N" lines here, App-ID is not concluding
# on a major flow — investigate the source app / endpoint.

show counter global filter severity drop packet-filter yes delta yes

Global counters:
Elapsed time since last sampling: 1.234 seconds

name                                value     rate severity  category  aspect    description
----------------------------------------------------------------------------------------------
flow_policy_deny                    1,847      1497  drop      flow      pktproc   Session setup: denied by policy
flow_no_session_match                  92        74  drop      flow      pktproc   No session match
flow_action_close                      31        25  info      flow      pktproc   TCP sessions closed via RST

The show counter global command is the single most powerful PAN-OS diagnostic. Every drop has a named counter; every named counter tells you which stage killed the packet. We'll build the full counter map in Blog 15.

Common mistakes that cost you the L1 / L2 interview

Pro tips from the field