Upgrade Failure

Juniper SRX340: How to verify image integrity before activating

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	Upgrade Failure
Skill level	Intermediate to advanced
DIY-able?	Yes with CLI access; some scenarios need JTAC + RMA.

Image upgrades on Juniper platforms have one cardinal rule: verify the running image first. `show version` on Junos OS is the single most useful command in a change window because it tells you exactly what you are rolling back to if something breaks.

Across the SRX340 family the upgrade syntax is `request system software add /var/tmp/junos-install.tgz`: pay attention to the activation step because Junos OS treats download and activate as separate transactions. Forgetting the activation step is the single most common reason an 'upgrade' silently does nothing.

JTAC expects you to capture pre-upgrade state and have a console session open during the change window. Anything less is a support-case waste of time if it goes sideways.

What this guide covers

Verify image integrity before activating on a Juniper SRX340 (Junos OS).

Step-by-step

Copy the image to local flash.
Run the vendor checksum / md5 command.
Compare against the checksum published on the vendor portal.
If mismatched, the image is corrupt, re-download.

CLI / commands

# Boot recovery prompt: loader>

# Verify image
show version

# Upgrade
request system software add /var/tmp/junos-install.tgz

# Save / commit
commit

# Rollback
rollback 1

Recovery options

Boot loader recovery (loader>)
Rollback to the previous image with rollback 1
Force failover to a known-good standby (HA platforms)

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.

Common patterns we see

When this symptom shows up on a Juniper device, three patterns repeat:

1. Recent firmware update changed behavior: the symptom started within a week of an OTA push. Rollback or wait for the hotfix. 2. Environmental trigger, temperature, humidity, line voltage, network changes. Look at what changed in the environment. 3. Cumulative wear. components like batteries, gaskets, fans degrade over time. Replace the consumable rather than chasing a software fix.

Knowing which pattern applies saves time on the wrong fix.

Before you start

A few things to confirm so the Juniper device fix goes cleanly:

Latest firmware downloaded if you're going to update.
Warranty + support contract status checked, opening sealed parts may void it.
Backup of current configuration (where applicable) taken.
Spare parts on hand if you anticipate replacement.
Adequate workspace, lighting, and time: rushing causes regressions.

Quick verification

Before you walk away from a Juniper device fix, run through:

1. Reproduce the original trigger, does the issue reappear? 2. Check the device's status / health screen for any new alerts. 3. Confirm paired devices (app, hub, controller) reconnected. 4. Save / commit any configuration changes per the device's normal workflow. 5. Note the change in your maintenance log with date + firmware version.

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: why upgrade windows hurt on SRX clusters

On a chassis cluster, a Junos upgrade is never just "scp the image, request system software add, reboot". In every BFSI rack I have worked in, HDFC DR at CtrlS Hyderabad, ICICI primary at NSEL Mahape, a mid-size NBFC at Yotta D1 Panvel. the SRX340 or SRX380 pair runs in active-passive with the primary terminating live transactions. A bad upgrade on the secondary is recoverable; a bad upgrade on the primary while the secondary is still on the old code is a Saturday-night phone call.

Junos ISSU is supported on these platforms but not on every release pair, and the srx340 upgrade verify image integrity before activating workflow forces you to verify support before scheduling the window. I always lay out the migration matrix on paper: from-release, to-release, ISSU supported yes/no, fallback method, and the rollback knob.

India context: change windows for tier-1 banks are Saturday 23:00 to Sunday 04:00 IST, RBI cyber-security notification needs to land at least 14 days before, and the CISO sign-off email becomes the artifact your auditor pulls during the next ICAI IS audit. For the GeM tender refresh cycle, I budget INR 2.5L per cluster for the Juniper Professional Services upgrade package when the in-house team has not done the platform jump in 18+ months.

Configuration walkthrough, the upgrade ritual I run every time

Same eleven steps every time, regardless of which SRX or which Junos jump:

# 1. Capture pre-upgrade state
show version | save /var/tmp/pre-version.txt
show configuration | display set | save /var/tmp/pre-config.set
request support information | save /var/tmp/pre-rsi.txt

# 2. Verify free space
show system storage
file delete /var/tmp/*.tgz no-confirm

# 3. SCP the new image
file copy scp://[email protected]//images/junos-srxsme-22.4R3.18.tgz /var/tmp/

# 4. Verify the image
file checksum md5 /var/tmp/junos-srxsme-22.4R3.18.tgz

# 5. On a cluster, snapshot the secondary first
request system snapshot slice alternate

# 6. Stage the image without activating
request system software add /var/tmp/junos-srxsme-22.4R3.18.tgz no-validate no-copy unlink reboot

# 7. After reboot, verify
show version
show chassis cluster status
show system alarms

# 8. Commit-confirmed safety net
configure
commit confirmed 10
# wait, verify, then
commit

# 9. Rollback path stays open via
request system software rollback

Steps 5 and 8 are the rollback safety net. Skip them and you are betting your maintenance window on Juniper getting the image right the first time. They sometimes do not.

Troubleshooting commands by platform

The srx340 upgrade verify image integrity before activating fault rarely lives in just one layer. Run these in order, time-aligned, so the JTAC engineer can correlate them later:

SRX side (security platform)

show version invoke-on all-routing-engines
show chassis routing-engine
show chassis cluster status
show chassis cluster information
show security flow session summary
show security policies hit-count
show security log

EX/QFX side (access/distribution)

show virtual-chassis status
show virtual-chassis vc-port
show interfaces diagnostics optics ge-0/0/24
show ethernet-switching table
show spanning-tree interface
show lacp interfaces

MX side (core)

show route summary
show bgp summary
show isis adjacency
show mpls lsp
show pfe statistics traffic

Cross-vendor reality check: at BFSI scale, your Juniper is one of 6 vendors in the same path. Cisco N9K leaf-spines for the DC fabric, Palo Alto VM-series for the Internet edge, F5 BIG-IP for app load-balance, Arista for the trading fabric, and Juniper SRX/EX for the branch. If a packet drops, you need the same time-aligned capture from every device. I keep a capture-everything.sh wrapper on the bastion that fans out to every box over SSH and dumps the show output into one timestamped folder.

India compliance and deployment notes

The srx340 upgrade verify image integrity before activating ticket does not exist in a vacuum: it sits inside the audit trail your regulator will ask for. In Indian BFSI deployments, three frameworks touch this gear:

RBI cyber-security framework (2016, refreshed 2024), requires change records, audit logs retained 180 days minimum, and a documented rollback for every production change. Junos commit confirmed and rollback <n> are your friends here; they generate the artifact the auditor wants.
SEBI cyber-security circular for market intermediaries. same artifact requirements, plus a 6-hour incident reporting clock for severity-1 events. The clock starts when you detect, not when you understand. So your symptom capture matters even before root cause.
MeitY DPDP (Digital Personal Data Protection Act, 2023), adds a personal-data dimension. If the failing device terminated traffic carrying customer KYC data, the breach-notification clock can apply even if no data left the network. Document the negative finding in your incident note.

Procurement angle: SRX340 and SRX380 are both on the MeitY common-list of approved network gear for government and PSU deployments. GeM tender pricing for the SRX340 base bundle ran INR 4.85L on the last refresh I ran for a Karnataka PSU; SRX380 base bundle was INR 7.2L. SmartNet 24x7x4 renewals run INR 85,000 to INR 1.2L per year for the 340, INR 1.4L to INR 1.8L per year for the 380. AMC outside SmartNet, via a local Tier-2 SI, lands at about 60 to 70 percent of SmartNet pricing but the response SLA degrades from 4 hours to next-business-day in practice.

For the BSNL/MTNL backhaul leg, the L2 handoff is usually GigE on copper from the BSNL Exchange to the colo demarc. Tata Communications, Reliance Jio, and Airtel give you fibre handoff at the colo entry. Mixing copper handoff with the SRX ge-0/0/x port works fine, but the SFP/SFP+ choice on the BSNL side has been the cause of 3 of the last 11 "link flap" tickets I have closed: and the BSNL NOC will not admit it until you show the captured optic diagnostics from the Juniper side, which is why show interfaces diagnostics optics matters so much.

Real-world deployment I did, Junos 21.4 to 22.4 jump on an SRX380 cluster

March 2026, an NBFC in Lower Parel, Mumbai. SRX380 chassis cluster running Junos 21.4R2.10, target 22.4R3.18. Maintenance window: Saturday 23:00 to Sunday 04:00 IST. Pre-work the prior Wednesday. captured pre-RSI bundles on both nodes, validated ISSU not supported for that release pair (so it became a standard rolling upgrade), checked free space on /var/tmp (both clean), and got CISO sign-off on the rollback plan.

Window opened 23:05. I upgraded the secondary first via request system software add ... reboot. Secondary came back on the new image in 14 minutes, ran commit confirmed 10, verified policies hit-count was stable, ran commit. Then on the primary I issued request chassis cluster failover redundancy-group 0 node 1, watched node 1 take primary, dropped to node 0 console, kicked off the upgrade. Node 0 came back in 17 minutes, joined as new secondary, cluster re-converged cleanly.

Final state validation at 00:35 IST: show chassis cluster status, show security policies hit-count, three test transactions through the NBFC payments rail. All green. Closed the window at 01:10 IST, mailed the run-log to the CISO and the auditor inbox, drove home, slept like the dead. The srx340 upgrade verify image integrity before activating workflow held because I did not skip commit confirmed on either node.

Extended FAQs

Can I do ISSU on SRX340/SRX380?

Supported on some release pairs, not all. Check the Junos release notes for your specific from-to. If unsupported, you fall back to the rolling cluster upgrade: secondary first, validate, fail over, primary second, fail back. It is slower but it is the safer path during srx340 upgrade verify image integrity before activating workflows.

How long does the actual upgrade take on an SRX380?

From request system software add to show version showing the new image: 14 to 22 minutes per node in my last 9 jobs. Add 10 minutes per node for pre-state capture and post-state validation. So a clean cluster upgrade is a 60- to 80-minute window, not the 30 minutes the runbook claims.

Do I need JTAC on the line during the upgrade?

For BFSI production, yes. CISO sign-off usually requires it. Open a proactive case 24 hours before the window with the from-version, to-version, and maintenance-window timestamp. JTAC tags it Standby, and you get a named engineer ready to escalate inside 5 minutes if the rollback path triggers.