HowToFixMe
Upgrade Failure

Juniper EX3400: How to verify image integrity before activating

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.

On Juniper kit the upgrade ritual matters more than the speed. `show version` first, `request support information | save /var/tmp/rsi.txt` second, then the actual `request system software add /var/tmp/junos-install.tgz`, that order on Junos OS saves the most support-case time when something goes wrong on the EX3400 unit.

Integrity verification is non-negotiable. Vendor mirrors get corrupted, internal staging servers serve stale files, and the checksum step on Junos OS is the only thing standing between you and a chassis that boots to a recovery prompt.

What follows is the safe-rollback variant. If you need an in-place upgrade with zero rollback path, this guide is not it. and frankly that is not a thing you should be doing on production gear.

What this guide covers

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

Step-by-step

  1. Copy the image to local flash.
  2. Run the vendor checksum / md5 command.
  3. Compare against the checksum published on the vendor portal.
  4. 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

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.

What changed recently?

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

The answer narrows the root cause to a manageable subset.

Safety + preconditions

Before any work on a Juniper device:

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.

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).

Can I roll this back if something breaks?

Yes for software-level changes (firmware rollback, config rollback). Hardware changes are usually one-way. Always back up settings before starting.

Why is this happening on a brand-new unit?

Out-of-box defects do occur. If you've owned the device under 30 days and the symptom persists after a factory reset, escalate to the seller for replacement under DOA terms before opening a manufacturer support case.

What if my model isn't exactly the same revision?

Cross-check the model code on the rating plate against the manufacturer support page. Major firmware generations sometimes shift the menu path; the option is usually under a similarly-named section.

How long does this fix usually take?

Most users complete the steps in 20-45 minutes the first time, and 5-10 minutes on subsequent runs once the menu paths are familiar.

Topology deep dive: where the EX3400 actually sits

The Juniper EX3400 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 EX3400 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 EX3400 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 EX3400

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 EX3400 that command is one line:

request support information | save /var/tmp/rsi-pre.txt
file copy /var/tmp/rsi-pre.txt scp://[email protected]:/srv/jtac/ex3400-rack-21-pre.txt

The actual image swap on EX3400 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-ex3400-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 EX3400 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 EX3400 I keep a paper cheat-sheet next to the rack. The Junos command grammar is consistent across platforms, but EX3400 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 EX3400 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 EX3400 into a BFSI or government workload there are four boxes to tick before the change advisory board signs off. First, the SBOM. Every EX3400 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 EX3400 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 EX3400 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 EX3400 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 EX3400 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 EX3400 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 EX3400?

Virtual Chassis combines two or more EX3400 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.