Hardware Failure

Juniper SRX300 partial boot then reload loop: Diagnose & Fix

Q: Where can I find the Juniper official documentation?

https://kb.juniper.net/ — search the product family + feature name.

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance

Vendor	Juniper
Operating system	Junos OS
Category	Hardware Failure
Skill level	Intermediate to advanced
DIY-able?	Yes with CLI access; some scenarios need JTAC + RMA.

Across years of operating Juniper gear I have watched the same hardware-failure pattern repeat: a unit ships fine, runs for two years, then trips on a power-event or a thermal excursion. On Junos OS the recovery path is the same whether the affected unit is from the SRX300 family or something newer.

Before you touch anything, capture state. `show version` and `show chassis environment` dumped to a file is worth more than a screen-cap because JTAC will ask for the exact output when you open the case. Keep the artifact even if the box recovers on its own.

Below I walk through the on-box steps first, then the JTAC escalation path. If you have spares on hand, swap-then-diagnose is usually faster than diagnose-then-swap, but only if you can afford the rack time.

What this guide covers

Diagnose and recover from partial boot then reload loop on a Juniper SRX300.

Step-by-step

Capture the boot console output to a file: this is the single most useful diagnostic.
Verify image integrity (md5sum or vendor checksum).
If the image is corrupt, re-download from the vendor site and copy back.
If the boot output references a hardware error (memory test fail, FPGA fail), open an RMA.
Try booting an older known-good image stored on flash.

CLI / commands

# Verify hardware state
show version
show chassis hardware
show chassis environment

# Collect for JTAC
request support information | save /var/tmp/rsi.txt

When to RMA

Repeated failure after re-seat and power-cycle
Visible burn, scorching, or physical damage
POST or memory diagnostic failure
Hardware crashinfo without a software workaround

Frequently asked questions

Will this work on my specific Junos OS version?

The procedure reflects current Junos OS behaviour. Older releases may need minor syntax adjustments, use the CLI help (? or tab-completion) to verify.

Should I open a JTAC case immediately?

Open one if you suspect hardware failure or the symptom persists after a maintenance-window reload. Make sure your support entitlement is active first.

Where can I find the Juniper official documentation?

https://kb.juniper.net/. search the product family + feature name.

Is this procedure safe in production?

Test in a lab or maintenance window first. Capture pre-change state so you can roll back.

All Juniper fix guides → /juniper/
All vendor guides → /vendors/

Related guides worth a look while you sort this one out:

References

Juniper support portal: https://support.juniper.net
Juniper knowledge base: https://kb.juniper.net/
Juniper security advisories: https://supportportal.juniper.net/s/global-search/Security%20Advisory
Open a case: https://supportportal.juniper.net/s/case

Reference material, not professional advice. Validate against your specific Junos OS version and test in a non-production environment before applying.

What changed recently?

Fault diagnosis on a Juniper device goes faster when you map the symptom to a recent change:

Did firmware update in the last 7 days?
Did the network (router, ISP, VPN) change?
Was the device moved physically?
Did paired devices (phone, hub, app) update?
Were any accessories swapped in or out?

The answer narrows the root cause to a manageable subset.

Safety + preconditions

Before any work on a Juniper device:

Unplug from mains for any internal-access procedure.
Discharge stored energy (capacitors in PSUs, residual battery charge) per manufacturer guidance.
Use ESD-safe handling for boards and modules, no carpet, no wool sleeves.
Avoid moisture; never apply liquids near vents or connectors.
If you smell smoke, see scorch marks, or feel uneven heat, stop and escalate.

Verification checklist

After applying the fix on your Juniper device, confirm:

The original symptom is no longer reproducible.
Related features (status LEDs, app sync, paired accessories) still work.
The device responds to a soft reboot without the fault returning.
Any error codes that were on display have cleared.
Documentation (your service log, the brand companion app) reflects the change.

When to call Juniper support instead

Escalate if:

The same symptom returns within 24 hours of a clean fix.
You see physical damage (burn marks, swollen battery, cracked PCB).
The device is in warranty and a hardware replacement is the cheaper outcome.
Repair requires specialised tools you don't own (alignment jigs, calibration software).
Following the official path keeps the warranty intact, which matters more than the time spent.

Topology deep dive, how the SRX300 actually moves a packet

VCP-trunk (Virtual Chassis Port) on the SRX340 runs at 40 Gbps over the dedicated rear ports. If you cable VCP over the front 10G optics by mistake (a common install error at remote BFSI branches), the stack joins but every inter-member packet eats a hop of latency. Use `show virtual-chassis vc-port` to confirm cabling. The output column should read VCP rather than Network.

The Junos OS RPD (routing protocol daemon) holds the BGP / OSPF tables, and the kernel installs them into the PFE forwarding table via the rpd-to-kernel socket. On a busy NSEL Mumbai colo edge with 1.2 million BGP routes from two ISP feeds (Reliance Jio + Airtel), the rpd memory footprint hits 6.4 GB. The SRX1500 ships 8 GB DRAM, and you will see the RE swap to disk during convergence storms if you do not damp the import. `show route summary` is your friend.

On the SRX300 / SRX340 / SRX1500 platform, the data-plane is built around a Juniper Trio chipset that splits the forwarding pipeline from the routing engine. The implication for an enterprise network engineer is direct: a `show chassis hardware` that reports the Trio PFE as up does not mean the routing engine is healthy. The two clocks run independently. In a BFSI data center, I always check both with `show chassis routing-engine` and `show chassis hardware extensive` before I touch anything.

Configuration walkthrough with Junos commit safety

The Junos commit model is two-stage by default: candidate config first, then `commit`. On a production SRX1500 at a BFSI data center, I always run `commit check` first, then `commit confirmed 5`. The `confirmed 5` flag rolls back automatically after five minutes if you do not run a second `commit` to make it permanent. This single habit has saved me from a midnight session at a colo cage more than once.

Rollback in Junos is granular. `rollback 1` brings back the last commit, `rollback 5` brings back five commits ago, and `show | compare rollback 1` diffs the live config against the previous one. On a Reliance Industries change window, our standard workflow is: open the candidate, `load merge terminal relative`, paste the change, `show | compare`, `commit check`, `commit confirmed 5`, then a final `commit` only after the verification script in `request system commands` passes.

For automation, NETCONF over SSH on port 830 is the standard. `set system services netconf ssh` enables it. Pair this with a service account whose AAA profile in `set system login user` uses `class super-user-local` only (no remote root). On the SRX340 at a BSNL POP in Vijayawada, we run Ansible juniper.device collection against this account, with vault-encrypted RSA 4096 keys. The keys rotate quarterly via a `gpg`-backed CI pipeline.

Troubleshooting commands I keep on the laminated card

show route summary: table sizes per RIB. If inet.0 exceeds 1 million on the SRX1500, you are crowding RPD memory and BGP convergence will degrade.
show system processes extensive | match rpd, rpd memory and CPU. Above 60% sustained, plan an RE upgrade or BGP import filtering.
request support information | save /var/tmp/rsi.txt. the JTAC bundle. Compress with `gzip` and upload via the JTAC case web upload.
request system snapshot, clone the current Junos OS slice to the secondary. Always run this before a firmware add.
show chassis hardware extensive: full inventory including serial numbers, FRU type, version. This is the first command JTAC asks for in any RMA case.
show log messages | last 50, recent syslog. Look for FPC FRU events, PEM events, and any RPD_ABORTED entries.
show interfaces ge-0/0/1 extensive. drops, errors, queue depth, and SFP DDM voltages. The DDM optical RX power should sit between -3 dBm and -7 dBm on a standard 10km SMF link.
show chassis environment, power, temperature, fan tray status. The temperature column reports Marginal before Failed, which gives you a 24-hour window in most BFSI cages to plan a cooling fix.

India compliance and procurement notes (MeitY, DPDP, GeM)

The GeM (Government e-Marketplace) listing for SRX340 at the time of writing is INR 4,87,500 per unit, with SmartNet renewal at INR 85,000 per year. The BoQ for a typical BSE colo deployment includes 2 SRX340 in cluster, 1 EX4300 management switch, 2 RJ45 console servers (Opengear), and the AMC line item for 3 years totalling around INR 14,75,000. The procurement cycle is 90-120 days end-to-end through GeM.

Under DPDP 2023 (Digital Personal Data Protection Act), logs that carry source IP plus a user identifier qualify as personal data. The syslog forwarding configuration on the SRX1500 must therefore include log retention boundaries (typically 180 days hot, 365 days cold) and access control at the SIEM. Splunk RBAC roles aligned to the data controller and processor responsibilities. On a Reliance Industries BFSI rollout, I have seen the legal team push back on raw syslog leaving the Mumbai data center perimeter, so the SIEM forward is to an on-prem instance, not a cloud SaaS.

What this looked like at a real BFSI site

On a Reliance Industries internal network refresh, we standardised the BFSI perimeter on SRX340 clusters. The procurement BoQ landed via GeM at INR 9,75,000 per pair with three-year SmartNet at INR 1,85,000 per box per year. I have seen integrators try to substitute imported grey-market units that fail the MeitY-cleared list on the device serial. If the device fails ITSAR validation at the audit, the whole BFSI compliance package gets a finding, and that delays the network handover by a quarter.

On a Mumbai NSE colo build, two SRX340s were stacked via Junos virtual chassis. The secondary stack member vanished from `show virtual-chassis` after a routine reboot. The fault was a VCP cable that had been crimped against a cable manager during install and was throwing intermittent CRC. We swapped to a DAC, and the stack recovered. The lesson: virtual-chassis cabling at colo sites needs slack and strain relief, not just label compliance.

Extended FAQs from the field

Should the SRX cluster run active-active or active-passive in a BSE colo?

Active-passive (`chassis cluster reth`) is the safer default. Active-active needs careful flow synchronisation tuning and the BFSI NOC must be ready to handle asymmetric paths. On every NSEL colo I have built, we stay active-passive unless the trading throughput specifically demands the doubled forwarding capacity.

How do I verify a Junos OS image before flashing?

Pull the image hash from the JTAC download page (it lists SHA-512). On the device, use `file checksum sha-256 /var/tmp/junos-srxsme-22.4R3.7.tgz` and compare. Mismatch means the file was truncated or tampered, do not flash. On a BFSI environment, the staging server must enforce TLS 1.2+ on the file transfer, and the JTAC web download uses HTTPS by default.

What if `show chassis environment` reports Fan Tray Failed but the unit is cool?

Check the fan tray seating first: at India colo sites, dust loading and vibration from BMS construction nearby can dislodge a tray. Reseat, wait 60 seconds, recheck. If still failed, swap the tray (FRU SRX-FAN-TRAY is field-replaceable on the SRX1500). The tray FRU price is approximately INR 38,000 from the JTAC spares line.

Does the Junos OS upgrade need a maintenance window?

Yes. Even with `commit confirmed` and a dual-RE chassis, the FPC reboots during the package install. On the SRX1500 single-RE platform, this is a 6-8 minute outage. I schedule them in the 02:00-04:00 IST window after coordinating with the BFSI NOC on-call, the upstream Reliance Jio / Airtel ISP, and the downstream switch fabric team.