Most engineers think…
Most people picture a firewall as 'one box that inspects every packet the same way'. On an SRX that mental model breaks in two places and it shows in an interview.
First, an SRX is two engines in one: a Routing Engine (the control plane — Junos, routing protocols, management, building the forwarding table and holding your candidate config) and a Packet Forwarding Engine (the data plane — hardware that actually moves transit traffic). Second, it is flow-based: only the first packet of a flow runs the full gauntlet of screens, route lookup, zone and policy lookup, and services; every later packet of that session takes a quick fast path. Understanding that split is what lets you reason about performance, troubleshoot with the session table, and explain the zones-to-policy flow cleanly.
① Junos & the two planes — the thinker and the mover
Every SRX runs Junos, one modular OS that splits work across two planes. The Routing Engine (RE) is the control plane: it runs the routing protocol processes, system management and the CLI, builds and maintains the routing table, and from it derives the forwarding table. The Packet Forwarding Engine (PFE) is the data plane: purpose-built hardware (ASICs and, on bigger boxes, Services Processing Units) that forwards transit traffic using a local copy of that forwarding table.
Why split them? Because separating 'thinking' from 'moving' is what gives the box performance and resilience. The PFE keeps forwarding from its local copy even if the control plane is busy or churning — so a flapping routing protocol on the RE does not stop traffic already on the data plane. In an interview, the one-liner is: RE thinks and manages, PFE forwards — and the RE pushes the forwarding table down to the PFE.
In an interview, say it in three beats: the Routing Engine is the control plane (it thinks and manages), the Packet Forwarding Engine is the data plane (it moves traffic), and the RE builds the forwarding table and pushes a copy down to the PFE. That copy is why traffic keeps flowing during control-plane churn.
On an SRX, which engine forwards transit traffic and from what?
② Flow-based processing — the session, first path vs fast path
SRX is a flow-based (stateful) firewall: it treats traffic as sessions, not lone packets. A session is identified by six fields — source IP, destination IP, source port, destination port, protocol, and a session token for the zone and virtual router. When a packet arrives the SRX checks the session table for a match.
First path vs fast path
If there is no match, the packet takes the first path (slow path): basic sanity and some screens, then a route lookup to find the egress interface, which determines the to-zone; then a policy lookup (from-zone to to-zone), then services like NAT, before the session is installed with a forward and reverse wing. Every subsequent packet of that flow matches the session and takes the fast path — it reuses the cached decisions, so it skips the heavy lookups and just gets per-packet security applied and forwarded. A few feature sets (like some MPLS) are handled packet-based instead, with no session.
Runs Junos, routing protocols, management and the CLI; builds the routing and forwarding tables and holds the candidate configuration.
ASIC/SPU hardware that forwards transit traffic from a local copy of the forwarding table — keeps moving even if the control plane is busy.
A tracked flow keyed by source IP, destination IP, source port, destination port, protocol and a zone/VR token. First packet builds it; the rest reuse it.
A logical group of interfaces with the same trust level. Bind interfaces to it — an unzoned interface drops all traffic.
Only the first packet of a flow runs the full first path. Saying the SRX re-does route and policy lookup on every packet signals you don't understand flow-based processing. The rest of the flow rides the fast path off the cached session — that's where the speed comes from.
Which packets of a flow take the SRX 'fast path'?
③ Security zones & policies — where the rules live
A security zone is a logical group of interfaces with the same trust level (think trust, untrust, dmz). You bind interfaces to zones; an interface in no zone sits in the null zone and cannot pass traffic at all. Traffic to the box itself is governed by host-inbound-traffic and is dropped by default unless you allow the service (SSH, ping, BGP, etc.). A functional zone like management is separate and its traffic never matches transit policies.
From-zone, to-zone, match, then
A security policy is written for a context = a from-zone/to-zone pair, and each context is an ordered list. Each policy has a match (source-address, destination-address, application) and a then action — permit, deny, reject, plus log/count. Addresses come from per-zone address books; services come from built-in or custom applications (e.g. junos-ssh). Zone-pair policies are checked first; if nothing matches, global policies are checked, and finally a default-deny drops the rest. The interview line: route lookup picks the to-zone, then the from-zone/to-zone context decides permit or deny.
Never close an SRX ticket on 'the rule looks right'. Run show security flow session to see if a session even installed, and show security match-policies / hit-count to see which policy actually matched. Route lookup decides the to-zone, so a rule in the wrong context silently never fires.
▶ Watch a first packet build a session and get permitted
How one new flow is processed end-to-end on the SRX. Press Play for the healthy path, then Break it to see the classic failure.
You bind ge-0/0/1 to no zone at all. What happens to traffic on it?
④ The Junos commit model — candidate config, commit, rollback
Junos does not apply changes as you type. You edit a candidate configuration — a working copy — and nothing happens to live traffic until you run commit. On commit, Junos validates syntax and consistency; if it is clean the candidate becomes the active configuration (saved as juniper.conf.gz) and the previous active config is kept as a numbered rollback file. Junos keeps up to 49 rollbacks.
Safety nets you must name
Use commit check to validate without applying, and commit confirmed to apply with a timer (10 minutes by default): if you don't confirm with a second commit, the box auto-rolls back to the last config — perfect for not locking yourself out over a WAN link. rollback N loads any saved config back into the candidate. This candidate-and-commit model is the single biggest reason engineers trust Junos changes: nothing is live until you say so, and one command undoes a mistake.
Vikram, a network engineer in Pune, faces this
A new policy was meant to let the dmz reach a database in trust, but the app still times out and nothing is logged as denied.
The policy was written in the wrong context — from-zone dmz to-zone trust was never created; traffic falls through to the default-deny in the right context.
Run a flow trace / policy lookup: the session never matches the new policy because route lookup sends it to a different to-zone than the one the policy was written for.
show security match-policies + show security flow sessionWrite the policy in the correct from-zone/to-zone context, fix the address-book entry and the application (e.g. junos-ms-sql), then commit confirmed.
Re-test the app: show security flow session shows an installed session and show security policies hit-count confirms the new policy is matching.
You're changing the firewall over a remote WAN link and fear locking yourself out. Safest command?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why does only the first packet of a flow take the slow path on an SRX? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Routing Engine (RE)
- The control plane — runs Junos, routing protocols, management and the CLI, and builds the routing and forwarding tables; holds the candidate configuration.
- Packet Forwarding Engine (PFE)
- The data plane — ASIC/SPU hardware that forwards transit traffic using a local copy of the forwarding table.
- Forwarding table
- The table of active routes derived from the routing table on the RE and copied down to the PFE for fast lookups.
- Session
- A tracked bidirectional flow keyed by six fields: source IP, destination IP, source port, destination port, protocol and a zone/virtual-router token.
- First path / fast path
- First path = the slow processing of a flow's first packet (lookups + install); fast path = the quick processing of later packets that match the session.
- Security zone
- A logical group of interfaces sharing a trust level. Interfaces must be bound to a zone; an unzoned interface drops traffic.
- Context (from-zone/to-zone)
- The from-zone/to-zone pair a security policy belongs to; each context is an ordered list of policies.
- Address book / application
- Address book = named source/destination addresses; application = a service object (e.g. junos-ssh) used in the policy match.
- Candidate configuration
- A working copy of the config that you edit freely; it only affects the device when you run commit.
- Commit confirmed / rollback
- commit confirmed applies a change with an auto-rollback timer; rollback N restores a saved configuration (up to 49 kept).
📚 Sources
- Juniper Networks — Junos OS Architecture Overview (Routing Engine and Packet Forwarding Engine). juniper.net/documentation/us/en/software/junos/junos-overview
- Juniper Networks — Traffic Processing on SRX Series Firewalls Overview (first path / fast path, session). juniper.net/documentation/us/en/software/junos/flow-packet-processing
- Juniper Networks — Flow-Based and Packet-Based Processing. juniper.net/documentation/us/en/software/junos/flow-packet-processing
- Juniper Networks — Security Zones (interfaces, host-inbound-traffic, functional zones). juniper.net/documentation/us/en/software/junos/security-policies
- Juniper Networks — Global Security Policies and policy ordering. juniper.net/documentation/us/en/software/junos/security-policies
- Juniper Networks — The Commit Model for Configurations (candidate, commit, commit confirmed, rollback). juniper.net/documentation/us/en/software/junos/junos-overview/cli
What's next?
Got the architecture? Next, go hands-on with the SRX CLI — configuring NAT (source/destination/static), IPsec site-to-site VPN, screens for DoS protection, and UTM/IDP — with real set-commands and show outputs you can run in the lab.