# Juniper Mist Wired Assurance & Mist Edge — EX Integration & Tunneling Source: https://ai.techclick.in/blog_mist_wired_assurance_edge Markdown: https://ai.techclick.in/blog_mist_wired_assurance_edge.md Publisher: Techclick Infosec Pvt Ltd Juniper Mist Wired Assurance & Mist Edge explained the AI-era way — adopt an EX switch, push a dynamic port profile, then watch an L2TPv3 tunnel anchor a remote AP to a Mist Edge cluster, live. Switch SLEs, the mist-dpc adoption trap, and tunnel design in 11 minutes. Juniper Mist Wired Assurance & Mist Edge — EX Integration & Tunneling student learning map A visual study map for Juniper Mist Wired Assurance & Mist Edge — EX Integration & Tunneling showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Juniper Mist Wired Assurance & Mist Edge — EX... Juniper Mist · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start Pick your path — jump straight to it 2. Understand The wrong way first — two clouds... 3. Prove ① Adopt the EX — greenfield ZTP vs... 4. Practice ② Port Profiles & SLEs — where... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. ## 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? Reveal 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? Reveal 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? Reveal 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. The Mist cloud manages EX switches via Wired Assurance and APs via Wi-Fi Assurance; a Mist Edge appliance terminates an L2TPv3 tunnel from a remote AP to place its clients on the headquarters VLAN. MIST CLOUD (AI-Native) Wired Assurance Marvis · SLEs - HTTPS mgmt HQ Campus · Lucknow EX4400 (access) Mist Edge (X-series) AP AP EX adopted → SLEs scored · local VLANs break out here VLAN 10 staff · VLAN 40 guest · VLAN 50 voice Teleworker · Home AP Remote AP L2TPv3 / IPsec tunnel → HQ VLAN 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? Reveal 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. A remote access point sends client traffic through an IPsec-secured L2TPv3 tunnel on UDP 1701 to a Mist Edge; the Edge separates its out-of-band management interface to the cloud from its tunnel-termination IP that breaks traffic out to the corporate VLAN. Remote AP Tunnel IP 10.10.10.30 cl cl L2TPv3 · UDP 1701 + IPsec (UDP 500/4500) Mist Edge OOBM → Mist cloud Tunnel-IP (other subnet) Upstream → corp VLAN Mist Cloud (mgmt only) HQ VLAN 10 Client traffic surfaces at the Edge on the corporate VLAN — as if the home AP were in the building. OOBM and tunnel-IP MUST be on different subnets. 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. ▶ Play Next ▶ ↺ Reset 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? Reveal 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. A flowchart deciding whether wireless traffic should break out locally at the access point or be tunneled centrally to a Mist Edge, based on teleworker needs, single-VLAN-across-sites needs, and whether a VLAN can be trunked through the access layer. Where should traffic break out? Teleworker / remote AP needs the HQ VLAN? e.g. home AP must place laptops on corp VLAN YES no One VLAN must follow users across sites? single roaming subnet over many campuses YES no Can't trunk the VLAN through access layer? guest/PCI VLAN not allowed on switches YES no TUNNEL to Mist Edge Centralized data plane + cluster failover LOCAL BREAKOUT Default · simplest · WAN-friendly ⚠ Never "tunnel everything" — it drags local traffic across the WAN and can saturate the link. 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. A reference card summarizing EX switch adoption paths, static versus dynamic port profiles and the mist-dpc trap, the four wired SLEs, and Mist Edge tunnel ports and cluster failover. Mist Wired & Edge — Cheat-Sheet ① ADOPT THE EX Greenfield → ZTP phone-home + activation code Brownfield → copy-paste CLI block (outbound-SSH) request system configuration rescue save Verify: switch shows "Connected" in Inventory show system connections | match 2200 ② PORTS & SLEs Static = pinned · Dynamic = rule-matched ⚠ "mist-dpc not defined" → re-adopt to rebuild 4 wired SLEs: Connects · Throughput · Switch Health · Switch–AP Marvis → root cause → one-click action ③ MIST EDGE TUNNEL L2TPv3 → UDP 1701 · IPsec → UDP 500/4500 RadSec proxy → TCP 2083 (remote auth) ⚠ OOBM ≠ tunnel-IP (different subnets!) Edge must be in a cluster to terminate tunnels Primary → fail over → Secondary → auto-preempt Host-select: Shuffle (default) / Shuffle by Site ④ TUNNEL OR NOT? Default = LOCAL BREAKOUT Tunnel only when: • teleworker / remote AP needs HQ VLAN • one VLAN must follow users across sites • VLAN can't be trunked through access layer Never tunnel everything — WAN saturation 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. Greenfield vs brownfield switch adoption — what's the difference? What exactly causes the "mist-dpc is not defined" error? Static vs dynamic port profile — when do I use each? Which ports do I open for a Mist Edge tunnel? How do primary and secondary clusters fail over? When should I tunnel vs break out locally? 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. ## 📝 Wrap-up — seven more You've already answered 3 inline. Seven left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end. Q4 · Remember Which protocol and UDP port does a Mist AP use to build a tunnel to a Mist Edge? a) GRE over port 47 b) RadSec over TCP 2083 c) HTTPS over TCP 443 d) L2TPv3 over UDP 1701 (optionally IPsec-wrapped on 500/4500) 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. Q5 · Apply 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? a) A static port profile pinned to the interface b) A Mist Edge tunnel c) A dynamic port profile matched at runtime by RADIUS attribute / LLDP / MAC-OUI d) An OOBM interface 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. Q6 · Apply You're adopting a live, production EX4300 carrying real users. What's the right first step before pasting the Mist adoption block? a) Run request system configuration rescue save so you can rollback if adoption breaks management b) Factory-reset the switch first c) Disable all uplinks d) Build an IPsec tunnel to the switch 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. Q7 · Analyze Marvis shows the "Successful Connects" SLE failing only on VLAN 40, only between 6–9 PM. Which root cause fits the evidence best? a) The switch PSU is failing b) DHCP scope exhaustion on the guest VLAN at peak hours — widen the pool or shorten lease time c) The L2TPv3 tunnel is down d) The mist-dpc group is undefined 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. Q8 · Analyze 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? a) Reboot the Mist cloud b) Switch the APs to local breakout permanently — tunnels are unsupported c) Disable RadSec on 2083 d) Re-IP the tunnel-termination interface onto its own subnet (OOBM and tunnel-IP must differ) and open UDP 1701/500/4500 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. Q9 · Evaluate 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. a) Sound — centralizing everything is always best for visibility b) Sound — but only if you disable SLEs c) Flawed — tunneling everything drags local guest/CCTV traffic across the WAN and can saturate it; tunnel only the VLANs that truly need central policy and break the rest out locally d) Flawed — Mist Edge can't handle more than one store 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). Q10 · Evaluate 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? a) Local breakout at the home AP + port-forward RADIUS to the internet b) Mist Edge L2TPv3/IPsec tunnel for the HQ VLAN + a RadSec proxy (TCP 2083) on the Edge to relay 802.1X to the internal RADIUS c) A static port profile on the home AP d) Dynamic port profiles on the switch only 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. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again". ### 🧠 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). Remind me Saved — see you in 3 days. ### 📖 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 --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt