# Juniper Marvis — Ask a Question, Get a Root Cause, Click to Fix Source: https://ai.techclick.in/blog_mist_marvis_aiops Markdown: https://ai.techclick.in/blog_mist_marvis_aiops.md Publisher: Techclick Infosec Pvt Ltd Juniper Mist Marvis explained the AI-era way — type a plain-English question, watch Marvis turn it into a root-cause, then auto-fix a Missing VLAN or bad cable in self-driving mode. Conversational RCA + Marvis Actions + Minis in 11 visual minutes instead of an hour of CLI. Juniper Marvis — Ask a Question, Get a Root Cause, Click to Fix student learning map A visual study map for Juniper Marvis — Ask a Question, Get a Root Cause, Click to Fix showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Juniper Marvis — Ask a Question, Get a Root Cause,... Juniper Mist · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start By the end you will be able to 2. Understand Pick your path — jump straight to it 3. Prove The wrong way most L1 engineers... 4. Practice ① Talk to Marvis — the... 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 most L1 engineers still troubleshoot It's 9:05 AM. Tickets pile up: "Wi-Fi slow in the Pune cafeteria." The old reflex? SSH into three APs, eyeball show interfaces , grep logs, blame RF, bump transmit power, and pray. Forty minutes gone, root cause still unknown — and you've maybe made co-channel interference worse . Marvis flips that. You don't start from the device. You start from what the user felt and let the AI connect it to what the network actually did. As one practitioner write-up put it: Marvis "starts from what users feel and connects it to what the network did." That single shift is the whole point of AIOps . 🟢 ELI5: Think of Marvis as a super-smart helpdesk friend. Instead of you opening every cupboard to find the broken thing, you just say "the lights flicker in the kitchen" and your friend instantly says "the kitchen plug is loose — want me to push it back in?" 🟣 Architect: Marvis sits on Mist's cloud telemetry pipeline (the same 7th-gen data-science engine feeding the SLEs). Its value is bounded by data quality and integration scope — define clearly what Mist manages vs adjacent legacy/non-Juniper segments, or your RCA will have blind spots at the seams. 💬 Conversational Assistant tap to flip The language front-end . Uses NLP + NLU to understand your plain-English question and route it to the right Mist data. It talks; it doesn't (mostly) change things. 🔧 Marvis Actions tap to flip The back-end engine . Detects high-impact issues across wired/wireless/WAN and either recommends or auto-applies the fix. This is the "self-driving" half. 🧭 Root Cause Analysis tap to flip Marvis decomposes an SLE failure into classifiers and names the dominant sub-cause. Goal: slash MTTR (time to resolve) and MTTI (time to innocence). 🧪 Marvis Minis tap to flip A digital twin that simulates client behaviour (assoc, DHCP, DNS, auth) so problems surface before real users hit them — even on an empty SSID. Warm-up · predict before you read If you type " why are clients failing on SSID Corp in Mumbai? " into Marvis, which part hears your words first — the Conversational Assistant or Marvis Actions? Reveal The Conversational Assistant. It is the NLP/NLU language layer. It interprets intent, fetches the relevant telemetry, and answers. Marvis Actions runs in the background detecting issues — but the typed sentence enters through the Assistant. Warm-up · predict before you read "Self-driving" Marvis Actions means Juniper engineers log in and change your config. True or false? Reveal False. Self-driving means Marvis itself applies a fix automatically — but only for the specific action types you opt into, scoped and audit-logged. No human at Juniper is touching your network. Warm-up · predict before you read Marvis says "Missing VLAN" on an AP's switch port. Whose config is most likely wrong — the AP or the switch? Reveal Usually the switch. The VLAN exists on the AP but isn't trunked on the switch port, so clients on that VLAN can't reach DHCP. Marvis compares both sides and tells you exactly which device — and which port — is missing the tag. Legend Mist AI Engine Telemetry sources & Marvis faces Telemetry flowing up Answers / actions flowing down Marvis Minis (synthetic clients) Marvis AIOps architecture: telemetry feeds the AI engine, which powers the Conversational Assistant and Marvis Actions A layered diagram showing wired, wireless and WAN telemetry flowing up into the Mist AI engine, which splits into the Conversational Assistant for questions and Marvis Actions for fixes, with Marvis Minis injecting synthetic client tests. ① Telemetry from the whole estate (the fuel) 📡 Wireless APs assoc · DHCP · roam · RF 🔌 Wired switches ports · VLANs · cables 🌐 WAN Edge tunnels · apps · paths - 🧠 Mist AI Engine 7th-gen data science · SLE classifiers · RCA 🧪 Marvis Minis synthetic clients 💬 Conversational Assistant NLP + NLU → you ASK, it answers + does guided changes 🔧 Marvis Actions detects + FIXES issues driver-assist or self-driving ② One AI brain → two ways to use it ③ Figure 1 — Telemetry from every layer fuels one AI engine. You consume it two ways: ask the Conversational Assistant, or let Marvis Actions act. Minis injects synthetic clients so issues surface early. ## ① Talk to Marvis — the Conversational Assistant Marvis was the first network assistant to bring conversational AI to networking. You interact two ways: follow its suggested prompts, or just type a sentence — " list unhappy clients on SSID Corp ", " why is the Bangalore office slow? ", " troubleshoot AP3 in Pune ". The NLP reads the words; the NLU figures out what you actually mean and pulls the matching telemetry. S Sneha at Infosys (L1): A user opens a ticket — "Teams keeps dropping in the 4th-floor cafeteria." Instead of SSHing anywhere, Sneha types why is the 4th floor cafeteria having issues? into Marvis. It returns the unhappy clients, the failing SLE, and a one-line root cause. Two minutes, not forty. ### ▶ Watch a plain-English question become an answer Click Play . Each stage lights up as your sentence travels through Marvis. ① YOU TYPE "why is wi-fi bad in the Pune cafeteria?" Plain English. No syntax, no CLI, no filter builder. ▼ ② NLP / NLU Parse intent → scope = site:Pune, area:cafeteria , metric = experience/SLE ▼ ③ FETCH DATA Pull SLE metrics + client events for that scope from the Mist AI engine ▼ ④ RUN RCA Decompose the failing SLE → dominant classifier = Coverage: sticky clients ▼ ⑤ ANSWER "12 clients unhappy. Coverage SLE failing — sticky clients on AP-Pune-07. Suggested: review band steering / min-RSSI." Press Play to step through how Marvis turns words into a root cause. Each press of Next advances one stage. ▶ Play Next ▶ ↺ Reset It can DO, not just SAY The Conversational Assistant isn't read-only. You can query the system and make guided changes through it — Juniper describes it as a GenAI interface where "you can use the conversational interface to query the system and actually do changes to the system." Think of typed conversation as a control surface, not just a search box. Quick check · Q1 of 10 · Remember Sneha at Infosys types "why is Wi-Fi bad in the Pune cafeteria?" into Marvis. Which Marvis component parses that plain-English sentence and turns it into a structured query? a) Marvis Actions — it handles all typed input b) The Marvis Conversational Assistant — NLP/NLU front-end that maps the sentence to the right Mist data and RCA c) Marvis Minis — it answers all questions d) The SLE dashboard — Marvis just renders it Correct: b. The Conversational Assistant uses NLP with NLU to understand intent and context, then maps it to the right Mist data (SLE metrics, events, RCA). It's the language front-end; Marvis Actions is the back-end remediation layer that runs separately. ## ② Conversational Root-Cause Analysis This is the magic word for your exam and your job: RCA . A user says "it's slow." That maps to a failing SLE . Marvis decomposes that SLE into its classifiers and attributes the failure to the dominant sub-cause — using telemetry across many clients, not one anecdote. The payoff is lower MTTR (mean time to resolution) and MTTI (mean time to innocence — proving it's not the network). P Priya at HCL (L2): A VIP complains video calls freeze. The app team blames the Wi-Fi. Priya asks Marvis; RCA points at the WAN path , not the WLAN. That's MTTI — Marvis just proved the wireless network is innocent, and Priya redirects the ticket to the WAN team with evidence, not a shrug. Conversational RCA funnel: a vague complaint narrows to a failing SLE, then to the dominant classifier, then to one fix A funnel from a broad user complaint down through SLE selection, classifier decomposition, and a single root cause with a recommended action. From "it's slow" to one root cause ① Vague complaint: "Wi-Fi is bad / Teams freezes" ② Maps to a failing SLE (e.g. Coverage) ③ Decompose into classifiers Asymmetry Sticky clients ✓ Interference Low RSSI ④ Root cause: sticky clients on AP-Pune-07 Fix: tune band steering / min-RSSI — NOT blindly raise power Figure 2 — RCA is a funnel: complaint → failing SLE → classifier decomposition → one dominant root cause and a targeted fix. The wrong instinct (raise transmit power) is exactly what RCA talks you out of. Pause & predict Coverage SLE is failing. Your gut says "low power — turn the APs up." Marvis RCA says "sticky clients." Who's probably right, and why? Reveal Marvis. Coverage failures are frequently sticky clients clinging to a far AP, not genuinely low transmit power. Cranking power up widens cells, increases co-channel interference, and can make the SLE worse . RCA across many clients beats one engineer's hunch. Quick check · Q2 of 10 · Analyze A site shows a poor Coverage SLE. The Conversational Assistant's RCA points at "asymmetry / sticky clients," not AP transmit power. Why trust the RCA over your gut feeling that it's a power problem? a) RCA always defaults to "sticky clients" regardless of data b) RCA decomposes the SLE into classifiers and attributes the failure using telemetry across many clients — and raising power can worsen co-channel interference c) Transmit power can't be changed in Mist d) Coverage SLE only measures DNS latency Correct: b. Marvis RCA decomposes an SLE into its classifiers and attributes the failure to the dominant sub-cause using real telemetry across many clients. Coverage failures are often sticky clients holding a weak AP — and raising power can increase co-channel interference, making things worse. Quick check · Q3 of 10 · Analyze Marvis flags "Persistently Failing Clients" on one SSID, but only for one specific device type. What is this signalling and where do you look first? a) An anomaly tied to that device population — likely a driver/supplicant or 802.1X/PSK config issue for that family; start with auth/association events for that device type b) A definite AP hardware failure — replace the AP c) An RF interference problem — change every channel d) A cabling fault on the uplink Correct: a. A failure hitting most-but-not-all clients of one type is an anomaly correlated to that client population — typically a driver, supplicant, or 802.1X/PSK issue for that device family, not an AP or RF fault. Start with the auth/association events for that device type, not the radios. ## ③ Marvis Actions — driver-assist vs self-driving The Conversational Assistant talks. Marvis Actions fixes. It lists the high-impact issues Marvis detects across wired, wireless and WAN — at MSP, org and site level — and offers two operating modes. This is the heart of the "self-driving network." 🧑‍✈️ Driver-assist tap Marvis surfaces the issue + the recommended fix, then waits for you to approve . Human stays in the loop. Safe default for high-blast-radius changes. 🤖 Self-driving tap Marvis auto-applies the fix — but only for the action types you opt into. Scoped, audit-logged. You ramp trust one action type at a time. 🏷️ Missing VLAN tap VLAN is on the AP but not trunked on the switch port → clients can't reach DHCP. Marvis compares AP vs switch traffic, names the port, can add the tag. 🔌 Bad Cable / Negotiation tap Marvis flags Ethernet errors as a Bad Cable action, and incomplete duplex/speed auto-neg as a Negotiation Mismatch on the exact port. R Rahul at TCS (L1): The Marvis Action dashboard shows "Negotiation Mismatch" on switch sw-tcs-edge-3 , port ge-0/0/14 , where an AP connects. A previous admin hard-set that port to 100/full . Rahul sets both ends back to auto/auto, the duplex mismatch clears, and the action auto-resolves. No ticket ping-pong. ### ▶ Self-driving fix: a Missing VLAN action Watch Marvis detect, decide, fix and verify a Missing VLAN — with self-driving enabled for that action type. ① SYMPTOM Clients on VLAN 20 (guest) at AP-HCL-12 can't get an IP — DHCP requests time out ▼ ② COMPARE Marvis checks: AP sends VLAN 20 traffic, switch port ge-0/0/8 trunk does NOT carry VLAN 20 ▼ ③ DECIDE Root cause = Missing VLAN on the switch port , not the AP ▼ ④ FIX (self-driving) Marvis adds VLAN 20 to the trunk on ge-0/0/8 — because this action type is opted into self-driving ▼ ⑤ VERIFY Clients on VLAN 20 now get 10.20.0.x from DHCP. Action moves to resolved, logged to the audit trail. In driver-assist, stage ④ would pause for your approval first. Self-driving skips the pause — only for action types you trusted. ▶ Play Next ▶ ↺ Reset The self-driving over-trust trap Symptom you'll see: a VLAN you deliberately pruned from a port for security keeps coming back, and you can't figure out who's re-adding it. Cause: self-driving "Missing VLAN" treats the AP-vs-switch comparison as ground truth, so it "helpfully" re-adds the VLAN. The fix: keep that action in driver-assist for security-sensitive ports, or scope self-driving only to sites where the VLAN model is authoritative. Never blanket-enable self-driving org-wide on day one. Quick check · Q4 of 10 · Apply In Marvis Actions, what is the difference between driver-assist mode and self-driving mode? a) Driver-assist recommends a fix and waits for human approval; self-driving auto-applies the fix for the action types you've explicitly enabled b) Driver-assist is for wired only, self-driving is for wireless only c) Self-driving lets Juniper engineers log in and change your config d) There is no difference — they're marketing names for the same thing Correct: a. Driver-assist surfaces the issue and the recommended fix but waits for a human to approve. Self-driving lets Marvis apply the remediation automatically — but only for the action types you opt into. You ramp up trust gradually, action type by action type. ## ④ Marvis Minis + the guardrails that keep you safe Marvis Minis is a digital-experience twin. It simulates client behaviour — association, DHCP, DNS, authentication — so the AI can find problems before a real human does, even on a freshly built SSID with zero users. Think of it as a robot test-user that walks your network every few minutes so a broken thing gets caught at 2 AM, not at the Monday 9 AM rush. S Sneha at Infosys (L1): A new "Contractor" SSID goes live Friday evening. No one's on it yet. Marvis Minis simulates a client joining — and immediately fails DHCP. Monday morning's 200 contractors never even notice, because the Missing VLAN was caught and fixed over the weekend by a synthetic client, not a real one. Decision tree: should this Marvis Action run self-driving or stay driver-assist? A flowchart that decides whether to enable self-driving for an action type based on blast radius, data authority and security sensitivity. Self-driving or driver-assist? A 3-gate decision New action type to enable High blast radius? driver assist --> YES Security- sensitive? NO ↓ YES Data model authoritative? NO ✅ Enable SELF-DRIVING scoped + audited YES 🧑‍✈️ Keep DRIVER-ASSIST Figure 3 — Three gates before you trust an action to self-driving: blast radius, security sensitivity, and whether the data model is authoritative. Any "wrong" answer → keep it driver-assist. The honest practitioner take Marvis is powerful but not magic. As field write-ups stress, "an AI is only as good as its data set, configuration, and implementation," and it "still needs the hand of an experienced technician to guide and teach it." Two real adoption killers: (1) blind spots at the seams with legacy or non-Juniper segments, and (2) only one engineer knowing how to read the output. Fix both with clear scope and role-based workflows for L1 / NOC / admin. Marvis adoption trust ladder over time, from observe-only to scoped self-driving A rising staircase showing four phases of adopting Marvis: observe, conversational triage, driver-assist remediation, and scoped self-driving, with MTTR falling as trust rises. The trust ladder — earn self-driving, don't switch it on blind Time + confidence → Automation level → 1 · Observe read SLEs + RCA only 2 · Ask conversational triage 3 · Driver-assist approve each fix 4 · Self-driving scoped per action MTTR falling ↘ Figure 4 — Adopt Marvis as a staircase: observe → ask → driver-assist → scoped self-driving. MTTR (dashed) falls as you climb. Skipping straight to step 4 org-wide is the classic rollout mistake. ### 🤖 Ask the AI Tutor Tap any question — instant context-aware answer. No login, no waiting. Conversational Assistant vs Marvis Actions — what's the difference? What is MTTI and why do I care? How does Marvis decide a "Missing VLAN"? Is self-driving safe to turn on everywhere? What exactly are Marvis Minis for? Does BlastRADIUS (CVE-2024-3596) affect how I trust Marvis auth RCA? Pre-curated answers from Juniper Mist docs + community Q&A + the JNCIA-MistAI track. For complex prod issues, paste your Marvis RCA + action details into chat.techclick.in. ## 📝 Wrap-up — six more You've already answered 4 inline. Six left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Evaluate A team launches a brand-new "Contractor" SSID Friday evening with zero users on it. They want assurance it actually works before 200 contractors arrive Monday. Which Marvis capability best meets that need, and why? a) Wait until Monday and read the Conversational Assistant's RCA after users complain — RCA is the only proactive tool b) Marvis Minis — a digital-experience twin that simulates client behaviour (assoc/DHCP/DNS/auth), so it can validate and surface problems proactively even with no real users on the SSID c) Buy a higher Marvis licensing tier to unlock more APs d) Enable self-driving on every action org-wide so any issue auto-fixes Correct: b. Marvis Minis is a digital-experience twin that simulates client behaviour, so it can validate a brand-new SSID and surface problems proactively even with zero real users. Waiting for complaints (a) isn't proactive; a license tier (c) doesn't test experience; blanket self-driving (d) is a reckless rollout, not a validation tool. Q6 · Apply Marvis raises a "Missing VLAN" action for an access point. What does that mean and how did Marvis decide it? a) The AP firmware is out of date b) The AP radio is disabled c) A VLAN is configured on the AP but not on the connected switch port; Marvis compared AP-traffic VLANs vs switch-port VLANs and named the missing device + port d) Two APs share the same IP address Correct: c. Missing VLAN means a VLAN is on the AP but not trunked on the switch port, so clients can't reach DHCP. Marvis compares the VLANs in AP traffic against the VLANs on the switch port, identifies which device is missing the tag, and gives you the exact port. Q7 · Apply Rahul at TCS sees a "Negotiation Mismatch" Marvis Action on a switch port. What is the most likely physical cause and the right first fix? a) A loop — enable spanning tree b) A VLAN trunk problem — add VLANs c) An IP conflict — change the subnet d) A duplex mismatch from failed auto-negotiation (often a hard-set speed/duplex on one side); set both ends to auto/auto, and if errors persist check the cable (Marvis flags Bad Cable separately) Correct: d. Negotiation Mismatch is usually a duplex mismatch where auto-neg failed to settle — frequently a hard-coded speed/duplex on one side or a marginal cable. Set the port to auto/auto on both ends (or correct the hard-set); if errors persist, check the cable, which Marvis surfaces as a separate Bad Cable action. Q8 · Analyze Priya at HCL enables self-driving for "Missing VLAN" but a server VLAN keeps getting re-added to a port she intentionally pruned for security. What went wrong and what should she do? a) The switch is faulty — RMA it b) Marvis was hacked — open a security incident c) Self-driving Missing VLAN trusts the AP-vs-switch comparison as truth and re-adds what she pruned; keep that action in driver-assist for security-sensitive ports, or scope self-driving to sites where the VLAN model is authoritative d) She must disable Marvis entirely Correct: c. Self-driving "Missing VLAN" treats the AP-vs-switch comparison as ground truth, so it re-adds a VLAN removed on purpose. Keep that action in driver-assist for security-sensitive ports, or scope self-driving to sites where the VLAN model is authoritative — don't blanket-enable it org-wide. Q9 · Analyze A VIP says video calls freeze; the app team blames Wi-Fi. Marvis RCA points at the WAN path, not the WLAN. What concept does this illustrate and what's the right next move? a) MTTI (mean time to innocence) — RCA proved the WLAN is innocent; route the ticket to the WAN team with the evidence b) RF interference — change wireless channels c) DHCP exhaustion — extend the scope d) A licensing issue — buy more Marvis seats Correct: a. This is MTTI — mean time to innocence. RCA decomposed the complaint and attributed it to the WAN path, proving the wireless network isn't the culprit. The right move is to hand the WAN team the evidence-backed root cause, not keep digging in the WLAN. Q10 · Evaluate Your security team asks whether enabling Marvis self-driving means an AI can change the network with no guardrails. What's the accurate architect-level answer? a) Yes — once on, Marvis has full unrestricted root b) No — but only because it never actually changes anything c) Self-driving acts only on the specific action types you opt into, scoped and audit-logged; a sane rollout keeps high-blast-radius actions in driver-assist and reviews the audit trail — governed automation, not a black box d) It's identical to giving Juniper engineers a permanent admin login Correct: c. Self-driving acts only on the action types you opt into, scoped and auditable — and an AI is only as good as its data and config. A sane rollout keeps high-blast-radius actions in driver-assist and reviews the Marvis audit trail. Treat it as governed automation, not unrestricted root. 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". ### 🧠 Lock it in — explain it back In one or two sentences, explain to a teammate: what is the difference between the Marvis Conversational Assistant and Marvis Actions, and when would you keep an action in driver-assist? Writing it in your own words is the single biggest memory booster. 👥 Teach-a-friend: Grab a colleague and demo it live — type one real question into your org's Marvis, read the RCA out loud, and decide together whether you'd let that fix go self-driving. Teaching forces the gaps to show. ### ⏰ Remember this in 3 days Spaced repetition beats cramming. Drop your email and we'll send you 3 quick recall questions on Marvis RCA & Actions in 3 days — no spam, one email. Send me the recall ✓ Done — we'll nudge you in 3 days. Keep climbing the trust ladder. ### 📖 Glossary AIOps AI for IT Operations — ML on telemetry to detect, diagnose and optionally auto-fix network issues. NLP / NLU Natural Language Processing reads your words; Natural Language Understanding grasps your intent and context. RCA Root-Cause Analysis — narrowing a symptom down to the one dominant cause. SLE Service-Level Expectation — Mist's user-experience KPIs (Coverage, Throughput, Capacity, Successful Connects). Next lesson's main topic. MTTR / MTTI Mean Time To Resolution / Mean Time To Innocence — how fast you fix it / how fast you prove it isn't your network. Driver-assist vs Self-driving Marvis recommends and waits for approval, vs Marvis auto-applies the fix for opted-in action types. #### 📚 Sources Juniper Networks Docs — Marvis Virtual Network Assistant Overview (Mist AIOps) . juniper.net/documentation - Juniper Networks Docs — Marvis Conversational Assistant . juniper.net/documentation - Juniper Networks Docs — Marvis Actions Overview + Wired / Connectivity / WAN Actions (Missing VLAN, Bad Cable, Negotiation Mismatch). juniper.net/documentation - Juniper Networks — Marvis AI Assistant product + datasheet (GenAI conversational interface, Marvis Minis, self-driving Day-2 ops); 2025 AI Breakthrough Award announcement. - Juniper Certification — JNCIA-MistAI (JN0-253) & JNCIS-MistAI blueprint: Marvis actions, queries and Minis domain. - turn-keytechnologies & CBTS — practitioner field notes on Marvis limitations, self-healing and adoption pitfalls. - Juniper Security Advisories — CVE-2024-3596 (BlastRADIUS) RADIUS MITM; FragAttacks / CVE-2020-24588 Mist AP advisories; 2025-03 Junos OS out-of-cycle bulletin (CVE-2025-21590). ### What's next? Marvis kept pointing at "SLEs" — Coverage, Throughput, Capacity. Next we open that box: how Mist's Service-Level Expectations are scored, what each classifier means, and how Premium Analytics turns raw telemetry into the dashboards your boss actually wants to see. Next · Mist SLEs & Premium Analytics → ← Recap RF & RRM 📩 Quiz me on this in 7 days. Opt in and we'll email you 3 micro-questions from this lesson at Day 1, Day 7 and Day 30 — spaced repetition is how it sticks. Un-tick any time. --- 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