Which command shows the number of times each security policy rule has matched traffic?

Correct: b. show security policies hit-count lists every policy rule with its match count since boot or last clear. It is the primary tool for detecting shadowed, dead or overly broad rules.

Why does the SRX NOT run a security policy lookup on the second and subsequent packets of an established TCP session?

Correct: c. The first-path creates a session entry storing the policy result, NAT translation and other per-flow data. Fast-path packets look up this entry and reuse the stored results, which is why the SRX can forward established sessions at high throughput.

Traceoptions output shows 'no-reverse-route' for a packet from 10.1.1.1 to 10.2.2.2. What should you check first?

Correct: c. no-reverse-route means the SRX cannot find a session entry for the return packet — classic asymmetric routing. The fix is to ensure both directions of the flow traverse the same SRX path, or to enable asymmetric flow support.

A session table summary shows active sessions at 98% of the platform maximum. What will happen to new connections?

Correct: d. When the session table is nearly full, new first-path connection attempts are dropped silently before the policy engine is even consulted — no deny log, no traceoptions output from a policy hit. Reducing timeouts or upgrading to a higher-capacity platform is the fix.

After fixing an SRX policy issue, a colleague says 'I pinged the server successfully so the fix works.' Why is this insufficient verification?

Correct: a. ICMP is a separate protocol from TCP. A policy may permit ICMP but still deny TCP 443. Verification requires show security flow session filtered to the exact destination and port, confirming the correct policy name and byte counters incrementing in both directions.

Juniper SRX Flow & Session Troubleshooting — First Path, Fast Path & Traceoptions (2026)

Q: Which SRX processing path performs the full security policy lookup, NAT evaluation and screen checks?

Correct: b. Only the first packet of a new connection takes the first path, which performs zone resolution, policy match, NAT evaluation, ALG detection and screen checks, then creates a session entry. Subsequent packets use the fast path and skip that processing.

Q: You want to check active sessions for destination IP 192.168.10.5 only. Which command is best?

Correct: c. The destination-prefix filter on show security flow session restricts output to sessions matching that host, avoiding thousands of lines of unrelated sessions. The other commands serve different purposes.

Q: A traceoptions file shows 'RT: ' next to a policy named 'block-internet'. What does this tell you?

Correct: c. RT: in the trace output means the policy verdict for that packet was deny. The policy name alongside it identifies which rule matched. The session was never created because the first-path dropped the packet.

Q: A security policy shows zero hit-count after a week of production traffic. What is the most likely cause?

Correct: b. Zero hits on a policy that should fire almost always means a broader rule above it in the policy list is catching the traffic first, shadowing this rule. Check the order of rules and compare address/zone/application matches.

Q: An engineer enables security-flow traceoptions with the basic-datapath flag but no packet filter on a 10 Gbps SRX. What is the most serious risk?

Correct: b. Without a packet filter, basic-datapath traces every first-path packet on a busy link. The SPU overhead from writing trace entries at line rate can degrade forwarding and in severe cases crash the process. Always use a source/destination IP packet filter and disable immediately after collection.

Most engineers think…

Most people assume the SRX runs every packet through a full policy lookup and NAT evaluation. That model leads you wrong in every troubleshooting scenario.

The SRX flow engine has two distinct paths. The first path is the expensive one: only the session-opening packet gets zone checks, route lookup, policy match, NAT evaluation and ALG processing. Once a session entry exists, every subsequent packet uses the fast path and skips all of that. Understanding this split tells you exactly where to look — session table for established flows, traceoptions for the first packet that gets dropped before a session is ever created.

① First path vs fast path — how the SRX decides how hard to work

When a packet arrives on an SRX, the flow daemon checks the session table by matching the 5-tuple. If no entry exists, the packet is on the first path — the SRX performs zone resolution, route lookup, security policy match, NAT rule evaluation, ALG detection and screen checks, then creates a session entry with the result. All subsequent packets in the same connection hit the fast path: the session entry is found, headers are rewritten per the stored NAT info, and the packet is forwarded — no policy re-evaluation.

Why does this matter for troubleshooting? A policy deny, a NAT mismatch, or a screen hit only shows up on the first path. If traffic worked yesterday and fails today, check whether the session was torn down (timeout, RST, asymmetric routing) and a new first-path attempt is now being blocked. Conversely, a session stuck in the table long after traffic stopped means a timeout is not firing — look at the timeout counter in the session output.

Figure 1 — First path vs fast path on the SRX

Only the session-opening packet runs the full first-path gauntlet. All subsequent packets skip straight to fast-path forwarding.

Figure 2 — What the SRX checks on the first path

First-path processing layers — each check can drop the packet before the next one runs.

Quick check · Q1 of 10 · Understand

Which SRX processing path performs the full security policy lookup, NAT evaluation and screen checks?

a) Fast path — it handles all packetsb) First path — only the session-opening packetc) Both paths equallyd) Express path for all UDP traffic

Correct: b. Only the first packet of a new connection takes the first path, which performs zone resolution, policy match, NAT evaluation, ALG detection and screen checks, then creates a session entry. Subsequent packets use the fast path and skip that processing.

👉 So far: First path = full policy + NAT + ALG + screen for the session-opening packet only. Fast path = session lookup + rewrite for all subsequent packets in the same flow.

② Reading the session table — show security flow session

The primary diagnostic command is show security flow session. Each session entry shows the session ID, the matched security policy by name, the ingress and egress interfaces, source and destination with ports, protocol, NAT translations, bytes and packets in each direction, and the remaining timeout in seconds.

Useful filters

Add filters to avoid thousands of lines of output: show security flow session destination-prefix 10.1.1.1/32 to narrow to a specific host; show security flow session protocol tcp destination-port 443 for HTTPS flows. The show security flow session summary gives total active sessions versus the platform maximum — a near-full session table is a silent killer that drops new first-path connections without any explicit policy deny log.

🔍

show security flow session

tap to flip

The primary session table command. Shows session ID, matched policy name, interfaces, 5-tuple, NAT translations, bytes/packets, and remaining timeout. Add destination-prefix or protocol filters to narrow output.

📋

show security policies hit-count

tap to flip

Reveals policy utility: zero hits = shadowed or dead rule; huge hits = possibly too broad. Reset counters with clear security policies statistics after tuning to start a fresh baseline.

🔦

security-flow traceoptions

tap to flip

X-rays the first-path journey. Always set a packet filter (source + destination IP) before enabling. Read with show log. Disable and commit immediately after — traceoptions can degrade SPU performance at scale.

⚡

Fast path

tap to flip

After the session entry is created by the first path, all subsequent packets in the same flow skip policy lookup, NAT evaluation and most checks — they just rewrite headers per the stored entry and forward. The fast path is why the SRX scales.

Session summary before you dig deeper

Always run show security flow session summary first. If active sessions are near the platform maximum, new first-path connections are being silently dropped — no policy deny log, no traceoptions output. Fix the table exhaustion before any other troubleshooting step.

▶ Watch a TCP SYN get permitted and a session created

A first-path packet traversing the SRX flow engine end-to-end. Press Play for the healthy path, then Break it to see the classic silent drop.

① SYN arrivesA client sends a TCP SYN to the payment server. The packet hits the SRX ingress interface in the Trust zone.

▼

② First-path checkNo session entry matches the 5-tuple. The flow daemon runs zone check, policy lookup (permit rule found), source NAT evaluation and screen checks — all pass.

▼

③ Session createdA session entry is written with the policy name, NAT translation and timeout. The SYN is forwarded to the Untrust zone interface.

▼

④ SYN-ACK fast pathThe server's SYN-ACK arrives on the return interface, matches the session entry via fast path, headers are rewritten per NAT and the packet is forwarded to the client.

Press Play to step through a healthy TCP SYN being permitted by the SRX. Then press Break it.

Quick check · Q2 of 10 · Apply

You want to check active sessions for destination IP 192.168.10.5 only. Which command is best?

a) show security flow sessionb) show route 192.168.10.5c) show security flow session destination-prefix 192.168.10.5/32d) show security policies detail

Correct: c. The destination-prefix filter on show security flow session restricts output to sessions matching that host, avoiding thousands of lines of unrelated sessions. The other commands serve different purposes.

👉 So far: show security flow session: check session ID, matched policy name, interfaces, NAT translations and remaining timeout. Add destination-prefix or protocol filters to avoid wall-of-text output.

③ Traceoptions — pinpoint exactly where a packet is dropped

When a session never appears in the table — meaning the first-path packet was dropped before a session could be created — security-flow traceoptions is your X-ray. Configure it under set security flow traceoptions file <name> with a flag (basic-datapath is the go-to) and critically a packet filter to limit tracing to a specific source and destination IP pair. Without the packet filter, traceoptions generates enormous log volume and degrades the SPU.

Read the trace file with show log <filename>. Look for the verdict line: RT:<deny> indicates a policy deny, RT:<drop> followed by a reason (e.g. no-reverse-route, screen hit) pinpoints the exact drop cause, and the policy name in the output confirms which rule (or the implicit deny) is matching. Always disable traceoptions immediately after collecting output: delete security flow traceoptions and commit. Since Junos 24.2R1, the local-debug-buf option lets you tune the in-memory trace buffer up to 40,000 lines.

Figure 3 — Traceoptions — one flag, many clues

The basic-datapath flag traces the full first-path journey; the packet filter keeps it surgical.

Traceoptions without a packet filter = SPU stress

Enabling security-flow traceoptions with the basic-datapath flag but no packet filter on a busy SRX traces every single first-path packet and can degrade forwarding performance or crash the SPU under high load. Always scope it to a specific source/destination IP pair and disable immediately after collecting the log.

Quick check · Q3 of 10 · Analyze

A traceoptions file shows 'RT:' next to a policy named 'block-internet'. What does this tell you?

a) The packet was allowed by block-internet and then dropped by NATb) The session was created but timed outc) The packet matched the block-internet policy and was denied at first-pathd) The fast path was bypassed

Correct: c. RT: in the trace output means the policy verdict for that packet was deny. The policy name alongside it identifies which rule matched. The session was never created because the first-path dropped the packet.

👉 So far: Traceoptions: always use a packet filter (src + dst IP), enable only as long as needed, read with show log, then delete and commit. RT: = policy drop; no-reverse-route = asymmetric routing drop.

④ Security policy hit-counts & common fixes

show security policies hit-count lists every configured policy sorted by the number of times it has matched traffic since the last reset. This instantly reveals shadowed rules (hit-count zero for a rule that should be firing — something above it is catching the traffic first), overly broad permit rules (enormous counts that should be multiple narrower rules), and dead rules you can safely remove.

Common fixes

The five issues you will see most often: (1) Policy deny — policy name in the session or trace log does not match what you expected; check zone pair and address book. (2) Asymmetric routing drop — SRX sees the return packet on a different SPU or interface; enable set security flow allow-dns-reply or fix the routing. (3) NAT mismatch — source or destination NAT rule did not apply because zone or address match failed; verify with show security nat source rule all. (4) Session table full — add show security flow session summary and compare active vs maximum; reduce timeouts or upgrade platform. (5) ALG interference — SIP/FTP control channel opens fine but data channel fails; check show security alg status.

Figure 4 — Policy deny vs session table drop

Two common SRX drops look similar but need different fixes — traceoptions tells them apart.

Arjun at a Mumbai fintech company faces this

Application team says HTTPS to the payment gateway (10.20.5.10) worked yesterday but drops silently today. show security flow session shows no active session for the destination.

Likely cause

A routing change moved the return path through a different interface, causing asymmetric routing — the SRX receives the TCP SYN reply on an interface that has no matching session entry and drops it silently.

Diagnosis

show security flow session destination-prefix 10.20.5.10/32 — no session. Enable traceoptions with a packet filter for 10.20.5.10 and look for 'no-reverse-route' or 'asymmetric' in the drop reason.

Operational mode ▸ show security flow session + set security flow traceoptions

Fix

Restore symmetric routing so both directions traverse the same SRX path. If asymmetric routing is unavoidable, enable flow-based asymmetric routing support on the affected zone, or consider using a stateless filter instead.

Verify

Disable traceoptions, retest HTTPS to 10.20.5.10 — show security flow session now shows an active session with the correct policy name and both byte counters incrementing.

Confirm the fix from the session, not a ping

A ping passing proves ICMP is working, not that TCP port 443 is working. After any SRX fix, verify with show security flow session filtered to the exact destination and port, confirm the correct policy name appears in the session, and check that byte counters in both directions are incrementing.

Quick check · Q4 of 10 · Evaluate

A security policy shows zero hit-count after a week of production traffic. What is the most likely cause?

a) The policy is working correctly and blocks high-volume attacksb) A rule higher in the policy list matches the same traffic first — the rule is shadowedc) Hit-counts only increment for UDP trafficd) The session table is full

Correct: b. Zero hits on a policy that should fire almost always means a broader rule above it in the policy list is catching the traffic first, shadowing this rule. Check the order of rules and compare address/zone/application matches.

👉 So far: show security policies hit-count: zero hits = shadowed or dead rule; huge hits = possibly too broad. Verify fixes from the session table, not a ping — session entry + incrementing byte counters = working flow.

🤖 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.

🧠 In your own words

Type one line: what is the difference between a first-path drop and a fast-path drop on an SRX, and how do you find each one? Then compare with the expert version.

Expert version: A first-path drop happens before a session is ever created — the session-opening packet is rejected by a screen, a policy deny, a NAT failure or because the session table is full. You find it by checking show security flow session (no entry for the destination), then enabling traceoptions with a packet filter to see the exact reason (RT:, no-reverse-route, screen hit). A fast-path drop is rarer and means an established session is losing packets mid-flow — check for interface errors, MTU mismatches, or a software upgrade that flushed the session table. The session entry exists but byte counters stop incrementing.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Juniper SRX at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

First path: SRX processing path for the session-opening packet: zone check, policy lookup, NAT evaluation, ALG detection and screen checks. Creates the session entry.
Fast path: SRX processing path for established-flow packets: looks up the existing session entry, rewrites headers per stored NAT info, and forwards. No policy re-evaluation.
Session table: In-memory table of active connections, keyed on 5-tuple. Each entry stores the matched policy, NAT translations and timeout. show security flow session reads it.
security-flow traceoptions: Junos diagnostic feature that logs the first-path journey of matching packets to a file. Must be scoped with a packet filter to avoid SPU performance impact.
Packet filter (traceoptions): A source/destination IP filter applied to traceoptions that limits logging to packets matching those criteria, preventing trace output from flooding the SPU.
show security policies hit-count: Command that lists every security policy rule with the number of times it has matched traffic. Zero hits = shadowed or dead rule.
Asymmetric routing: Condition where forward and return packets traverse different SRX interfaces or nodes. The return packet finds no session entry and is silently dropped (no-reverse-route).
ALG (Application Layer Gateway): SRX feature that inspects control-channel protocols (SIP, FTP, H.323) to dynamically open pinholes for their data channels. Detected and configured on the first path.
Session table exhaustion: Condition where active sessions reach the platform maximum. New first-path connections are silently dropped — no policy log. Detected with show security flow session summary.
RT:: Token that appears in security-flow traceoptions output indicating the packet was dropped by a security policy deny action at first-path processing.

📚 Sources

Juniper Networks — Traffic Processing on SRX Series Firewalls Overview (first path, fast path, session table). juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-srx-devices-processing-overview.html
Juniper Networks — Monitoring Security Flow Sessions — show security flow session reference. juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-session-and-error-handling.html
Juniper Networks — traceoptions (Security Flow) — configuration reference. juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/ref/statement/security-edit-traceoptions-flow.html
Juniper Networks — Monitoring and Troubleshooting Security Policies — show security policies hit-count. juniper.net/documentation/us/en/software/junos/security-policies/topics/topic-map/monitoring-troubleshooting-security-policy.html
Juniper Networks — Flow-Based Sessions on SRX Series Devices. juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-flow-based-session-for-srx-series-devices.html
Juniper Networks — Express Path Overview (fast-path acceleration). juniper.net/documentation/us/en/software/junos/flow-packet-processing/topics/topic-map/security-express-path.html

What's next?

Mastered the flow engine? Next, go deep on Juniper SRX security zones, address books and policy hierarchy — why zone ordering matters and how to build a clean policy set without shadow rules.

Next · All interview lessons → Practice on exam.techclick.in →

Juniper SRX Flow & Session Troubleshooting — First Path, Fast Path & Traceoptions

🎯 By the end you will be able to

Pick where you want to start

First vs fast path

Session table

Traceoptions

Policy & hit-counts

① First path vs fast path — how the SRX decides how hard to work

② Reading the session table — show security flow session

Useful filters

▶ Watch a TCP SYN get permitted and a session created

③ Traceoptions — pinpoint exactly where a packet is dropped

④ Security policy hit-counts & common fixes

Common fixes

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?