Juniper EX2300: How to zero-touch provisioning

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

What this guide covers

How to zero-touch provisioning for Juniper EX2300 (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

• Always test on a single device or sandbox before fleet rollout.
• Keep configurations in version control (Git).
• Use AAA + RBAC for the automation account; never embed credentials in code.
• Build pre/post-change validation into your pipeline.

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

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

Related fixes

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

• Juniper EX3400: How to zero-touch provisioning
• Juniper EX4300-MP: How to zero-touch provisioning
• Juniper EX2300 all ports dead: Diagnose & Fix
• Juniper EX2300: How to back up configs nightly to a Git repo
• Juniper EX2300: How to deploy with a Python script (paramiko / netmiko / native API)
• Juniper EX2300: How to deploy with Ansible

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.

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.

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.

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

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.

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.

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

Last quarter I worked a Juniper EX2300 refresh at a BFSI branch access fabric, NSE colo Mumbai for a private bank moving off an ageing legacy access fabric. The site was a primary trading floor distribution layer with a sister colo in Bengaluru on the DR side, SD-WAN tunnels between them on Tata Comm and Airtel IPLC, and roughly 2,400 wired endpoints behind the Juniper access pods. The way you think about juniper ex2300: how to zero-touch provisioning on a Juniper EX2300 changes when you actually own the runbook at 2 am on a settlement day.

For India BFSI data centers I see three reference designs come up again and again. Design A: collapsed core with a single EX2300 pair in MC-LAG handling both distribution and access, dual uplinks into an MX core, EVPN-VXLAN above. Cheap to buy, expensive to grow. This suits a sub-1,000-port branch hub. NSE-listed mid-caps use this at their regional offices.

2. Design B: three-tier with the EX2300 as the access layer, EX4400 or QFX5120 as distribution, MX480 as the core. This is the canonical BFSI reference architecture for a Mumbai BKC trading colo with 4,000-12,000 endpoints. Every EX2300 sits in a Virtual Chassis stack with the next pod over, so a single bad SFP does not orphan an entire row of trading desks during NSE pre-open at 9:00 IST.

3. Design C: dedicated out-of-band fabric, with a EX2300 in every cage as the OOB switch handling console servers, BMC ports, and PDU management. This is what every SEBI-audited DR plan demands now. If the production fabric fails, you still want to reach the lights-out management port on every chassis from a dedicated terminal server.

Power planning matters more than people admit. A EX2300 at full load draws roughly 65-180 watts per PSU depending on PoE budget. In a Mumbai BKC cage at 12.40 INR per unit commercial tariff, that is about INR 1,200-2,800 a month per access switch for primary power, before cooling adders. Multiply by 24 switches in a typical trading-floor distribution pod and you can see why the DC manager cares about idle draw. BFSI AMC quotes routinely include a stocked hot-spare EX2300 on site at NSE Mahape; add INR 28,000 to INR 42,000 for that line on the BoQ.

Configuration walkthrough

For juniper ex2300: how to zero-touch provisioning, the Juniper EX2300 config I drop in by default for a BFSI trading floor access switch looks like this. It is the version we push at NSE Mahape with IST clock, NPL NTP at 14.139.60.103 (the National Physical Laboratory primary, the regulator-friendly reference under SEBI cyber-security guidelines), and syslog landing on the SOC collector in the same cage.

system {
    host-name JNPR-MUM-NSE-ACC-01;
    time-zone Asia/Kolkata;
    root-authentication { encrypted-password "$6$..."; }
    services { ssh { protocol-version v2; } netconf { ssh; } }
    syslog { host 10.20.30.40 { any info; facility-override local6; } }
    ntp { server 14.139.60.103; }
}
interfaces {
    ge-0/0/0 {
        description "Uplink-to-EX4400-DIST-A";
        unit 0 { family ethernet-switching { interface-mode trunk;
            vlan { members [ TRADING MGMT VOIP ]; } } }
    }
    irb {
        unit 100 { family inet { address 10.20.100.1/24; } }
    }
}
protocols {
    rstp { interface ge-0/0/0; }
    lldp { interface all; }
}
vlans {
    TRADING { vlan-id 100; l3-interface irb.100; }
    MGMT    { vlan-id 200; }
    VOIP    { vlan-id 300; }
}

The bit that catches people new to Junos is the candidate-commit model. Edits do not take effect until you run commit. Use commit check first, then commit confirmed 5 on anything risky; if you do not run a second commit within five minutes, the change rolls itself back automatically. I have saved my own job with commit confirmed on a Saturday morning fat-finger of a management interface IP. The router rolled itself back in three minutes and I was on the bridge with the NOC before the alarm cleared.

After the candidate is committed, verify with:

show configuration | display set | match interface
show interfaces terse
show ethernet-switching interface
show lldp neighbors
show vlans

On Junos OS, the first command renders the configuration as SET syntax, which is what most CMDB import tools expect. If you are pushing configs from a NETCONF harness, prefer XML; if you are storing them in Git for diff review, SET syntax wins because it is line-oriented and diffs cleanly. I keep both in the repo: config.set for the ops team and config.xml for the automation pipeline.

Troubleshooting commands by platform

This is my muscle-memory set on Juniper EX2300 (Junos OS). I run them in this order on every incident bridge so the JTAC engineer gets the same artefact set every time. Saves 30 minutes of back-and-forth with a Bengaluru JTAC engineer or a Singapore queue if it routes that way.

One habit worth copying: pipe the output to a USB stick or an SCP target before you reboot. On a hard reload the on-box buffer is lost and you lose the very evidence JTAC will ask for first. On Junos OS I script request support information | save /var/tmp/ex2300-rsi.txt and then file copy /var/tmp/ex2300-rsi.txt scp://noc@10.0.0.5//srv/jtac/ as part of my pre-change checklist, every single time.

A small Junos gotcha: in a Virtual Chassis stack, show chassis hardware shows only the master unit by default. To see all members run show virtual-chassis status first to map member IDs, then show chassis hardware detail member 1 and so on. I have wasted real time on a bridge wondering why a stack member was missing from the hardware output because I forgot the per-member syntax.

India compliance and deployment notes

If you are buying a Juniper EX2300 on a BFSI RFP, the GeM portal is not usually the route, the bank's panel of empanelled SIs is. List prices on GeM can run 10-18 percent above what a Tier-1 SI quotes for the same SKU, because the GeM listing does not bundle India deployment services. For a Juniper EX2300 in a typical 3-year AMC inside a regulated BFSI cage, expect 15-22 percent year-over-year escalation on labour and a flat material rate, with mandatory background-verified onsite engineers on the BoQ.

The INR 1.15 lakh figure above is the annualised SmartNet-equivalent J-Care support renewal for a single EX2300 chassis on a 3-year JTAC contract at NBD, India support, including software updates. 24x7x4 on site pushes that by 38-52 percent. For a BFSI customer running a NSE/BSE colo footprint with SEBI CSCRF obligations, 24x7x4 is mandatory on any device in the production trading path; the audit asks for it explicitly during the annual review.

Under MeitY's DPDP Act (Digital Personal Data Protection, in force from 2025), logs that contain personal data must be retained inside Indian borders. I push customers to ship syslog from the EX2300 to a local SIEM (Splunk on prem at CtrlS Hyderabad or QRadar at NetMagic Bengaluru) rather than a foreign cloud collector. Cross-border telemetry from the J-Web management interface or Mist cloud onboarding is a separate question; if you turn on cloud onboarding, document the data flow in your DPIA and brief the DPO before go-live.

RoHS, BIS, and WPC certifications are checked at customs. For a Juniper EX2300 arriving against a service contract, the BIS R-41 number must appear on the packing list or the consignment sits at the Bombay Custom House at JNPT until you produce it. I have personally lost two days to this on a NSE Mahape delivery; do not repeat my mistake. Keep the BIS certificate PDF in the same shared folder as the PO so the SCM team finds it without ringing me at 11 pm.

SEBI CSCRF (the cyber security and resilience framework for stock exchanges and depositories) demands change control records, immutable logs, and quarterly vulnerability scans for any device in the trading fabric. The BFSI branch access fabric, NSE colo Mumbai I work with treats every EX2300 change as a SOX-grade event: NETCONF push from a controlled jump host, before-and-after config in Git, ticket ID in the commit message, two-engineer sign-off on the change record. It feels like overhead until your first audit; it becomes muscle memory after.

Real-world deployment I did

I rolled out 14 Juniper EX2300 units for a NSE-listed retail brokerage customer with branches across Hyderabad, Vijayawada, and Vizag last quarter. Each branch needed an access switch pair, dual ISP (Airtel primary, ACT secondary on a metro Ethernet handoff), and centralised management from the Mumbai NOC at NSE Mahape.

The bit that ate the most time was not the EX2300 configuration, that is a templated NETCONF push. The bit that ate time was the carrier handoff. ACT in particular hands off with a static-IP /30 and no BGP option on the metro tier; that constrains your HA design. We landed on a VRRP pair on the EX2300 with a tracked default route. Works fine, but the design choice has to happen before the PO goes out, not after the first install at Vijayawada.

End-state: branches up in 10 working days, AMC signed at INR 1.15 lakh per chassis per year for the EX2300 fleet, single NSO console for ops. The customer is happy because the P1 ticket count dropped from roughly 18 a month to 3. The runbook I wrote during that rollout is the one I still ship with every BFSI engagement.

Extended FAQs

What does a Juniper EX2300 draw at idle vs full load?

Idle on a single PSU, around 45-90 watts. Full load with all ports lit and PoE+ delivering, 180-720 watts depending on PoE budget. Plan for the upper number in your rack power budget; running hot is what kills PSU lifetime first, and Indian DC inlet temps in summer at NSE Mahape in May routinely run higher than the lab spec sheet assumes.

Can I mix a Juniper EX2300 with another vendor in Virtual Chassis?

No. Virtual Chassis members must be the same chassis family and the same Junos OS release. You can have a different vendor at the next tier (an Arista core upstream, an Aruba CX leaf downstream), but the VC peer must be the same SKU. I have tried mixing major Junos releases inside a VC group during a rolling upgrade and it half-worked. Half-working is worse than not working in a BFSI trading floor.

What is the realistic MTBF in an Indian data center?

Vendor spec sheets quote 200,000-400,000 hours. Real-world in a clean cage at CtrlS Hyderabad or NetMagic Mumbai, I see roughly one PSU failure per 50 units per year, one fan tray per 80 units per year, and one chassis logic-board failure per 200 units per year. Plan sparing accordingly: a single hot spare per 25 chassis is my rule. Sites with poor humidity control (we had one in Coimbatore that wandered above 70 percent RH for weeks) see PSU failures at twice that rate.

Do I need an India-based JTAC entitlement?

Yes if you want phone support in IST and an India-language engineer on the case. The default routing for global support contracts without the India tag will land you in a Singapore or Bangalore queue, and the time-to-engineer is roughly 3x slower for a P2 case during US business hours. Pay the India adder; it is INR 14,000-22,000 per chassis per year extra and worth every paisa at 2 am.

What is the right way to back up the config?

SCP to an in-cage Linux box on a management VLAN, then rsync to two geographically separate locations (one Mumbai, one Bengaluru is a good split). The J-Web export is a snapshot, not a backup. I have lost a config once to a UI export that silently truncated; never trust the browser as a backup tool. show configuration | display set | save /var/tmp/config.set piped to SCP is the only backup I actually trust on Junos.

How long does an in-place Junos OS upgrade actually take?

On a EX2300, plan for 30-45 minutes wall-clock for a non-VC chassis, including pre-checks, image transfer at 1 Gbps from local SCP, reload, and post-checks. On Virtual Chassis, add 12 minutes per member for a non-stop software upgrade (NSSU). I never schedule a maintenance window shorter than 90 minutes for an upgrade on this class; if it goes well, you finish early and write the report. If it does not, you have time to request system reboot from the previous slice and roll back without a panic call to JTAC.