Juniper Mist and the EX4000 Series

The EX4000 series is Juniper's cloud-first access switch line — the successor to the EX2300/EX3400 class, designed from day one to be onboarded, configured, and monitored through the Mist cloud rather than box-by-box CLI. Under the hood it still runs Junos, so nothing you know about the CLI is wasted, but the operational model changes completely: templates instead of per-switch configs, service levels instead of raw counters, and an AI assistant (Marvis) that will tell you a cable is bad before a user does.

This article walks through the platform, the Mist onboarding flow, and the features that actually change how you operate a campus network.

The EX4000 Platform

The family covers the standard access-layer spread — compact fanless models up through 48-port PoE-dense units, with multigig ports on the higher-end SKUs for Wi-Fi 6E/7 APs and SFP+ uplinks. A few things that matter in practice:

• Junos OS: full featured — same VLAN, LACP, STP/RSTP/MSTP, IGMP snooping, and routing behavior you'd expect. You can still drop to the CLI for troubleshooting (show interfaces, show ethernet-switching table, show poe interface) even when the box is Mist-managed.
• Virtual Chassis: stack multiple EX4000s into one logical switch with a single management plane — one uplink LAG across members, no STP between stack members.
• PoE for the modern edge: budget and per-port wattage vary by SKU; size for your AP and camera load with headroom, and check the datasheet for the exact model before ordering. Under Mist you get per-port PoE draw telemetry, which ends the "is this port actually delivering power?" guessing game.
• Cloud-ready: every unit ships with a claim code. There is no controller appliance to install.

Onboarding: Claim, Assign, Done

The Mist onboarding flow is genuinely short:

1. Claim the switch into your organization — scan the QR/claim code with the Mist AI app or enter it under Organization → Inventory (or push a list via API).
2. Assign it to a Site.
3. Cable it to a network with DHCP and internet reachability. The switch phones home (outbound TLS to the Mist cloud), pulls its assigned configuration, and appears on the site dashboard.

For zero-touch branch deployments that's the whole story: ship the box, have anyone plug it in, and it configures itself from the template.

Templates and the Configuration Hierarchy

Mist Wired Assurance replaces per-device config files with a hierarchy:

Organization
  └── Switch Template  (VLANs, port profiles, radius, syslog, etc.)
        └── Site (overrides)
              └── Switch (overrides)
                    └── Port (overrides)

You define networks (VLANs) and port profiles once at the template level:

• ap — trunk, native VLAN mgmt, tagged everything, PoE on
• corp — access VLAN 10, dot1x, storm control
• printer — access VLAN 40, no dot1x, MAC auth fallback
• uplink — trunk to core, all VLANs

…then apply profiles to port ranges per switch. A site can override the template, and an individual switch can override the site — but the override is visible and auditable in the UI, which kills the "who changed this one switch and why" archaeology.

Need something the GUI doesn't model? Additional CLI commands in the template let you push raw Junos set statements, so edge cases don't force you off the platform.

Dynamic Port Profiles

The feature that sells the platform in a demo: dynamic port configuration. Rules match what's plugged in — by LLDP chassis ID, manufacturer OUI, or RADIUS attributes — and apply the right profile automatically:

• A Mist AP is detected via LLDP → port converts to the ap trunk profile.
• A camera OUI shows up → camera profile with its VLAN and PoE policy.
• Someone unplugs the AP and plugs in a laptop → the port falls back to the restricted default.

Combined with Virtual Chassis, this means "which port is the AP on?" stops being configuration information at all — any port works.

Observability: SLEs and Marvis

This is the part relevant to anyone doing observability work. Mist doesn't just graph counters; it scores Service Level Expectations (SLEs) for the wired edge:

• Throughput — was the switch/port congested when a client needed capacity?
• Successful Connect — did dot1x/DHCP/ARP complete promptly?
• Switch Health — CPU, memory, temperature, PoE budget.

Each SLE is decomposed into classifiers, so a degraded Successful Connect score points directly at, say, RADIUS latency rather than making you infer it.

Marvis, the AI assistant, sits on top: it flags bad cables (using PHY-level error patterns), negotiation mismatches, flapping ports, missing VLANs on uplinks, and loops — often identifying the specific port and remediation. You can also just ask it things ("troubleshoot client aa:bb:cc...") in plain language.

For integration into an external observability stack:

• Webhooks push alerts and audit events to anything with an HTTPS endpoint.
• The REST API (api.mist.com) exposes everything the UI shows — stats, SLEs, inventory, config. Polling /api/v1/sites/:site_id/stats/devices gives you per-switch health you can forward into New Relic or Grafana.
• Junos on the EX4000 can still speak SNMP and stream telemetry directly if you want device-level collection alongside the cloud view — see my New Relic network observability article for the collector side.

API Example: Inventory Audit

Everything in Mist is API-first (the GUI itself uses the public API). A quick Python example — list every switch in an org with its firmware version:

import requests

MIST = "https://api.mist.com/api/v1"
headers = {"Authorization": f"Token {API_TOKEN}"}

devices = requests.get(
    f"{MIST}/orgs/{ORG_ID}/inventory?type=switch",
    headers=headers,
).json()

for d in devices:
    print(f"{d.get('name','(unassigned)'):24} {d['model']:12} {d.get('version','?')}")

Because config lives in templates, drift detection is trivial: the API can tell you exactly which switches carry local overrides.

Operating Model Takeaways

Moving from classic per-switch Junos to Mist-managed EX4000s changes a few habits:

1. Stop editing boxes. Config changes go to the template; the cloud pushes them. Treat local CLI overrides as break-glass.
2. Trust the SLEs first. Before diving into show commands, check which SLE classifier degraded — it's usually faster.
3. Wire up webhooks early. Mist knows about the failure before your users do; make sure that alert reaches your on-call path.
4. Keep CLI skills sharp. It's still Junos underneath, and console access still saves you when a site loses WAN.

Cloud management used to mean "less capable but easier." Wired Assurance on the EX4000 is the first wired platform I've run where the cloud layer adds diagnostic capability — the bad-cable detection alone has paid for the subscription in truck rolls.