HowToFixMe
Upgrade Failure

Juniper EX4300-MP: How to rollback to the previous image after a failed upgrade

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

⚡ At a glance
VendorJuniper
Operating systemJunos OS
CategoryUpgrade Failure
Skill levelIntermediate to advanced
DIY-able?Yes with CLI access; some scenarios need JTAC + RMA.

Upgrade work on a Juniper fleet is mostly about discipline. Junos OS gives you the commands; the failure mode is almost always operator error, wrong image for the platform, integrity not checked, no rollback plan. The EX4300-MP family is no exception.

I always do a one-box pilot before a fleet roll. request system software add /var/tmp/junos-install.tgz on a single representative unit, then 24 hours of soak, then the rest of the fleet in waves. Skipping the soak has bitten me twice.

JTAC will want the exact build string and the upgrade method (CLI vs controller-driven) on every case, so keep that recorded for the change ticket.

What this guide covers

Rollback to the previous image after a failed upgrade on a Juniper EX4300-MP (Junos OS).

Step-by-step

  1. Confirm there's a previous image still on flash.
  2. Set the boot variable to that previous image.
  3. Reboot.
  4. Verify the version is back to the prior release.
  5. Investigate the upgrade failure separately. do not re-attempt without root cause.

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

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.

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

References

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:

How to confirm it's actually fixed

On a Juniper device, the test is rarely "reboot and see". Use this list:

Escalation guide

For a Juniper device, the right escalation depends on impact:

More frequently asked questions

What if the fix returns after a reboot?

Persistent fault returns mean either: a hardware fault (escalate), a configuration that's being overwritten by a sync source (check cloud profiles), or a regression in a recent firmware update (rollback).

How often should I run preventive checks?

Quarterly for most consumer devices; monthly for production / commercial devices. Set a calendar reminder so the device stays healthy between issues.

Will this void my warranty?

Applying official firmware updates and following the user manual will not affect warranty. Opening sealed components, jumping safety circuits, or using third-party parts can void warranty in most jurisdictions.

Does this affect other devices on my network?

Generally no. The procedure is local to this device. Network-side changes (firmware updates that affect TLS, SMB, or routing) are flagged explicitly in the steps.

Will the procedure work on the international variant?

Some features and firmware paths are region-locked. Check the model spec sheet to confirm your variant supports the menu option referenced. If you're outside the US/EU, look for the regional support portal.

Topology deep dive: where the EX4300-MP actually sits

The Juniper EX4300-MP is a 48-port 1G or 10G aggregation switch that I have racked in three kinds of sites: a BFSI data centre core in BKC Mumbai, a brokerage colo cage at NSE Mahape, and a campus distribution layer for a Bengaluru engineering office. Each deployment changes how you think about this box. In the BFSI core it lives below a pair of QFX5120 spines on Virtual Chassis, carrying ToR uplinks at 10G with LACP. In the brokerage colo it terminates trading turret VLANs with strict QoS, and the broadcast domain is small but latency-sensitive. In the campus role it is a wiring-closet switch with PoE+ uplinks and a few uplink fibres back to a Mist controller. The placement decides almost everything else: VLAN count, uplink speed, redundancy posture, and how aggressive you can be with commit-confirmed windows.

Power planning is something a lot of engineers miss until they get a rack survey from the data-centre operator. A single EX4300-MP pulls roughly 90 W idle and bursts to 740 W under full PoE+ load on the long-reach SKU. At an NM4 cage in Chennai my rack PDU was rated 16 A on a single phase, and once I stacked two members with PoE+ the inrush threw a warning on the iPDU. After that I split the pair across A and B feeds and kept current draw under 60 percent of the breaker rating. The Juniper data sheet calls this out, but I have seen new installs ignore it.

Cabling is the next gotcha. On EX4300-MP the Virtual Chassis Ports come up at 40G on the rear, and Juniper ships short DAC cables in the kit. If you spread members across racks you need OS2 fibre with the right transceivers. JNP-QSFP-40G-SR4 is the part I keep on the shelf. Mixing third-party optics is allowed but you will see a Junos warning unless you enable set chassis fpc 0 pic 0 sfpplus pic-mode 10g with the optic vendor name on a custom list. I have not had to RMA over third-party optics, but my JTAC engineer always asks the question first.

Configuration walkthrough: a controlled upgrade on EX4300-MP

Before the upgrade window I always pull the current support information bundle so I have a clean before-snapshot to give JTAC if anything goes sideways. On EX4300-MP that command is one line:

request support information | save /var/tmp/rsi-pre.txt
file copy /var/tmp/rsi-pre.txt scp://backup@10.20.30.40:/srv/jtac/ex4300-mp-rack-21-pre.txt

The actual image swap on EX4300-MP is staged. request system software add validates the image and stages it for the next reboot. I always include no-validate off so Junos checks the local-config compatibility, and reboot off so I control when the swap happens. The relevant line:

request system software add /var/tmp/junos-jinstall-host-ex4300-mp-21.4R3-S5.4-signed.tgz
show system storage
request system reboot at "23:00" message "upgrade window CR-44621"

On a stacked Virtual Chassis the same command rolls members sequentially. The NSSU (Non-Stop Software Upgrade) path on EX4300-MP works on 18.4 and later, but on older 17.x trains you have to do a cold swap. I learnt that on a 2024 deploy at a Chennai brokerage colo where the maintenance window was 03:00 to 05:00 IST: the NSSU path on the older code failed validation, so I had to drop to a cold reboot and lost the trading desks for 4 minutes. Now I always check release notes for NSSU support first.

Rollback on Junos is the safety net most engineers underuse. request system software rollback swaps to the partition holding the previous image, and a reboot brings you back. The hardware keeps two partitions so the swap is atomic. Keep one in mind: rollback does not touch /config, so a fresh config that depends on a new feature will refuse to commit on the old image. rescue configuration is your friend here. Save one before the upgrade.

Troubleshooting commands by platform

On a EX4300-MP I keep a paper cheat-sheet next to the rack. The Junos command grammar is consistent across platforms, but EX4300-MP has a few outputs you only see on this family. Here is the short list I use most:

# Live state
show chassis hardware detail
show chassis environment
show chassis alarms
show chassis fpc
show interfaces extensive ge-0/0/0
show ethernet-switching table
show vlans
show spanning-tree bridge
show route summary
show route protocol ospf
show lldp neighbors

# Captures
request support information | save /var/tmp/rsi.txt
file list /var/log
show log messages | last 200
show log chassisd | last 200

# Forensics on a flap
show interfaces ge-0/0/0 extensive | match "Input errors|Output errors|Carrier transitions"
monitor interface traffic
monitor traffic interface ge-0/0/0 size 1500 count 200 no-resolve

# Forwarding-plane
show pfe statistics traffic fpc 0
show pfe statistics error fpc 0

The forwarding-plane counters are where you find the silent killers. A flapping link with no Input errors at the interface layer but rising drops at the PFE layer points to a hashing or queue issue on the ASIC. I caught that exact pattern on a stacked EX4300-MP at an NSE colo: an L2 trunk to a server NIC was hashing all traffic to one egress queue and the queue was full, but the interface showed clean. show pfe statistics error fpc 0 showed the queue tail drops. Re-pinning the hash on the trunk fixed it without a reboot.

India compliance and deployment notes

If you are deploying EX4300-MP into a BFSI or government workload there are four boxes to tick before the change advisory board signs off. First, the SBOM. Every EX4300-MP I rack has its show version output captured and stored against the asset register. The RBI cyber resilience guidelines and the SEBI cybersecurity framework both expect this. Second, the firmware base. The DPDP Act 2023 has not directly named network firmware, but the CERT-In advisories for switches do, and my BFSI clients have begun requiring quarterly evidence that the deployed Junos train is within 18 months of GA.

Third, the optics. CDOT and MeitY have a list of approved optical components for government deployments. JNP-branded optics clear that list. Third-party optics, even if they fit and work, are flagged. On a 2025 MeitY-cleared deploy at a public-sector bank in Delhi we replaced 240 third-party SR4 optics with JNP-branded units at INR 11,200 per piece. That alone was an INR 26.8 lakh line item, but it cleared the audit.

Fourth, the management plane. SSH must enforce key-based authentication on the automation account, and the password-based login must be limited to the break-glass account stored in the PAM vault. The Junos snippet is short:

set system services ssh root-login deny
set system services ssh protocol-version v2
set system services ssh ciphers aes256-ctr
set system services ssh macs hmac-sha2-512
set system login user automation class netadmin authentication ssh-rsa "ssh-rsa AAAA..."
set system login user breakglass class super-user authentication encrypted-password "$6$..."

The Reliance Jio enterprise circuit team and the Airtel enterprise team both run their own SSH cipher policies. If you peer with their MPLS PE there is no impact, but if you are running an L2 hand-off you may need to align ciphers with their automation. I have rolled that change at a Mumbai BFSI client without issue.

Real-world deployment I did

The deployment that sticks in my head most clearly was a 6-switch EX4300-MP rollout for a Tier-2 BFSI colo at NM4 Chennai in early 2026. The brief was simple: replace ageing aggregation switches that were running a stack of 12 access switches on the trading floor. The constraint was less simple: the change window was 02:00 to 04:30 IST on a Saturday, and the trading desks went live at 09:00 IST on Monday. The kit cost INR 18.4 lakh ex-GST including SmartNet for three years. JNP-QSFP-40G-SR4 optics were an additional INR 67,200 for 6 units. PoE+ was not in scope.

The wave plan was: rack and cable on Friday night with the new switches powered off, push the rendered Junos config via PyEZ on Saturday at 02:05 IST, fail over the trading-floor uplinks at 02:30 IST in pairs, and run validation against the rendered template at 04:00 IST. I had a JTAC engineer on a parallel slack channel from 01:45 IST as a safety net.

The first three pairs failed over cleanly. On the fourth pair the LACP came up but a single VLAN was stuck. The pre-flight show vlans diff said the VLAN was configured. Two minutes of head-scratching later I found that the template had the VLAN ID as 1340 on the trunk but 134 on the access port: a typo in the rendered set file from a template variable. I corrected the line, ran load merge, and commit confirmed 5. Total downtime on that pair: 6 minutes. We finished the window 10 minutes late, at 04:40 IST.

The takeaway: even when your automation is solid, a single template typo will eat 6 minutes of a maintenance window. The fix was to add a unit-test in the CI that asserts every VLAN ID referenced on a trunk also exists on the access side. That test caught two more similar typos in the next four months.

FAQs (extended)

What Junos OS train do you recommend on a fresh EX4300-MP in 2026?

I run 21.4R3-S5 on most of my BFSI fleet. It is the longest-lived 21.4 service release and JTAC has been steady on it. 22.4R3 is also good. Avoid 22.2 because of the known Layer 2 forwarding regression that Juniper documented in PR1707241.

How much should I budget for a 240-port EX4300-MP rollout in India?

For 5 switches plus a 3-year SmartNet renewal plus optics, I have seen quotes between INR 18 and 22 lakh ex-GST depending on the partner. SmartNet alone is INR 1.6 to 2.1 lakh per switch per year. PoE+ adds about 12 to 18 percent to the price of the unit.

Is the EX4300-MP supported on the GeM portal for government tenders?

Yes. Juniper has presence on GeM. The catalogue ID changes between FY cycles, so check the live listing before you anchor a tender to a specific SKU. For MeitY-cleared deployments the JNP-branded optic must be on the BoQ explicitly.

Will the EX4300-MP interoperate with Cisco and HPE on LACP and STP?

Yes. LACP is standards-based and interoperates cleanly. STP works with RSTP. For MSTP you need matching region names and revision numbers on both sides, which I have done many times against a Cisco Catalyst access layer.

What is the difference between Virtual Chassis and EVPN-VXLAN for EX4300-MP?

Virtual Chassis combines two or more EX4300-MP units into one logical switch for the access layer. It is operationally simple but has a blast radius if the master fails. EVPN-VXLAN keeps each switch as its own control plane but federates Layer 2 over an underlay, which is the path Juniper recommends for new builds. For 99 percent of campus access roles I still pick Virtual Chassis.