HowToFixMe
Deployment Automation

Juniper EX4300-MP: How to push a config change to N devices in parallel

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

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

Automating against Juniper gear at scale means respecting Junos OS as an API surface, not just a CLI. The EX4300-MP platform exposes a structured interface, and request support information | save /var/tmp/rsi.txt plus commit are the two operations that show up in almost every automation pipeline.

I have run automation against Juniper fleets ranging from a dozen units to several thousand, and the failure modes concentrate at credential handling and at the 'activate' step. Plan for both.

Below is a pattern I use in real change pipelines. It is not Hello-World; expect to adapt it to your CMDB, your IPAM, and your JTAC-friendly change format.

What this guide covers

How to push a config change to N devices in parallel for Juniper EX4300-MP (Junos OS).

Step-by-step

  1. Choose the automation surface: vendor controller, API, or CLI scripting.
  2. Verify reachability + credentials from your automation host.
  3. Test the change on a single device + maintenance window.
  4. Roll out in waves of 10-20 devices to limit blast radius.
  5. Pre-collect baseline, push the change, post-collect; diff.
  6. Roll back any device whose post-check fails.

Sample CLI invocation

# Manual baseline
show version
show chassis hardware
show interfaces terse

# Push change (via vendor CLI)
configure
set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.1/24
commit

# Verify
show interfaces terse

Best practices

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:

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

Is it safe to apply during business hours?

If the device is in production use, apply during a scheduled maintenance window. Most procedures need 2-15 minutes of downtime. Capture pre-change state so you can roll back if needed.

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.

Are there safer alternatives for non-technical users?

Yes. the manufacturer's self-service troubleshooter (HP Smart, LG ThinQ, Samsung Members, similar) usually walks through the same steps in a guided UI. Use that first if you're not comfortable with menu paths.

Should I update firmware first or last?

Update firmware first if a release note specifically mentions your symptom. Otherwise, finish the troubleshooting flow first, then update; that way you can isolate whether the update or the underlying fix solved it.

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

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: production-grade automation against EX4300-MP

The thing that surprises a lot of engineers moving from screen-scraping to API is that Junos NETCONF over SSH has been stable since 12.x. On EX4300-MP I run NETCONF on port 830 by default. The minimum config to enable it is three lines:

set system services netconf ssh port 830
set system login class netadmin permissions all
set system login user automation class netadmin authentication ssh-rsa "ssh-rsa AAAA..."
commit comment "Enable NETCONF for automation - INC0078123"

For my BFSI fleet I separate read-only and write-capable accounts. monitor can pull show interfaces extensive all day. change can load merge and commit confirmed 5. The privilege split costs ten minutes to set up and saves a real audit finding later. The RBI cyber resilience inspection in 2025 specifically asked one of my clients for evidence that automation accounts were scoped to least privilege.

For the configuration push itself I prefer load merge terminal relative over set-line snippets because relative paths reduce indentation bugs in templates. The classic mistake is to template a stanza like protocols ospf area 0.0.0.0 interface and forget that set protocols ospf area 0.0.0.0 needs to be its own line in the rendered config. Junos validates on commit, so you do not lose state, but the rollback churn is annoying when you are pushing to 80 devices on a Saturday window.

# Render then push (PyEZ example)
from jnpr.junos import Device
from jnpr.junos.utils.config import Config
with Device(host='10.10.5.21', user='automation', ssh_private_key_file='/home/auto/.ssh/id_rsa') as dev:
    with Config(dev, mode='exclusive') as cu:
        cu.load(path='rendered/ex4300-mp-rack-21.set', format='set', merge=True)
        cu.commit(confirm=5, comment='batch push 2026-06-10')

Last month I migrated 64 access switches in a Pune BFSI DR site this way. Each push was rolled in a wave of 8 devices, with a 90-second settle between waves so the monitoring pipeline could record any link flaps. Total wall time: 41 minutes, including a single rollback on member rack-37 because the template had a stray PoE+ stanza that did not apply on a non-PoE model.

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.