Which protocol and UDP port does a Mist AP use to build a tunnel to a Mist Edge?

Correct: d. The AP→Edge tunnel is L2TPv3 on UDP 1701, optionally protected by IPsec (UDP 500/4500). RadSec on TCP 2083 (b) is the auth-proxy service, not the data tunnel. HTTPS 443 (c) is cloud management. GRE (a) is not the Mist tunnel protocol.

You need the same physical access port to become an AP port, an IP-phone port, or a user port depending on what plugs in. Which feature delivers this?

Correct: c. A dynamic port profile applies automatically when a rule (RADIUS attribute, LLDP chassis-id, or MAC/OUI) matches — so one socket adapts to whatever connects. A static profile (a) is fixed. Tunnels (b) and OOBM (d) are unrelated to per-port adaptation.

You're adopting a live, production EX4300 carrying real users. What's the right first step before pasting the Mist adoption block?

Correct: a. A rescue save captures the known-good config; if a pasted command locks SSH before the Mist agent connects, rollback rescue restores it. Factory-reset (b) wipes the production config you're trying to preserve. Disabling uplinks (c) cuts the path home. Tunnels (d) aren't part of switch adoption.

Marvis shows the "Successful Connects" SLE failing only on VLAN 40, only between 6–9 PM. Which root cause fits the evidence best?

Correct: b. Failures scoped to one VLAN at peak time point at DHCP lease exhaustion — too few addresses for evening guest load. A PSU fault (a) would hit the whole switch, not one VLAN. A tunnel-down (c) or mist-dpc (d) issue wouldn't be time-of-day and VLAN-specific.

A Mist Edge is "Connected" to the cloud, yet APs cannot establish tunnels and the tunnel-IP and OOBM are both 10.50.10.0/24. What's the fix?

Correct: d. Mist requires the OOBM (management) and tunnel-termination IPs on different subnets; on the same subnet, tunnels won't terminate. Separate them and confirm the L2TPv3/IPsec ports are open. You can't reboot the cloud (a); tunnels are supported (b); RadSec (c) is unrelated.

A retailer proposes tunneling ALL traffic from 40 stores to one Mist Edge cluster "for central visibility", including guest Wi-Fi and store CCTV. Evaluate the design.

Correct: c. Centralizing every flow forces local traffic (guest, CCTV) over the WAN to HQ and back, saturating links. Tunnel by exception — only the corporate VLAN needing central policy — and break out guest/IoT locally. Visibility comes from Wired/Wi-Fi Assurance regardless of data path; you don't disable SLEs (b), and an Edge scales to many sites (d).

For a teleworker design, an engineer wants the home AP to authenticate remote users against the on-prem RADIUS without exposing the RADIUS server to the internet, and place them on the HQ VLAN. Which combination is right?

Correct: b. The tunnel places remote clients on the HQ VLAN; the Edge's RadSec proxy (TCP 2083) securely relays the AP's 802.1X requests to the internal RADIUS — no server exposed to the internet, same identity policy as in-office. Port-forwarding RADIUS (a) is a security hole. Port profiles (c, d) are switch-side and don't solve remote auth or VLAN anchoring.

Juniper Mist Wired Assurance & Mist Edge — EX Integration & Tunneling

Q: A brand-new cloud-ready EX switch is racked with internet access but has never been touched. What is the correct, lowest-effort way to bring it into your Mist org?

Correct: a. A cloud-ready switch's phone-home client reaches the redirect server and gets pointed at Mist on first boot. You just claim it with the activation code. Brownfield switches need the copy-paste CLI block (b is only for adoption, and never hand-typed). Reflashing old code (c) and tunnels (d) are irrelevant to onboarding.

Q: After adoption, your dynamic port profiles never apply and a commit prints "Configuration group 'mist-dpc' is not defined". What is the most likely root cause?

Correct: b. Dynamic port config rides on the mist-dpc apply-group plus Mist op/event scripts pushed at adoption. On some EX models (EX3400 is the classic) those scripts/groups don't build, leaving the apply-group pointing at nothing. Re-adopt or re-run the event script to rebuild them. Port profiles are widely supported (a is false); tunnels are unrelated (c).

Q: Your Mist Edge is connected to the cloud, but no AP tunnel will establish. You discover the OOBM interface and the tunnel-termination IP are in 10.50.10.0/24 together. What's wrong?

Correct: b. Mist requires the management (OOBM) interface and the tunnel-termination IP to live on separate subnets so the management and data planes stay distinct. Same subnet = tunnels won't terminate. The cloud link is fine (a is false), L2TPv3 is correct (c), and RadSec is a separate service (d).

The wrong way first — two clouds and a console cable

War story · what NOT to do Sneha at Infosys ran Mist for Wi-Fi and a separate on-prem controller plus per-switch console sessions for the wired side. When a meeting-room AP went dark, she had two dashboards, two truths, and a 40-minute argument about whether it was "the Wi-Fi" or "the switch port". The AP was fine — the access port had silently negotiated half-duplex after a firmware bump, and nothing correlated the two.

That split-brain is the old model. Mist Wired Assurance ends it: the same cloud, the same Marvis, the same SLE language for both the AP and the switch port it sits on. One click correlates "Wi-Fi degraded" with "the uplink port flapped". And when a single VLAN must follow users across many sites — or a teleworker's home AP must land on the corporate VLAN — Mist Edge tunnels that traffic to a central data plane. This lesson covers both: getting the EX into the cloud, and pulling traffic to the Edge.

🧒 ELI5: Imagine your school's Wi-Fi router and the wall sockets are now managed from the same app on your phone. And imagine a magic pipe (tunnel) that lets a student studying at home plug into a socket that behaves exactly like one in the school building.

🛠 Practitioner: Adopt EX + QFX into the same org as your APs so AP and switch-port telemetry correlate in one SLE view. Reach for Mist Edge only when local VLAN breakout genuinely can't do the job — teleworker, single roaming VLAN across sites, or a VLAN you can't trunk through the access layer.

🏛 Architect: Treat Wired Assurance as observability + config-intent for the access layer, and Mist Edge as an optional overlay data plane. Default to a distributed (local-breakout) design; centralize only the flows that demand it, and size the Edge cluster for failover across two data centers from day one.

Pre-quiz · before you read — predict

Q1. A brand-new, cloud-ready EX switch is racked and cabled to the internet. What gets it into your Mist org with zero CLI?

ZTP via phone-home + the order activation code. On first boot the switch's phone-home client reaches the redirect server, gets pointed at Mist, and pulls its config. You claim it by entering the activation code (linked to the purchase order) in the portal — no console session required.

Pre-quiz · predict

Q2. Your dynamic port profiles stop applying and the commit warns "Configuration group mist-dpc is not defined". What broke?

The mist-dpc apply-group / Mist scripts didn't initialize during adoption. Mist relies on the mist-dpc group and op/event scripts to build dynamic config; if the script directories or groups are missing (a known EX3400 adoption bug), the apply-group references nothing and dynamic ports go dead.

Pre-quiz · predict

Q3. A Mist Edge in a cluster fails entirely. What happens to the APs tunneling to it?

They fail over to the secondary cluster. APs load-balance across Edges in the primary cluster; if the whole primary cluster dies they move to the secondary cluster (ideally in another data center). With auto-preemption on, they return to primary once it recovers.

① Adopt the EX — greenfield ZTP vs brownfield CLI

There are two doors into Mist Wired Assurance. Greenfield (a brand-new cloud-ready EX) and brownfield (an EX already in production with a config you cannot lose). Both end in the same place — the switch shows Connected in Organization > Inventory — but the journey differs.

Figure 1 — One Mist cloud manages EX switches (Wired Assurance) and APs; a Mist Edge terminates a tunnel that places the teleworker's home AP onto the HQ VLAN.

Greenfield — zero-touch provisioning

A cloud-ready EX runs a phone-home client. Power it on with internet reachability, claim it in Organization > Inventory > Switches > Claim using the order activation code, and it appears in inventory in minutes. No CLI, no image juggling.

Brownfield — the copy-paste adoption

For an EX already carrying a production config, you adopt it without wiping anything. Mist generates a per-org command block — always copy it fresh from the portal, never hand-type it. It creates a local mist user, enables SSH/NETCONF, and sets up an outbound-SSH session so the switch dials home.

Switch CLI — paste the Mist-generated adoption block (illustrative)

set system services ssh
set system services netconf ssh
set system login user mist class super-user authentication ...
set system services outbound-ssh client mist ...
commit and-quit

Verify the agent connected

user@ex4400> show system connections | match 2200
tcp4   0  0  10.10.10.21.51022   oc-term...mist.com.2200  ESTABLISHED

Always rescue-save first

Before adopting a brownfield switch, run request system configuration rescue save. If anything goes sideways during adoption, rollback rescue restores the exact pre-Mist config. On a live access switch carrying real users, this 5-second habit has saved many a midnight.

Field note · Rahul @ TCS Rahul adopted 30 production EX4300s on a Friday and skipped the rescue save on the last one. A typo in the pasted block locked his SSH on that single switch — and because the Mist agent hadn't connected yet, he had no remote way back in. One console-cable drive to the comms room later, he never skips the rescue save again.

Quick check · Q1 of 10

A brand-new cloud-ready EX switch is racked with internet access but has never been touched. What is the correct, lowest-effort way to bring it into your Mist org?

a) Let it ZTP via phone-home, then claim it with the order activation code in the portal — no CLI needed b) Console in and hand-type the full Mist adoption block from memory c) Reflash Junos to the oldest available image first d) Build an L2TPv3 tunnel to the switch before it can be managed

Correct: a. A cloud-ready switch's phone-home client reaches the redirect server and gets pointed at Mist on first boot. You just claim it with the activation code. Brownfield switches need the copy-paste CLI block (b is only for adoption, and never hand-typed). Reflashing old code (c) and tunnels (d) are irrelevant to onboarding.

② Port Profiles & SLEs — where the AI earns its keep

Once adopted, you stop configuring interfaces one by one and start assigning port profiles. There are two kinds, and the difference is a top exam question and a top real-world bug.

Static profile (pinned to a port) Dynamic profile (matched at runtime) Healthy / matched Translated / overridden Trap / needs attention

📌

Static profile

tap to flip

Pinned to a specific interface or range. The port always uses this config — VLAN, PoE, speed. Predictable, simple, and the right default for uplinks.

🔀

Dynamic profile

tap

Applied automatically when a rule matches — a RADIUS attribute, an LLDP chassis-id, or a MAC/OUI. The same socket becomes AP, phone, or user port by what plugs in.

🧩

mist-dpc group

tap

Dynamic ports ride on the mist-dpc apply-group + Mist op/event scripts. If those don't build during adoption, dynamic ports go dead — the famous "not defined" commit warning.

📊

Wired SLEs

tap

Four scores: Successful Connects, Throughput, Switch Health, Switch–AP/Bandwidth. Each breaks down to a root cause you can act on.

🧒 ELI5: A static port is a labelled drawer — same thing always goes there. A dynamic port is a smart shelf that recognises what you put on it and arranges itself. The SLEs are the report card the AI gives every port.

🛠 Practitioner: Use static profiles for uplinks and infrastructure; use dynamic profiles for user-facing access ports driven by 802.1X / RADIUS. Before relying on dynamic, confirm show configuration groups mist-dpc returns something on every adopted switch.

🏛 Architect: Dynamic port profiles let one access-switch template serve mixed device types without per-port config drift across sites. Treat the RADIUS attribute → profile mapping as your wired identity policy, mirroring the WxLAN labels you already use on Wi-Fi.

The #1 Wired Assurance trap — "mist-dpc is not defined"

Symptom you see: dynamic port profiles silently never apply, and a commit prints apply-groups mist-dpc: mgd: Configuration group 'mist-dpc' is not defined. Cause: during adoption the Mist op/event scripts and the mist-dpc / mist-script groups failed to initialize — the script dirs /var/db/scripts/op and /var/db/scripts/event came up empty (a known EX3400 adoption issue). The apply-group then points at nothing. Fix: remove the switch from the site and let Mist re-push, or re-run the Mist event script so the groups rebuild. Use a static profile in the meantime.

War story · Priya @ HCL Priya rolled out 802.1X dynamic ports across a new branch on EX3400s. Wireless was perfect; wired auth "just didn't take" on some switches. Two hours in, she ran a commit and finally saw the mist-dpc is not defined warning scroll past. The dynamic profiles had never been live on those units — the apply-group was empty. Re-adopting the affected switches rebuilt the scripts, and 802.1X came up everywhere.

The four wired SLEs — and Marvis on top

Wired Assurance scores every switch against four SLEs: Successful Connects (did clients get DHCP/authz?), Throughput, Switch Health (CPU, memory, temperature, PSU), and Switch–AP / Bandwidth (are uplinks and PoE healthy?). Each SLE drills into a root-cause classifier, so "connect failures" resolves to "DHCP timeout on VLAN 40" rather than a vague red bar. Marvis turns those into actions — and into proactive anomaly detection that flags a baseline deviation before users notice.

Marvis query · ask it in plain English

marvis> troubleshoot switch ex4400-luck-01

Expected output (paraphrased)

Switch ex4400-luck-01 · Health 96 · Connects 89
Anomaly: ge-0/0/14 negotiated 100M-HALF (expected 1G-FULL)
Likely cause: duplex mismatch / cabling on AP uplink
Suggested action: re-seat cable or pin port to 1G-full  [Apply]

Quick check · Q2 of 10

After adoption, your dynamic port profiles never apply and a commit prints "Configuration group 'mist-dpc' is not defined". What is the most likely root cause?

a) The switch model doesn't support port profiles at all b) The Mist op/event scripts and the mist-dpc apply-group failed to initialize during adoption, so the apply-group references nothing c) You forgot to build an IPsec tunnel to the switch d) Marvis disabled the ports on purpose

Correct: b. Dynamic port config rides on the mist-dpc apply-group plus Mist op/event scripts pushed at adoption. On some EX models (EX3400 is the classic) those scripts/groups don't build, leaving the apply-group pointing at nothing. Re-adopt or re-run the event script to rebuild them. Port profiles are widely supported (a is false); tunnels are unrelated (c).

Pause & predict

Marvis flags your "Successful Connects" SLE dropping only on VLAN 40 (guest), only in the evening. What's your first hypothesis before you open the root-cause view?

DHCP scope exhaustion on the guest VLAN. A failure scoped to one VLAN at peak hours screams "ran out of leases", not a switch fault. Marvis will usually confirm "DHCP timeout / no offer" — widen the scope or shorten lease time. Per-VLAN, time-of-day scoping is exactly what the SLE root-cause breakdown is for.

③ Mist Edge & Tunnels — anchor a remote AP to HQ

Most traffic should break out locally at the AP. But sometimes you need client traffic to surface at a central point — a teleworker's home AP placing corporate laptops on the HQ VLAN, or one guest VLAN that must follow users across 50 sites. That's the job of Mist Edge: the AP builds an L2TPv3 tunnel (optionally IPsec-protected) to a Mist Edge, which breaks the traffic out centrally.

Figure 2 — Mist Edge data path: management (OOBM) and tunnel-termination (tunnel-IP) interfaces are deliberately on different subnets; client traffic breaks out centrally onto the HQ VLAN.

A Mist Tunnel object holds the design: the tunnel protocol, the primary and secondary clusters, the tunneled VLANs, failover timers, and auto-preemption. A Mist Edge must belong to a cluster before it can terminate any tunnel. APs load-balance across the Edges in the primary cluster; the host-selection options are Shuffle (default) and Shuffle by Site (pins a site's APs to one Edge).

▶ Watch a remote AP anchor its client to the HQ VLAN

Click Play. Each stage lights up as a teleworker's laptop traverses the Mist Edge tunnel.

① CLIENT JOINS Laptop associates to the home AP's Corp SSID · 802.1X auth begins

▼

② TUNNEL UP AP 10.10.10.30 → Edge 203.0.113.20 · L2TPv3 / UDP 1701 (IPsec-wrapped)

▼

③ CLUSTER PICK AP terminates on an Edge in the primary cluster · host-selection = Shuffle

▼

④ BREAKOUT Edge places the client on HQ VLAN 10 (10.50.10.0/24) — not the home LAN

▼

⑤ FAILOVER Primary cluster dies → AP re-anchors to the secondary cluster in DC2

▼

⑥ PREEMPT Primary recovers · auto-preemption moves the AP back. Client never noticed.

Press Play to step through the tunnel anchoring. Each press of Next advances one stage.

The #1 Mist Edge trap — OOBM and tunnel-IP on the same subnet

Symptom you see: the Edge shows happily connected to the cloud, but no AP tunnel ever comes up — or it flaps. Cause: the OOBM (management) interface and the tunnel-termination IP were put on the same subnet. Mist requires them on different subnets so management and data planes don't collide. Fix: re-IP the tunnel interface into its own subnet, and confirm UDP 1701 (plus 500/4500 for IPsec) is open end-to-end.

RadSec proxy — the teleworker's authentication lifeline

For remote APs, the Edge can run a cloud-managed RadSec proxy on TCP 2083. It securely relays the remote AP's 802.1X requests to your RADIUS/NAC, so a teleworker authenticates with the same identity policy as someone at HQ — no RADIUS server exposed to the internet.

Quick check · Q3 of 10

Your Mist Edge is connected to the cloud, but no AP tunnel will establish. You discover the OOBM interface and the tunnel-termination IP are in 10.50.10.0/24 together. What's wrong?

a) Mist Edge can't reach the cloud over OOBM b) The OOBM and tunnel-termination IPs must be on different subnets — they're colliding c) You must downgrade to L2TPv2 d) RadSec on 2083 is blocking the tunnel

Correct: b. Mist requires the management (OOBM) interface and the tunnel-termination IP to live on separate subnets so the management and data planes stay distinct. Same subnet = tunnels won't terminate. The cloud link is fine (a is false), L2TPv3 is correct (c), and RadSec is a separate service (d).

Pause & predict

You set tunnel host-selection to "Shuffle by Site" instead of the default "Shuffle". What behaviour does that change?

All APs at one site terminate on the same Edge within the cluster. Default "Shuffle" spreads APs across all Edges in the primary cluster for even load. "Shuffle by Site" keeps a site's APs together on one Edge — handy when you want per-site locality or simpler troubleshooting, at the cost of less even load distribution.

④ Tunnel or not? — the decision that saves your WAN

This is the architect-grade call, and the most common way teams hurt themselves. The default is local breakout (distributed data plane): the AP maps clients to a tagged VLAN and traffic exits at the edge. You reach for the Mist Edge (centralized data plane) only for specific reasons.

Figure 3 — Decision tree: tunnel to a Mist Edge only for teleworker, single-VLAN-across-sites, or non-trunkable VLANs; otherwise break out locally.

War story · Arjun @ a large retailer Arjun tunneled all wireless traffic from 40 stores to one Mist Edge cluster at HQ "for visibility". Within a week, store CCTV and guest Wi-Fi were hauling video across the WAN to HQ and back — the MPLS links saturated and POS terminals timed out. The fix: break guest and IoT out locally, and tunnel only the corporate VLAN that genuinely needed central policy. Tunnel by exception, never by default.

One-screen cheat-sheet

Pin this. It's the whole lesson — adoption, port profiles, SLEs, and tunneling — on a single card.

Figure 4 — Cheat-sheet: adopt → port profiles + SLEs → Mist Edge tunnel ports & clusters → the tunnel-or-not decision.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Juniper Mist Wired Assurance + Mist Edge docs and community Q&A. For complex prod issues, paste your show system connections + Mist Edge tunnel status into chat.techclick.in.

🧠 Explain it back (self-explanation)

In one or two lines, explain to yourself: why does adopting EX switches into the same cloud as your APs help troubleshooting, and when is a Mist Edge tunnel actually worth it? Typing it cements it.

👋 Teach a friend

Best retention hack: explain Mist Edge to a teammate in 60 seconds. Try this opener — "A Mist Edge tunnel is a company shuttle bus: a home AP puts your laptop on it, it drives over an L2TPv3/IPsec road to HQ, and you arrive on the corporate VLAN as if you'd walked into the building."

⏰ Lock it in — spaced recall

Want a 3-question refresher on this lesson in 3 days? Drop your email — we'll nudge you once (no spam).

📖 Glossary

Wired Assurance: Mist's cloud service that brings AI monitoring, SLEs, and Marvis to EX/QFX switches — the wired counterpart of Wi-Fi Assurance.
ZTP / phone-home: Zero-touch provisioning: a cloud-ready switch's phone-home client reaches a redirect server, gets pointed at Mist, and pulls its config — claimed by activation code.
Brownfield adoption: Onboarding an existing, production EX into Mist without wiping its config, using a per-org copy-paste CLI block that sets up outbound-SSH.
Dynamic port profile: A port config applied at runtime when a rule matches (RADIUS attribute, LLDP, MAC/OUI); depends on the mist-dpc apply-group being present.
SLE: Service-Level Expectation — a continuously scored target. Wired SLEs: Successful Connects, Throughput, Switch Health, Switch–AP/Bandwidth.
Mist Edge: An appliance that terminates L2TPv3/IPsec tunnels from APs to provide a centralized data plane; must belong to a cluster to terminate tunnels.
OOBM: Out-of-band management interface on a Mist Edge — talks to the cloud; must be on a different subnet than the tunnel-termination IP.
RadSec proxy: RADIUS-over-TLS (TCP 2083) running on the Edge to securely relay a remote AP's 802.1X auth to internal RADIUS.

📚 Sources

Juniper Mist Docs — Wired Assurance Overview + Datasheet (switch SLEs, Marvis, cloud-ready EX/QFX). juniper.net/documentation
Juniper Mist Docs — Onboard Switches to Mist Cloud + Adding an EX Series Switch to the Juniper Mist Cloud (ZTP phone-home, activation code, brownfield copy-paste, rescue save). mist.com/documentation
Juniper Mist Docs — Static and Dynamic Port Profiles / Dynamic Port Configuration. juniper.net/documentation
Community — Juniper Community "Mist Wired Assurance and Dynamic Port Configuration" & Network Direction "Mist Wired Assurance: mist-dpc is not Defined" (EX3400 adoption bug, empty script dirs, workaround).
Juniper Mist Docs — Mist Edge Getting Started + Mist Edge Design Guide + Configure a Teleworker + Configure a RADIUS Proxy Server (L2TPv3/UDP 1701, IPsec 500/4500, OOBM vs tunnel-IP subnets, primary/secondary cluster, Shuffle / Shuffle by Site, RadSec 2083). juniper.net/documentation
Security — Juniper Mist Security Alerts page & PSIRT; e.g. CVE-2025-21589 API auth-bypass on WAN Assurance / Session Smart Router (subscribe to JSAs, patch promptly).
Certification — HPE Juniper JNCIA-MistAI (JN0-253) blueprint (Wired/WAN/Routing Assurance, onboarding, RadSec/Mist certs) & JNCIS-MistAI-Wired specialist track.

What's next?

You've got the switch in the cloud and traffic flowing through the Edge. Next, the part everyone actually wants: when something breaks, Marvis pulls a dynamic packet capture at the moment of failure and tells you the anomaly in plain English — and offers one-click actions to fix it.

Next · Mist Troubleshooting & Marvis Actions — Dynamic Packet Capture & Anomalies → ← All lessons