Junos SRX Flow Session Debugging: Commands in Order

On an SRX, traffic that "should work" and does not is a session problem far more often than a policy problem. Because the SRX is flow-based, the first packet creates a session and everything afterwards rides on it - so if the session never forms, or forms with the wrong NAT, policy or route, the symptom is silence rather than a log entry. Junos gives you a set of operational commands that answer those questions without committing any configuration, which matters on production firewalls. This is the order to use them in.

1. Are there sessions at all? Filter, do not dump

# sessions between two hosts
show security flow session source-prefix 10.10.1.50 destination-prefix 172.16.8.10

# filter by application
show security flow session application junos-https source-prefix 10.10.1.50

# quick summary counts
show security flow session summary

# detailed view, including NAT pool and policy applied
show security flow session extensive | match "10.10.1.50"

A full show security flow session on a busy firewall is unusable; every useful invocation includes a filter. For chassis clusters, add node 0 or node 1 (or all) so you are reading the node you think you are reading - sessions are per-node, and a failover moves them.

2. Read the session, not just its existence

In the extensive output the fields that matter are the interface list (ingress and egress), the policy name that created the session, any Source NAT pool entry, and the packet and byte counters in each direction. An asymmetric counter - packets in with near-zero bytes out - almost always means the return path is being dropped or routed elsewhere. Junos SRX Source NAT and Destination NAT Configuration explains how a NAT rule misconfiguration produces exactly this signature.

3. Live monitoring without changing the configuration

monitor security flow start source-prefix 10.10.1.50 destination-prefix 172.16.8.10
monitor security flow start flow all-fields
show monitoring security flow
monitor security flow stop

Monitoring commands are operational: nothing is committed and nothing survives a reboot. Note that flow monitoring and configured security flow traceoptions cannot run at the same time - stop one before starting the other.

4. When you must see the packet

# operational capture on the flow (retained in the packet buffer)
request security packet-capture ...
request security packet-filter ...
show security packet-capture ...

# datapath debug with packet dump, higher-end platforms
set security datapath-debug capture-file /var/tmp/cap.pcap format pcap
set security datapath-debug capture-file world-readable
set security datapath-debug packet-filter pf1 source-prefix 10.10.1.0/24
set security datapath-debug action profile ap1 capture packet-dump
set security datapath-debug action profile ap1 trace
show security datapath-debug capture

Datapath debugging is configuration, so it needs a commit - use commit confirmed 5 so the change rolls back automatically if your management session is interrupted. Keep trace files small and time-boxed: a debug left enabled on a production SRX fills /var and takes the node down.

5. Sessions that never form

1. No session, no drops - the packet never reached the SRX, or routing sent it elsewhere. Check show route and interface counters first.
2. Session created, then immediately torn down - the policy matched but application identification or IDP rejected it, or an asymmetric route caused a reset. Look at show security flow session brief state and the security log.
3. Session in the wrong direction - the return traffic is being matched as a new session (seen as two sessions for one flow), which indicates NAT or routing asymmetry.
4. Nothing works after a failover - check session sync status and confirm both nodes agree on the routing. The verification habits in Junos BFD Timers: Liveness Detection That Scales apply to SRX clusters as much as to switches.

Practical tips

• Always capture the zone, policy and NAT in the same output before drawing conclusions - SRX issues are usually a mismatch between the three.
• Time-box your debugging: note the timestamp when you started capture, so log correlation is trivial for the next engineer.
• Keep the session-oriented command set in your runbook; Juniper SRX Troubleshooting Commands: Show, Log and Flow is a useful shortlist to extend.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/show-security-flow-session.html