Juniper SRX Troubleshooting Commands: Show, Log and Flow

When a Juniper SRX firewall misbehaves, the fastest path to the answer is a small set of well-chosen Junos operational commands: flow sessions to see exactly which policy matched a connection, display set to read the configuration as flat lines, rollback compare to see what changed, and traffic monitoring to capture packets. This article collects the most useful SRX troubleshooting commands from TunnelsUP's field guide, with explanations of what each output tells you.

How to Triage an SRX Incident

SRX troubleshooting has one structural advantage over router troubleshooting: the session table tells you, for every connection, which policy matched and in which direction the traffic is flowing. That means you can usually answer the two most important questions — "is this connection even reaching the firewall?" and "which rule allowed or denied it?" — with a single command.

The triage order that works is: configuration history first (did something change?), then health (is the box itself well?), then the session table (is the connection here and which policy did it hit?), then routing and interface state (can the packet get there?), and finally packet capture (what is actually on the wire?). Moving straight to packet capture is the most common mistake: a capture taken before you know which policy should have applied produces a wall of packets and no conclusion.

One habit is worth building early: keep a second terminal open on the neighbour device. SRX faults very frequently turn out to be asymmetric routing, a missing return route, or a NAT configuration on the other side, and being able to check the other end immediately saves a round trip through a change-management queue.

Step 1: Configuration Inspection

user@SRX1> show | display set

Displays the configuration as single set lines instead of stanzas - much easier to search: show | display set | match interface.

The flat view has one further advantage that is easy to miss: it shows the effect of inheritance and groups explicitly. When you are chasing a policy that does not seem to be applied, the flat form makes it obvious whether the address book entry or the application is coming from a group, and whether the value you are reading is the one that is actually in effect. The stanza view hides that in a hierarchy you have to trace by hand.

user@SRX1> show | compare rollback 5

Shows the differences between the active configuration and rollback 5 - invaluable for finding who changed what before an incident.

user@SRX1> show system commit
user@SRX1> show configuration | compare rollback 1
user@SRX1> rollback 5
user@SRX1> show | compare

The companion commands are what turn rollback compare into a workflow. show system commit gives you the timestamps and the user names, which lets you pick the right rollback number instead of guessing. Running rollback N followed by show | compare shows you the delta that would be applied if you committed — a safe way to preview a revert without committing it. Junos keeps a limited number of rollbacks, so if you need to prove what the configuration looked like six months ago you will need the archived configuration files rather than the rollback buffer.

Step 2: Security Flow Analysis

user@SRX1> show security flow session
Session ID: 18999, Policy name: POL-INSIDE-TO-OUTSIDE/6, Timeout: 1632
  In: 172.16.200.43/37689 --> 199.199.199.199/443;tcp, If: ge-0/0/1.0
  Out: 199.199.199.199/443 --> 200.200.200.200/8915;tcp, If: ge-0/0/0.0

Every active connection with the policy that matched it. Filter with show security flow session destination-port 443 or show security flow session summary for aggregate counts.

user@SRX1> show security flow session source-prefix 172.16.200.43/32
user@SRX1> show security flow session destination-prefix 199.199.199.199/32
user@SRX1> show security flow session application junos-https
user@SRX1> show security flow session tunnel
user@SRX1> show security flow session summary node 0

Read the output in three places. The policy name tells you which rule matched — and a /6 or /0 suffix indicates whether the session was permitted or denied, since denied sessions can appear in the table with a deny marker. The In and Out tuples tell you both directions of the flow, including the translated addresses if NAT applied, which is the cleanest way to confirm that source NAT is doing what you expect. The interface names tell you which zones the traffic traversed, and therefore which pair of policies could possibly have matched.

When a session appears but no traffic flows, check the timeout and the session flags rather than concluding the firewall is at fault — a session in a half-open state usually means the return path is missing somewhere downstream. When a session does not appear at all, the packet never reached the firewall, or it was discarded in a screen or flow-level check before a session could be created; show security flow statistics distinguishes the two.

user@SRX1> show security flow statistics
user@SRX1> show security flow status
user@SRX1> show security policies
user@SRX1> show security policies hit-count

The hit-count view is the one people forget, and it is often the fastest way to prove a policy is not matching: a rule with zero hits after the traffic should have arrived is definitive.

Step 3: Health and Alarms

user@SRX1> show chassis routing-engine

A snapshot of CPU, uptime, memory and temperature for each Routing Engine.

user@SRX1> show chassis craft-interface

Front-panel LED status on SRX models with a craft interface.

user@SRX1> show chassis alarms
user@SRX1> show system alarms
user@SRX1> show chassis cluster status
user@SRX1> show chassis cluster interfaces
user@SRX1> show chassis cluster statistics

The cluster commands are essential on any HA pair and are meaningless on a standalone device. On a cluster, a surprising proportion of "policy not working" tickets are actually a redundancy group that failed over, leaving the primary handling traffic for a zone it no longer owns — the status output shows ownership and priority per redundancy group, which makes that immediately visible. For the configuration side, including how fabric and control links are built and what happens when they break, see Juniper SRX chassis cluster configuration.

On health checks, watch the Routing Engine CPU over time rather than at a single instant. An SRX whose RE CPU is pinned at 100% by a control-plane process may still forward traffic perfectly but will fail to commit configuration, which produces a very confusing set of symptoms. show chassis routing-engine shows both the current and the last-one-minute and last-five-minute averages, and the trend matters more than the instantaneous value.

Step 4: Logs and Change History

user@SRX1> show log messages | match "RT_FLOW|UI_COMMIT"

Junos relies heavily on log files under /var/log; the messages file plus commit records show every configuration change with the responsible user: show system commit lists commit history.

user@SRX1> show log messages | last 100
user@SRX1> show log messages | match "RT_FLOW_SESSION_DENY"
user@SRX1> show log interactive-commands | match commit
user@SRX1> show log kmd | last 50

The log tags map onto subsystems in a way that makes filtering precise. RT_FLOW covers session creation and denial, which is the fastest way to answer "why was this blocked?" without enabling any debug — the deny message names the source, destination, port and, on many platforms, the policy that rejected it. UI_COMMIT records configuration commits. kmd covers key management, which is where IKE and certificate errors appear.

Two practical cautions. First, session logging at the default level can generate a very high volume of messages on a busy firewall, so if RT_FLOW entries are absent it may be because logging is not configured for that policy rather than because nothing happened. Second, logs rotate; show log messages.0.gz and the other rotated files hold the window before the most recent one.

Step 5: Traffic Monitoring and Packet Capture

user@SRX1> monitor traffic interface ge-0/0/1

Live packet capture on the interface (control-plane traffic only - transit traffic is not shown without special configuration).

user@SRX1> monitor traffic interface ge-0/0/1 write-file test.pcap

Writes the capture to a pcap file for offline analysis.

user@SRX1> monitor traffic interface ge-0/0/1 matching "host 199.199.199.199 and port 443"
user@SRX1> monitor traffic interface ge-0/0/1 no-resolve size 1500 count 100
user@SRX1> monitor traffic interface ge-0/0/1 layer2-headers write-file l2.pcap

Narrow the capture before you run it. An unfiltered capture on a production uplink produces more data than you can read, and the file can fill the disk on a device with limited storage. The matching option accepts standard tcpdump filter syntax, so you can be as precise as you need. The no-resolve and size options keep the output compact, and layer2-headers is what you want when the question is about VLAN tags or MAC addressing rather than IP.

The limitation stated above is the one that catches people out: on SRX, monitor traffic captures traffic destined to the device itself, not transit traffic. Sessions that traverse the firewall without terminating on it will not appear. When you need to see transit packets, the supported methods are session-level packet capture configured in the security configuration, or flow tracing, rather than the monitor command. Working through Junos monitor traffic packet capture examples first will save you from concluding that traffic is absent when it is merely invisible to this tool.

Step 6: Routing and Interface Checks

user@SRX1> show route
user@SRX1> show interfaces terse
user@SRX1> show arp

Quick triage when traffic is black-holed: confirm the route exists, the interface is up/up, and the ARP entry resolved.

user@SRX1> show route <prefix> detail
user@SRX1> show route forwarding-table destination <prefix>
user@SRX1> show interfaces ge-0/0/1 extensive | match error
user@SRX1> ping 8.8.8.8 source 172.16.200.43 count 5
user@SRX1> show security zones
user@SRX1> show security zones | match "ge-0/0/1"

The zone check belongs on this list and is easy to omit. A perfectly correct route and a perfectly healthy interface still produce no connectivity if the interface is bound to the wrong zone, because the policy lookup is performed against zones, not interfaces. Confirming that each interface sits in the zone you assume is a thirty-second check that resolves a class of fault nothing else on this page will find.

Interface error counters deserve one more remark. Sustained CRC or input errors on an SRX interface almost always indicate a physical problem — a marginal optic, a bad patch lead, a speed or duplex mismatch — rather than a firewall configuration issue, and no amount of policy tuning will fix them. The field-by-field interpretation of Junos interface error output in Junos show interfaces extensive error fields explains which counters indicate which physical fault.

VPN-Specific Quick Checks

user@SRX1> show security ike security-association
user@SRX1> show security ike security-association detail
user@SRX1> show security ike security-association index <n> detail
user@SRX1> show security ipsec security-association
user@SRX1> show security ipsec statistics
user@SRX1> show security ipsec next-hop-tunnels
user@SRX1> show security pki local-cert detail

Work IPsec faults in phase order. If show security ike security-association is empty, phase 1 never came up and debugging phase 2 is wasted effort — look at proposals, pre-shared keys, peer addresses and the kmd log. Once phase 1 is up, show security ipsec next-hop-tunnels confirms that the tunnel is bound to the expected st0 interface and next hop, and show security ipsec statistics shows whether encapsulations and decapsulations are both incrementing. A tunnel with encapsulations climbing while decapsulations stay flat means your side is sending and the peer is not answering, which is either a routing issue beyond the firewall or a mismatch at the far end.

For the full phase-by-phase walkthrough including the debug flags, see IPsec IKEv2 troubleshooting: SA_INIT and IKE_AUTH debugs, and for a working configuration to compare against, Juniper SRX route-based site-to-site IPsec VPN.

FAQ

Why does my session show a policy name but no traffic passes? Check the return path first. The session proves the forward packet matched and was permitted; it does not prove the reply can come back. Confirm the reverse route, the reverse policy (sessions are stateful, so a separate reverse rule is not usually needed, but asymmetric routing breaks this) and NAT in both directions.

A policy should match but hit-count stays at zero. Where do I look? In order: is the interface in the zone you think it is, is the traffic actually arriving at the firewall at all, and is an earlier policy in the sequence matching first? Policy evaluation is top-down and first-match.

Is show security flow session expensive to run? On a heavily loaded device with a large session table, an unfiltered run produces a lot of output and takes noticeable CPU. Always filter by source, destination, port or application.

What is the single most useful command on this list? show security flow session with a filter, because it simultaneously proves reachability, identifies the matched policy and reveals the NAT translation. Everything else on this page is used to explain what that output shows.

Related articles: Juniper SRX 防火墙配置教程, Juniper SRX chassis cluster configuration, and SRX 14-step internet configuration. For zone and policy fundamentals behind the flow table, see Juniper SRX security policy configuration: zones to policy rules.

原文链接：http://www.tunnelsup.com/useful-juniper-srx-troubleshooting-commands