Juniper Mist – Marvis-Abfragen

1. Lernziele

Conversational Assistant und Marvis Query Language unterscheiden,
Query Type, Object, Value, Clause, Filter und Duration erklären,
LIST, COUNT, RANK, LOCATE und TROUBLESHOOT passend auswählen,
STATUSOF, ROAMINGOF und UTILIZATIONOF einordnen,
Wireless-, Wired- und Mist-Edge-Abfragen formulieren,
mehrdeutige Namen, Scope und Zeitraum beherrschen,
Tabellenergebnisse und CSV-Exporte korrekt interpretieren,
Marvis-Ergebnisse über SLEs, Insights und Events validieren.

Leitfrage: Welcher Abfragetyp liefert für die konkrete Betriebsfrage die kleinste, eindeutig definierte und technisch überprüfbare Ergebnismenge?

2. Zwei Wege zur Abfrage

Conversational Assistant

Freie natürliche Sprache mit Rückfragen und Folgekontext. Geeignet für Erklärungen, Suche, Dokumentation und geführtes Troubleshooting.

Marvis Query Language

Strukturierte, vom Portal geführte Abfrage. Geeignet für Listen, Counts, Rankings, Geräte-/Eventdaten und reproduzierbare Auswertungen.

Kriterium	Conversation	MQL
Eingabe	natürliche Sprache	vorgegebene Query-Elemente
Antwort	erklärend und dialogorientiert	häufig Tabelle, Grafik oder Rohdaten
Reproduzierbarkeit	vom Dialogkontext abhängig	Query String kann mit Export erhalten bleiben
Stärke	unscharfe Frage eingrenzen	definierte Datenmenge untersuchen
Einstieg	Marvis-Symbol im Portal	`Marvis → Marvis Actions → Ask a Question`

Conversation erklärt | MQL selektiert, zählt, priorisiert und untersucht

3. Voraussetzungen und Sichtbarkeit

Welche Abfragen, Objekte und Ergebnisse verfügbar sind, hängt von Subscription, Rolle, Sitezugriff, betriebenen Netzwerkdomänen und vorhandener Telemetrie ab.

aktive Marvis-Subscription für die benötigte Funktion
Zugriff auf die betroffenen Organisationen und Sites
Geräte sind geclaimt, einer Site zugewiesen und liefern Telemetrie
Wireless-, Wired-, WAN- oder Mist-Edge-Domain ist tatsächlich vorhanden
Objektnamen beziehungsweise MAC-Adressen sind eindeutig auflösbar
Zeitraum liegt innerhalb der verfügbaren Datenhistorie

Für den Conversational Assistant nennt Juniper ein Konto mit Zugriff auf alle Sites der Organisation als Voraussetzung. Für API-Troubleshooting nennt Juniper unter anderem Organization-level Marvis, einen gültigen Observer-API-Token und je nach Abfrage Device-MAC oder Site-ID/-Name.

Leeres Ergebnis ist kein Gegenbeweis: Es kann bedeuten, dass kein passendes Ereignis existiert – oder dass Scope, Rechte, Objekt, Zeitraum beziehungsweise Datenquelle nicht passen.

4. Aufbau der Marvis Query Language

Juniper beschreibt eine MQL-Abfrage als Kombination mehrerer Elemente. Nicht jede Abfrage benötigt jedes Element; die Oberfläche bietet nach einem Leerzeichen die jeweils zulässigen Folgeschritte an.

Query Type+Query Object / Value+Clause+Filter+Duration

Element	Funktion	Beispiele
Query Type	gewünschte Operation	LIST, COUNT, RANK, LOCATE, TROUBLESHOOT
Query Object	Mist-definierte Entität oder Ereignisklasse	APs, ApEvents, Clients, ClientEvents, Switches
Value	organisationsspezifischer konkreter Wert	AP-Name, Site-Name, Clientname
Clause	verbindet oder qualifiziert	WITH, BY, OF
Filter Type	grenzt die Ergebnismenge ein	Site, AccessPoint, Problem, Event Type
Duration	zeitliche Begrenzung	DURING <time duration>

QUERY_TYPE OBJECT/VALUE [CLAUSE FILTER VALUE] [DURING TIME]

Die Schreibweise in dieser Unterlage zeigt Muster. Verbindlich ist die im eigenen Portal angebotene Autovervollständigung, da Juniper Objekte und Filter erweitert.

5. Eine strukturierte Abfrage erstellen

1. Betriebsfrage
Soll Marvis Details listen, die Menge zählen, eine Rangfolge bilden, ein Objekt lokalisieren oder einen Fehler untersuchen?

2. Query Type
Passende Operation auswählen und Leerzeichen drücken.

3. Object oder Value
Nur die vom Portal angebotene Entität beziehungsweise das konkrete Objekt wählen.

4. Scope
Site, AP, Client, Switch, Mist Edge oder andere verfügbare Filter ergänzen.

5. Duration
Bei Ereignissen und Fehlern den relevanten Zeitraum begrenzen.

6. Ergebnis
Zeilen, Einheiten, Sortierung und Scope kontrollieren.

7. Drill-down
Von Tabelle oder Grafik zu Insights, SLEs, Event oder Troubleshoot wechseln.

8. Dokumentieren
Query String, Exportzeit, Zeitzone und Befund sichern.

6. LIST – Details anzeigen

LIST liefert einzelne Entitäten oder Events mit ihren Details. Es ist die richtige Wahl, wenn die konkreten Treffer wichtiger sind als nur deren Anzahl.

LIST ClientEvents WITH AccessPoint <AP name> DURING <time duration>

Clientereignisse eines bestimmten APs im gewählten Zeitraum.

LIST ApEvents WITH AccessPoint <AP name>

AP-Ereignisse für einen konkreten Access Point.

LIST WiredClients WITH Site <site name>

Wired Clients einer Site.

LIST MistEdges WITH Site <site name>

Mist Edges einer Site.

Geeignete Verwendung

Ereignisse einer Fehlerphase vollständig ansehen
betroffene Geräte oder Clients identifizieren
Eigenschaften und Zustände tabellarisch vergleichen
von einem Treffer in Insights oder Troubleshooting verzweigen

7. COUNT – Menge bestimmen

COUNT verwendet grundsätzlich eine ähnliche Struktur wie LIST, liefert aber die Anzahl passender Objekte oder Ereignisse. Von einem Count kann bei unterstützten Ergebnissen zur Eventliste gewechselt werden.

COUNT ClientEvents WITH AccessPoint <AP name> DURING <time duration>COUNT WiredClients WITH Site <site name>COUNT MistEdgeEvents WITH Site <site name>

COUNT beantwortet

Wie groß ist der Scope?
Ist das Ereignis einmalig oder gehäuft?
Welche Site oder Zeitspanne ist stärker betroffen?

Count ohne Nenner: 100 Fehlerereignisse sind ohne Clientanzahl, Traffic, Zeitraum und Wiederholungen pro Objekt nicht automatisch schwerwiegender als 20.

8. RANK – Prioritäten sichtbar machen

RANK sortiert Entitäten nach einer Metrik oder Count-Dimension. Es eignet sich für die Suche nach Top-Talkern, besonders häufig betroffenen Objekten oder auffälligen Konfigurationsgruppen.

RANK Clients BY AuthenticationFailures

Konzeptionelles Beispiel aus der Juniper-Dokumentation: Clients nach Authentifizierungsfehlern priorisieren. Die exakten angebotenen Elemente werden in der Portal-Auswahl bestimmt.

RANK MistEdges BY TunnelCountRANK MistEdges BY MistEdgeEventsCountRANK MistEdgeEventTypes BY MistEdgeEventsCount

Ranking richtig lesen

Prüfung	Warum?
Sortiermetrik	Count, Rate, Auslastung oder anderes Maß nicht verwechseln
Zeitraum	lange Zeiträume bevorzugen häufig aktive Objekte
Scope	Organization-Ranking und Site-Ranking sind nicht vergleichbar
Exposition	viele Fehler können aus sehr vielen Sessions entstehen
Drill-down	Top-Platz ist Startpunkt, kein Root-Cause-Beweis

9. TROUBLESHOOT – Ursache eingrenzen

TROUBLESHOOT kann laut Juniper für Client, AP oder Site verwendet und auf ein Problem beziehungsweise einen Zeitraum begrenzt werden.

TROUBLESHOOT <client/site/AP name>TROUBLESHOOT <client/site/AP name> WITH Problem SlowToConnectTROUBLESHOOT <client/site/AP name> WITH Problem UnableToConnect DURING <time duration>

Das Ergebnis kann Ursache, Band, WLAN und Service-Level-Informationen enthalten. Kategorien lassen sich weiter öffnen, um Details und betroffene Objekte zu prüfen.

TROUBLESHOOT = Analyse eines konkreten Objekts | LIST = Auswahl konkreter Datensätze

Namen eindeutig wählen: Gleichnamige APs oder Sites sowie wechselnde Clientnamen können zur falschen Objektauflösung führen. MAC-Adresse, Sitekontext und angezeigte Identität gegenprüfen.

10. STATUSOF – problematische Clients priorisieren

STATUSOF zeigt Clients mit Verbindungsproblemen und ordnet die am stärksten betroffenen Clients zuerst ein. Juniper empfiehlt die Abfrage als möglichen Startpunkt einer Troubleshooting-Session.

STATUSOF Clients WITH Site <site name>STATUSOF Clients WITH Problem Capacity

Je nach verfügbarer Auswahl können Problemfelder wie Coverage, Throughput oder Connectivity eingegrenzt werden. Vom Clientergebnis geht der Drill-down zu Service Levels, Insights oder TROUBLESHOOT.

Interpretation

Clientranking mit User Impact abgleichen
Site- und WLAN-Kontext kontrollieren
ein dauerhaft schlechtes Gerät von siteweiter Störung unterscheiden
Clientfähigkeiten und Treiber als mögliche Domäne berücksichtigen

11. ROAMINGOF – Clientroaming visualisieren

ROAMINGOF stellt den Weg eines Clients zwischen APs grafisch dar. Rohdaten können unter anderem Zeitpunkt, WLAN, Band, alter/neuer AP und RSSI-Änderung zeigen.

ROAMINGOF <client name> DURING <time interval>

Prüfung	Fachliche Frage
Roam-Zeitpunkt	Passt er zur gemeldeten Unterbrechung?
Old/New AP	Ist der Übergang topologisch plausibel?
RSSI vor/nach	Verbessert oder verschlechtert sich die Funklage?
Band/WLAN	War es reines Roaming oder zusätzlich Band-/SSID-Wechsel?
Cliententscheidung	Welche Scans, Schwellen und Fähigkeiten besitzt der Client?

Roaming-Grundsatz: Die Auswahl des neuen APs trifft grundsätzlich der Client. Die Infrastruktur beeinflusst sie durch RF-Design, Nachbarinformationen und Roaminghilfen.

12. UTILIZATIONOF – Funknutzung untersuchen

UTILIZATIONOF zeigt die von einem AP ausgestrahlten Kanäle und deren Nutzung in 2,4-, 5- und 6-GHz-Bändern. Über Show Channels kann die Ansicht nach einzelnen Kanälen aufgelöst werden.

UTILIZATIONOF <AP name>

Was Channel Utilization nicht allein beantwortet

welcher Anteil durch eigenen BSS-Traffic entsteht,
ob Wi-Fi- oder Non-Wi-Fi-Interferenz dominiert,
ob Clients wegen niedriger Datenraten viel Airtime benötigen,
ob die Anwendung tatsächlich beeinträchtigt ist.

Die Abfrage wird deshalb mit Capacity SLE, RF-/AP-Insights, Clientdaten und RRM-Events korreliert.

13. LOCATE – Site, AP oder Client finden

LOCATE findet Sites, APs oder Clients. Für Sites verwendet Marvis die unter Site Configuration hinterlegte Kartenposition; APs und Clients können auf dem Floorplan dargestellt werden.

LOCATE <site/AP/client>

Das Ergebnis kann zusätzliche Informationen sowie Links zu Insights, Service Levels und Troubleshoot enthalten.

Voraussetzungen für belastbare Positionen

korrekte Siteadresse und Geoposition
aktueller Floorplan mit Maßstab
APs exakt positioniert und orientiert
Clientlokalisierung durch ausreichende Infrastruktur unterstützt
Zeitbezug zwischen letzter Sichtung und aktueller Position beachtet

14. Wireless-Abfragemuster

Betriebsfrage	Geeigneter Einstieg
Welche Clients haben Probleme?	`STATUSOF Clients WITH Site <site>`
Warum verbindet sich Client X nicht?	`TROUBLESHOOT <client> WITH Problem UnableToConnect DURING <time>`
Welche Clientevents sah AP X?	`LIST ClientEvents WITH AccessPoint <AP> DURING <time>`
Wie roamte Client X?	`ROAMINGOF <client> DURING <time>`
Wie ausgelastet sind die Radios von AP X?	`UTILIZATIONOF <AP>`
Wo befindet sich Client oder AP?	`LOCATE <object>`

AP-Inventar und RF-Parameter

Juniper dokumentiert für LIST, COUNT und RANK AP-spezifische Parameter wie Ethernet Port Speed, LLDP Allocated/Negotiated Power, External IP Address sowie Tx Power und Channel für 2,4, 5 und 6 GHz. Die Portalvorschläge bestimmen die genaue Syntax.

15. Wired-Abfragemuster

LIST WiredClients WITH Site <site name>

Inventar der Wired Clients als Ausgangspunkt.

LIST SwitchEvents WITH SwitchEventType <event type> DURING <time>

Muster zur Suche nach Switchereignissen – beispielsweise relevanten STP-Topologieänderungen. Eventtypen werden aus der Portal-Auswahl übernommen.

TROUBLESHOOT <site name>

Siteweite Analyse; im Conversational beziehungsweise API-Kontext die Domäne wired eindeutig festlegen, wenn mehrere Domänen vorhanden sind.

Wired-Ergebnis weiter prüfen

Switch und Port eindeutig
VLAN und Portprofil wirksam
Authentication-/RADIUS-Ergebnis
PoE, Link, Speed und Duplex
STP-, LAG- und Tabellenereignisse
Client-, Switch- und Site-Insights im gleichen Zeitraum

16. Mist-Edge-Abfragen

MQL unterstützt Mist Edges und zugehörige Ereignisse. Juniper dokumentiert Abfragen nach OOBM IP/MAC, Modell, Site, Version, Eventtyp, Tunnel Count und MX-Tunnelstatus.

LIST MistEdges WITH Site <site name>LIST MistEdgeEvents WITH MistEdge <edge name>COUNT MistEdgeEvents WITH Site <site name>RANK MistEdges BY TunnelCount

Weiterhin können APs nach Mist Edge und Up-/Down-Status des L2TPv3-Tunnels gelistet werden. Vom Ergebnis führen Optionen zu Details, Insights, SLEs oder Troubleshooting.

Tunnel Down ist ein Zustand, keine vollständige Ursache: AP-Erreichbarkeit, Edge-Service, Zertifikate, Underlay, MTU, NAT/Firewall und Konfiguration werden entlang des Pfads geprüft.

17. Natürlichsprachliche Abfragen

Der Conversational Assistant versteht natürliche Sprache und kann Rückfragen stellen. Gute Prompts enthalten Absicht, Objekt, Scope, Zeit und gewünschte Evidenz.

Zweck	Beispiel
Inventar	„How many switches are connected at Site Berlin?“
Sitegesundheit	„How is Site Berlin working today?“
Clientfehler	„Troubleshoot wireless client <MAC> at Site Berlin during the last two hours.“
Anwendung	„Why was the Teams call for client <MAC> bad at 10:15?“
Dokumentation	„Show documentation for dynamic packet capture.“
Unhappy Devices	„Show unhappy switches at Site Berlin.“

Folgefragen

„Which devices and users were impacted?“
„What evidence supports this conclusion?“
„Show the timeline for the affected client.“
„What changed immediately before the issue?“
„Which SLE and classifier were affected?“
„What is the recommended next step?“

Englische Beispiele sind in der Dokumentation besonders stabil wiederzufinden. Ob und wie deutschsprachige Formulierungen vollständig interpretiert werden, wird in der eigenen Cloudregion praktisch geprüft.

18. Ergebnisse technisch prüfen

1. Objektauflösung
Site, AP, Switch, Edge oder Client wirklich korrekt?

2. Scope
Organization, Site und Netzwerkdomäne passen?

3. Zeitraum
Start, Ende, Zeitzone und Historie korrekt?

4. Datenform
Count, Liste, Ranking, Rate oder aktueller Zustand?

5. Vollständigkeit
Offline-Geräte, Datenlücken, Pagination oder Filter berücksichtigt?

6. Drill-down
SLE, Insights, Event und gegebenenfalls PCAP öffnen.

7. Gegenprobe
Alternativer Zeitraum, anderes Objekt oder ungefilterte Liste vergleichen.

MQL-Ergebnis = selektierte Daten ≠ automatisch bestätigte Root Cause

19. CSV-Export und Troubleshoot API

MQL-Ergebnisse können laut Juniper als CSV zusammen mit dem Query String heruntergeladen werden. Das verbessert Reproduzierbarkeit und Nachrechnung.

CSV-Dokumentation

Query String unverändert sichern
Organization/Site und Exportzeit notieren
Zeitzone und Duration festhalten
Spalten, Einheit, Sortierung und Nullwerte beschreiben
personenbezogene Clientdaten angemessen schützen

Troubleshoot API

GET /api/v1/orgs/:org_id/troubleshoot?mac=:device_macGET /api/v1/orgs/:org_id/troubleshoot?site_id=:site_id&type=wired

Für Sites kann type auf wireless, wired oder WAN begrenzen; der dokumentierte Default ist wireless. start und end begrenzen den Zeitraum. Die Antwort kann Problemkategorie, Grund, Beschreibung und Empfehlung enthalten.

API-Sicherheit: Tokens gehören nicht in Schulungsunterlagen, Tickets oder Abfragebeispiele. Sie werden mit Least Privilege verwaltet und regelmäßig erneuert.

20. Drei praxistaugliche Workflows

A. Vom Überblick zum Client

STATUSOF Clients→Top Client→TROUBLESHOOT→Insights/SLE→Evidence

B. Vom Count zu Events

COUNT Events→Event List→betroffene Geräte→Timeline→gemeinsame Ursache

C. Vom Ranking zum Designproblem

RANK→Top Objekte→Normalisierung→Config/Insights→kontrollierter Change

Der Workflow endet nicht mit einem Treffer, sondern mit einer überprüften Ursache und einem messbaren Vorher-/Nachher-Ergebnis.

21. Typische Fehler und Korrekturen

Symptom	Ursache	Korrektur
Objekt nicht gefunden	Name falsch, mehrdeutig oder außerhalb des Scopes	Search/LOCATE, MAC und Site prüfen
keine Folgeschritte	ungültige Kombination oder fehlende Subscription	Autovervollständigung ab Query Type neu aufbauen
leeres Eventergebnis	Zeitraum, Eventtyp oder Telemetrie unpassend	Duration erweitern und Filter reduzieren
zu viele Treffer	Site, AP, Eventtyp oder Zeit fehlt	kleinsten sinnvollen Scope ergänzen
Ranking wirkt unplausibel	Aktivität/Exposition nicht normalisiert	Count, Clients, Sessions und Zeitraum vergleichen
Conversation missversteht Frage	Objekt oder Intent mehrdeutig	MAC, Site, Domäne und Zeit explizit nennen
Portal/API weichen ab	Default `type`, Zeitgrenzen oder Objekt-ID	identische Parameter und Zeitzone verwenden
historische Syntax funktioniert nicht	MQL-Objekte wurden weiterentwickelt	aktuelle Portalvorschläge und Dokumentation nutzen

22. Cheat Sheet

Ziel	Query Type	Ergebnis
konkrete Datensätze	`LIST`	Tabelle mit Entitäten oder Events
Anzahl bestimmen	`COUNT`	Menge passender Treffer
Top-Verursacher/Objekte	`RANK`	sortierte Rangfolge
Root Cause eingrenzen	`TROUBLESHOOT`	Problem, Ursache, Details, Empfehlung
problematische Clients	`STATUSOF`	priorisierte Clientliste
Roamingweg	`ROAMINGOF`	grafische und tabellarische Roamingdaten
Kanalauslastung	`UTILIZATIONOF`	Band-/Kanalnutzung eines APs
Position	`LOCATE`	Karte/Floorplan und Objektlinks

Prüfungstaugliche Kurzform: Operation → Objekt → Scope → Filter → Zeitraum → Ergebnisdefinition → technische Validierung.

Häufige Fehlannahmen

Behauptung	Bewertung	Fachliche Einordnung
„Conversation und MQL sind identisch.“	Falsch	Conversation nutzt natürliche Sprache; MQL ist eine strukturierte, geführte Abfragesprache.
„LIST und COUNT liefern dasselbe.“	Falsch	LIST liefert konkrete Treffer, COUNT deren Anzahl.
„Der erste Rang ist automatisch Root Cause.“	Falsch	Ranking priorisiert; Aktivität, Nenner und technische Evidenz bleiben zu prüfen.
„Ein leeres Ergebnis beweist, dass nichts geschah.“	Falsch	Scope, Zeitraum, Rechte oder Telemetrie können unvollständig sein.
„ROAMINGOF zeigt eine AP-Entscheidung.“	Falsch	Der Client entscheidet grundsätzlich über den Roam.
„UTILIZATIONOF beweist Interferenzursache.“	Falsch	Auslastung muss nach RF-Quelle, Clientverhalten und User Impact aufgelöst werden.
„MQL-Syntax bleibt für immer unverändert.“	Falsch	Objekte und Parameter werden erweitert; Portal-Autovervollständigung ist maßgeblich.
„Die API nutzt automatisch die richtige Domäne.“	Falsch	Für Site-Troubleshooting ist der dokumentierte Default wireless; wired/WAN werden explizit gesetzt.

Merksätze

Die Betriebsfrage bestimmt den Query Type.
LIST zeigt Details, COUNT quantifiziert und RANK priorisiert.
TROUBLESHOOT untersucht ein konkretes Objekt oder eine Site.
Scope und Zeitraum gehören in jede Ereignisabfrage.
Die Autovervollständigung zeigt die aktuell gültige MQL-Struktur.
Ein leerer Treffer ist erst nach Scope- und Datenprüfung aussagekräftig.
Rankings brauchen Nenner und Aktivitätskontext.
Conversation eignet sich zum Eingrenzen, MQL zur reproduzierbaren Auswahl.
Der Query String gehört zum CSV-Nachweis.
Jedes Ergebnis wird in SLEs, Insights oder Events technisch geprüft.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. MQL-Objekte, Filter, Querytypen, Produktnavigation, Rollen, Subscriptions und API-Parameter können sich ändern. Für produktive Abfragen gelten die aktuell im Portal angebotene Autovervollständigung, die Juniper-Dokumentation und der konkrete Organization-/Site-Scope.