Automation, Troubleshooting, and Operations
Automation, Troubleshooting, and Operations tests how you operate an SRX at scale: Junos scripts and APIs, plus a repeatable method for isolating policy, NAT, routing, and tunnel faults.
Automation
Junos supports commit scripts that validate or modify a candidate configuration, op scripts that run on demand, event scripts triggered by event-options, and SNMP scripts. PyEZ provides Device, Config, and RPC objects for Python automation over NETCONF, typically port 830. The REST API exposes the same RPCs over HTTPS. For security, automation is useful for bulk policy and address-book updates and for compliance checks.
Troubleshooting method
Use show security flow session first: a session proves the first packet passed screen, policy, and NAT. If no session exists, check interface filters, screens, routing, and policy hit counts. Flow traceoptions with a packet filter shows the decision path. For IPsec, check IKE and IPsec security associations separately. For clusters, check show chassis cluster status before chasing data-plane issues.
Worked example
Users cannot reach 198.51.100.10:443. show security flow session destination-prefix 198.51.100.10/32 shows nothing. show security policies from-zone trust to-zone untrust shows no hit count, so policy is not being reached. A filter counter on the ingress interface is incrementing. Reasoning: no session plus no policy hit points upstream of policy, to a filter or screen. Removing the filter term restores service; the traceoptions log confirms the drop.
Traps
- Using commit confirmed and forgetting to confirm; the configuration rolls back.
- Running traceoptions without a packet filter, causing heavy CPU load and huge logs.
- Assuming a dynamic application policy matches immediately; AppID may need to identify the flow first.
- Checking IPsec statistics without first confirming phase 1 is established.