JNCIA-SEC: Monitoring, logging, and troubleshooting

Monitoring, logging, and troubleshooting

This domain tests operational evidence: sessions, policy counters, logs, and packet-level traces. The exam favors a structured check of interface, zone, policy, NAT, route, and session state rather than random configuration changes.

Core rules

• show security flow session displays live sessions and can show the policy and NAT translation applied. show security policies hit-count proves whether a policy matched.
• show security ike sa and show security ipsec sa verify tunnel state; show log kmd and show log iked help with negotiation failures.
• Security logging can use stream mode to a syslog server. Policy log options include session-init and session-close.
• monitor traffic interface captures packets on an interface; flow traceoptions with a packet filter give detailed path decisions.
• Check the return route as carefully as the forward route. Asymmetric routing can break stateful inspection.

Worked example

Users cannot reach a web server through the SRX. Start with interface status and zone membership, then check the trust-to-untrust policy hit count. If the count increments, the policy matched; inspect show security flow session for NAT and the egress interface. If no session exists, the drop is before session creation: screen, route lookup, or policy. If a session exists but no response, check the return route, NAT translation, and server-side policy. Use monitor traffic on both sides to see whether packets leave and return.

Traps

Do not treat a policy permit as proof of forwarding; routes, NAT, and zones still matter. Do not leave verbose traceoptions running in production. Do not read only session-init logs when you need session-close reason codes. Remember that NAT ordering changes what you see in session output.