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?

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.

Marvis raises a "Missing VLAN" action for an access point. What does that mean and how did Marvis decide it?

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.

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?

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.

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?

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.

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?

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.

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?

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.

Juniper Mist Marvis & AIOps — Conversational RCA & Actions

Q: 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?

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.

Q: 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?

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.

Q: 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?

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.

Q: In Marvis Actions, what is the difference between driver-assist mode and self-driving mode?

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.

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?

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?

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?

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

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.

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.

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

📖 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

Juniper Marvis — Ask a Question, Get a Root Cause, Click to Fix

By the end you will be able to

Pick your path — jump straight to it

Talk to Marvis

Conversational RCA

Marvis Actions

Minis + Guardrails

The wrong way most L1 engineers still troubleshoot

① Talk to Marvis — the Conversational Assistant

▶ Watch a plain-English question become an answer

② Conversational Root-Cause Analysis

③ Marvis Actions — driver-assist vs self-driving

▶ Self-driving fix: a Missing VLAN action

④ Marvis Minis + the guardrails that keep you safe

🤖 Ask the AI Tutor

📝 Wrap-up — six more

🧠 Lock it in — explain it back

⏰ Remember this in 3 days

📖 Glossary

📚 Sources

What's next?