Juniper Mist Künstliche Intelligenz und Optionen zur Fehlerbehebung

1. Lernziele

Mist AI, PACE, Marvis Conversation, Actions und Minis voneinander abgrenzen,
Telemetrie, Baseline, SLE und Classifier als Evidenzkette erklären,
natürliche Sprache und strukturierte Abfragen zielgerichtet verwenden,
Driver-Assist- und Self-Driving-Aktionen sicher unterscheiden,
Wireless-, Wired- und WAN-Probleme full-stack korrelieren,
Dynamic und Manual Packet Capture korrekt einsetzen,
KI-Ergebnis durch Events, Messwerte und Gegenprobe validieren,
eine supportfähige Falldokumentation erstellen.

Leitfrage: Welche beobachteten Daten stützen welche Diagnose, welche Aktion folgt daraus – und wodurch wird nachgewiesen, dass die Ursache tatsächlich beseitigt wurde?

2. Was bedeutet „Mist AI“?

Mist AI bezeichnet nicht ein einzelnes Modell und auch keinen universellen Chatbot. Es ist ein System aus kontinuierlicher Telemetrie, Datenverarbeitung, Korrelation, maschinellem Lernen, Service-Level-Bewertung, Anomalieerkennung und automatisierten Workflows.

Beobachten

APs, Switches, WAN Edges, Clients und Cloudservices liefern Zustände, Events und Performancewerte.

Einordnen

PACE, SLEs, Classifier und Baselines verdichten die Daten zu Nutzerwirkung und wahrscheinlichen Ursachen.

Handeln

Marvis erklärt, priorisiert, empfiehlt oder führt für unterstützte Actions freigegebene Korrekturen aus.

Mist AI = Telemetrie + Kontext + Korrelation + Modelle + Automatisierungsworkflow

Die Plattform kombiniert deterministische Regeln mit statistischen beziehungsweise lernenden Verfahren. Nicht jede Anzeige und nicht jede automatische Reaktion ist deshalb „KI“ im engeren Sinn.

3. Datenbasis und Kontext

Datenquelle	Beispiele	Beitrag
Wireless Client	Association, Auth, DHCP, DNS, RSSI, SNR, Roam, Retries	reale Verbindungserfahrung
Access Point	Radiozustand, RF-Umgebung, Uplink, Reboots, Firmware	Funk- und AP-Kontext
Switch	Portstatus, VLAN, PoE, LAG, Fehler, Tabellen, Auth	Wired Underlay
WAN Edge	Uplinks, ARP, DHCP, BGP, Tunnel, Loss, Latency, Jitter	WAN- und Applikationspfad
Cloud/Config	Template, Version, Changes, Site- und Org-Kontext	Sollzustand und Änderungsursache
Marvis Minis	synthetische Auth-, DHCP-, ARP-, DNS- und Curl-Tests	proaktive Erfahrung ohne echten Benutzer
Marvis Client	Clientseitige Verbindung und Telemetrie	Perspektive des Endgeräts

Juniper beschreibt für Wi-Fi Assurance mehr als 150 Zustandsänderungen pro Client und AP, die in kurzen Abständen erfasst werden. Die fachliche Aussage bleibt dennoch vom konkreten Gerät, der Lizenz, Firmware und vorhandenen Telemetrie abhängig.

Kein Messwert ohne Kontext: Ein schlechter RSSI, ein DHCP Timeout oder ein hoher Portfehlerzähler beantwortet allein weder Scope noch Root Cause.

4. PACE, SLEs und Classifier

Die Predictive Analytics and Correlation Engine (PACE) verarbeitet Streaming-Telemetrie zu Service Level Expectations. SLEs bewerten die Nutzererfahrung; Classifier zerlegen fehlgeschlagene User Minutes in technisch interpretierbare Ursachenbereiche.

Rohtelemetrie→User Minutes→SLE→Classifier→betroffene Objekte→Insights

Ebene	Frage	Beispiel
SLE	Welcher Experience-Bereich verfehlt das Ziel?	Successful Connects
Classifier	Welcher Prozessschritt trägt zum Misserfolg bei?	DHCP
Sub-Classifier	Welches konkrete Muster wurde erkannt?	DHCP Timeout
Scope	Wo und bei wem trat es auf?	Site, WLAN, AP, Client
Evidence	Welche Events oder Pakete belegen es?	Discover ohne Offer

Die SLE-Kette verkürzt die Suche. Sie ersetzt nicht die Prüfung, ob der Classifier Symptom, Ursache oder Folge einer übergeordneten Störung ist.

5. Was KI leisten kann – und was nicht

Leistung	Nutzen	Grenze
Anomalien erkennen	Abweichung früher sichtbar	ungewöhnlich ist nicht automatisch fehlerhaft
Daten korrelieren	zeitliche und topologische Zusammenhänge	Korrelation beweist keine Kausalität
Root Cause priorisieren	Suchraum wird kleiner	unvollständige Telemetrie begrenzt Diagnose
Handlung empfehlen	klarer nächster Schritt	Change-Risiko bleibt kontextabhängig
unterstützte Aktion ausführen	schnelle, wiederholbare Remediation	nur definierte Actions und Berechtigungen
Erfolg validieren	Wiederauftreten wird beobachtet	Validierungsfenster ist kein Langzeitbeweis

KI-Hypothese + technische Evidenz + kontrollierte Änderung + Wirkungskontrolle = belastbarer Befund

Fachliche Grundregel: Marvis darf die Diagnose beschleunigen. Die Beweisführung bleibt Aufgabe des verantwortlichen Betriebsprozesses.

6. Marvis Conversational Assistant

Marvis stellt eine natürlichsprachliche Oberfläche für Suche, Dokumentation und Fehlerbehebung bereit. Juniper beschreibt NLP und NLU zur Kontextualisierung von Anfragen. Die Funktionen umfassen Informationen zu Sites, Geräten, Clients und Anwendungen sowie deren Troubleshooting.

Troubleshoot

Site, Anwendung, Gerät oder Wired-/Wireless-Client untersuchen.

Search

Benutzer, Clients, Geräte und Sites finden.

Documentation

Passende Juniper-Mist-Dokumentation suchen.

Marvis Actions

Offene beziehungsweise bearbeitete Actions aufrufen.

Für die Conversational-Funktion nennt Juniper eine passende Marvis-Subscription und ein Benutzerkonto mit Zugriff auf alle Sites der Organisation als Anforderungen. Rechte und Subscription sind daher zuerst zu prüfen, wenn Ergebnisse fehlen.

7. Gute Fragen an Marvis

Eine präzise Frage enthält Objekt, Scope, Symptom und Zeitraum. Bei Bedarf folgt eine zweite Frage nach Ursache, Evidenz oder betroffenen Komponenten.

Schwach	Besser	Warum?
„Wi-Fi ist schlecht.“	„Troubleshoot wireless client 34:… at Site Berlin during the last 2 hours.“	Objekt, Ort und Zeit sind begrenzt
„Warum geht DHCP nicht?“	„Show DHCP failures for WLAN Corp at Site A today and impacted APs.“	Scope und betroffene Infrastruktur
„Ist der Switch kaputt?“	„Show health, port errors and critical events for switch EX-A since 08:00.“	prüfbare Indikatoren
„Teams ruckelt.“	„Troubleshoot Teams for client X at Site B in the last 30 minutes.“	App-, Client- und Zeitkontext

Prüfung der Antwort

Hat Marvis das richtige Objekt aufgelöst?
Ist der betrachtete Zeitraum korrekt?
Welche Messwerte und Events werden genannt?
Ist die Aussage Beobachtung, Schlussfolgerung oder Empfehlung?
Welche alternative Ursache bleibt möglich?
Welcher Drill-down bestätigt das Ergebnis?

8. Marvis Actions

Marvis Actions zeigt hochwirksame Probleme und empfohlene Maßnahmen für Wireless, Wired und WAN – je nach Plattform auch auf MSP-, Organization- oder Site-Ebene. Juniper nennt unter anderem Firmware-Compliance, defekte Kabel, Layer-2-Loops und WAN-Link-Ausfälle.

Driver Assist

Marvis liefert Details und Empfehlung. Der Administrator bewertet und startet beziehungsweise realisiert die Korrektur.

Self-Driving

Nach erforderlicher Freigabe führt Marvis eine für diese Action unterstützte Korrektur automatisch aus.

Detected
Telemetrie und Kriterien erzeugen eine Action.

Scoped
Betroffene Site, Geräte, Ports, Clients oder Pfade werden zugeordnet.

Recommended
Details, Ursache und nächster Schritt werden dargestellt.

Remediated
Admin oder Self-Driving führt die Korrektur aus.

Validated
Marvis beobachtet, ob das Problem im Validierungszeitraum erneut auftritt.

Subscriptions bestimmen, welche Actions sichtbar sind. Der aktuelle Action-Katalog ist deshalb in der jeweiligen Organisation und Dokumentation zu prüfen.

9. Self-Driving und AI Validated

Self-Driving-Berechtigungen können laut Juniper auf Organization- oder Site-Ebene gesetzt werden; Sitewerte können Organization-Vorgaben überschreiben. Grundsätzlich ist die Self-Driving-Freigabe deaktiviert, einzelne Actions bilden jedoch dokumentierte Ausnahmen.

Open→Self-Driving erlaubt→Korrektur→Marvis Self Driven→Beobachtung→AI Validated

Status	Bedeutung
Open	Problem ist aktiv oder nach automatischer Korrektur wieder aufgetreten
Marvis Self Driven	Self-Driving hat die vorgesehene Remediation durchgeführt
AI Validated	Problem wurde während des Validierungszeitraums nicht erneut beobachtet

Wird Self-Driving deaktiviert, können bereits laufende Aufgaben laut Juniper noch abgeschlossen werden; nachfolgende Aufgaben werden nicht mehr automatisch gestartet.

AI Validated bedeutet: Im vorgesehenen Beobachtungsfenster trat das erkannte Muster nicht erneut auf. Es ist kein universeller Beweis für Fehlerfreiheit.

10. Wireless Actions

Action	Erkennung / Zweck	Mögliche Reaktion
Offline	Site, Switch oder einzelner AP ohne Cloudverbindung; lokal online/offline differenzierbar	Scope und Upstream prüfen
Health Check Failed	mögliches Hardware- oder Softwareproblem	Firmwareupgrade oder Austausch
Non-Compliant	abweichende ältere Firmware gegenüber APs desselben Modells	manuelles oder freigegebenes automatisches Upgrade
Dynamic Capacity Optimization	mehrere APs mit geringer Kapazität oder ein dauerhaft überlasteter AP	Band-/Radiomodus und Kanalbreite optimieren
DFS Optimization	Radarhistorie und Wirkung auf Kanalzuweisungen	RRM-gestützte DFS-Optimierung
Mist Edge Anomaly	ungewöhnlicher Traffic oder Tunnelbetrieb am Mist Edge	Edge-/Tunnelanalyse

Juniper dokumentiert Dynamic Capacity Optimization als standardmäßig nicht für Self-Driving freigegeben. DFS Optimization ist dagegen self-driving aktiviert und kann aktuell nicht deaktiviert werden. Diese Sonderregel wird vor Governance-Aussagen ausdrücklich berücksichtigt.

11. Wired Actions

Beispiel	Beobachtung	Korrektur / Grenze
Port Stuck	Port leitet trotz Zustand nicht korrekt weiter	automatischer Port Bounce; laut Juniper maximal drei Versuche
Rogue DHCP Server Detected	wiederholte Offers eines unbekannten Servers, zu Port/VLAN/Site zugeordnet	Access-Port deaktivieren; nicht auf Trunk-Port anwenden
Bad Cable	physische beziehungsweise Fehlerindikatoren am Link	Kabel, Patchweg und Gegenstelle prüfen
L2 Loop	korrelierte Loop-Indikatoren	Topologie, STP und betroffene Ports prüfen
Non-Compliant	Firmware-/Konfigurationsabweichung	Change kontrolliert planen

Beim Rogue-DHCP-Fall ist die automatische Portabschaltung sicherheitswirksam, aber auch disruptiv. Vor Freigabe sind Access-/Trunk-Erkennung, Uplinkschutz, Ausnahmen und Incident-Prozess zu prüfen.

12. WAN Actions

Action	Fachlicher Inhalt
MTU Mismatch	Hinweis auf nicht passende MTU im Pfad
Intermittent WAN Connectivity	ISP-ARP- oder ISP-DHCP-Ausfälle; automatische Port-Bounces bis zur dokumentierten Grenze
Bad WAN Uplink	nach aktueller Abgrenzung schlechte LTE-Konnektivität mit Signalmetriken
VPN Path Down	Ausfall eines erwarteten VPN-/Overlaypfads
Non-Compliant	bei SRX kann Snapshot die Backup-Partition an die primäre Junos-Version angleichen
Negotiation Incomplete	Autonegotiation-/Duplexproblem am WAN-Port

Juniper hat die Trennung zwischen Bad WAN Uplink und Intermittent WAN Connectivity 2025 überarbeitet. Alte Screenshots oder Schulungsunterlagen können daher abweichende Zuordnungen enthalten.

13. Potential Anomalies and Optimizations

Marvis analysiert Echtzeitdaten aus APs, Switches und WAN Edges und kann mögliche Anomalien als Frühwarnsignale anzeigen. Juniper ordnet sie in Site Insights unter Events → Potential Anomalies and Optimizations ein.

Potential Anomaly

Ein ungewöhnliches oder möglicherweise problematisches Muster mit empfohlener Untersuchung.

Confirmed Incident

Ein durch User Impact, Events und technische Evidenz bestätigter Fehler.

Anomalien können siteweit – etwa DHCP-Ausfälle – oder gerätebezogen – etwa Device Health – sein. Sie sind für proaktiven Betrieb nützlich, müssen aber nach Scope, Impact und Wiederholbarkeit priorisiert werden.

Anomalie ist kein Schuldspruch: Erst die Verbindung zu betroffenen Nutzern, Services oder technischen Grenzwerten macht sie handlungsrelevant.

14. Marvis Minis – Digital Experience Twin

Marvis Minis erzeugt synthetische Clienttransaktionen, um Verbindungen proaktiv zu prüfen, auch wenn gerade kein realer Benutzer betroffen ist. Die Tests lernen APs, WLANs, Switches und aktive VLANs und passen ihren Scope an.

Authentifizierung→DHCP→ARP→DNS→Curl / Anwendung

Wireless Minis

Simulieren Benutzerverbindungen über ausgewählte APs und erweitern den Scope bei beobachtetem Fehler.

Wired Minis

Laufen auf unterstützten EX Switches, prüfen bis zu 16 vorrangig aktive VLANs und vermeiden Überschneidungen mit Wireless-Tests.

Juniper nennt für Wired Minis RADIUS, DHCP, ARP, DNS und Curl. Standardmäßig werden unter anderem Microsoft Teams, Office, Apple Captive Portal und Googles Connectivity Check getestet; eigene Anwendungen können definiert werden.

Wenn Minis nicht validiert

aktive Marvis-for-Wireless- beziehungsweise passende Subscription prüfen
Organization- und Site-Aktivierung prüfen
mindestens ein aktives WLAN mit getaggtem oder ungetaggtem VLAN
Firmwarevoraussetzungen für alle APs der Site prüfen
Site-Override gegenüber Organization-Einstellung beachten

15. Insights als Beweisraum

Insights verbindet Timeline, Events, Zustände und Messwerte für Site, Gerät oder Client. Hier wird geprüft, ob die von SLE oder Marvis genannte Ursache im gleichen Zeitraum und Scope sichtbar ist.

Ebene	Beispielprüfung
Site Insights	gleichzeitige Ausfälle, kritische Alerts, Anwendungen und Full-Stack-Swimlanes
AP Insights	Uplink, Radio, Reboot, Firmware, Clients und RF-Ereignisse
Client Insights	Association bis DNS, Roaming, RSSI/SNR, Datenraten und Timeline
Switch Insights	Port, VLAN, Auth, Fehler, PoE, CPU/Memory und Konfigurationsereignisse
WAN Insights	ARP/DHCP/BGP, Tunnel, Pfade, Loss, Latency und Jitter

gleicher Scope + gleicher Zeitraum + topologischer Pfad = sinnvolle Korrelation

16. Dynamic und Manual Packet Capture

Dynamic PCAP

Kurzer Capture wird bei unterstützten Fehlerereignissen automatisch ausgelöst. Das Ereignis trägt in Insights ein Büroklammer-Symbol.

Manual PCAP

Gezielte Capture-Session für Wireless, Wired, WAN oder Mist Edge mit Objekt, Dauer, Paketanzahl/-größe und Filtern.

Beispiele für Dynamic-PCAP-Trigger

Domäne	Beispiele
Wireless	DHCP Timeout, DHCP Denied, DHCP Terminated und weitere Verbindungsfehler
WAN/SSR	ARP zum Next Hop, DHCP-Auflösung, BGP Peering, Overlay Path

Juniper weist darauf hin, dass Mist aus Packet Captures keine Payloaddaten sammelt oder speichert, sondern Übertragungs- und Verbindungsdaten verwendet. Die konkrete Capture-Datei bleibt dennoch sensibel und ist entsprechend zu behandeln.

Manuelle Optionen

Canned Filters passend zur Netzwerkart
Advanced Filters in tcpdump-Syntax
Expression Builder für Filterausdrücke
Header-/Truncation-Einstellungen und lokaler Buffer
Capture-Dauer und Umfang so klein wie erforderlich

Plattformgrenze: Juniper dokumentiert Dynamic PCAP für WAN Edge, weist aber aus, dass SRX Series Firewalls dort kein Dynamic Packet Capture unterstützen.

17. Manuelle Fehlerbehebungsoptionen

Werkzeug	Einsatz	Beispiel
Event Timeline	Änderung und Störung zeitlich verbinden	Firmwareupdate vor Reboot
SLE Drill-down	User Impact und Classifier quantifizieren	DHCP User Minutes
Device/Client Insights	Objektbezogene Messwerte und Zustände	Client-Roamingverlauf
Packet Capture	Protokollablauf beweisen	Discover ohne Offer
Switch Tools	Cable Test, Port Bounce, Tabellen und Portdetails	physischer Fehler
AP-/Radio Tools	Radio Events, RF-Werte, Reboot oder kontrollierter Test	DFS/Kanalwechsel
WAN Tests	Path-, Tunnel-, ARP-, BGP- und SLA-Prüfung	Intermittent Connectivity
API	reproduzierbare Datenabfrage und Integration	SLE-Zeitreihe exportieren

Manuelle Werkzeuge ergänzen KI dort, wo die Hypothese verifiziert, ein nicht unterstützter Scope untersucht oder eine kontrollierte Gegenprobe durchgeführt werden muss.

18. Beweisorientierter Troubleshooting-Workflow

1. Symptom normieren
Wer, was, wo, wann, wie oft und welche Auswirkung?

2. Scope bestimmen
Ein Client, WLAN, AP, Switch, Site, ISP oder mehrere Sites?

3. SLE und User Minutes
Betroffenen Experience-Bereich und tatsächlichen Impact prüfen.

4. Classifier
Fehlerphase und Sub-Classifier eingrenzen.

5. Marvis fragen
Objekt, Site und Zeitraum explizit nennen; Evidenz und Empfehlung abfragen.

6. Actions/Anomalies
Offene, self-driven oder validierte Vorgänge im Scope prüfen.

7. Insights korrelieren
Client-, AP-, Switch- und WAN-Timeline auf denselben Zeitpunkt ausrichten.

8. PCAP oder manueller Test
Protokollablauf beziehungsweise physische Hypothese beweisen.

9. Kleinste Korrektur
Change-Risiko, Freigabe und Rollback definieren.

10. Validieren
SLE, Event, User Impact und Wiederauftreten nach der Änderung prüfen.

19. Drei typische Fehlerszenarien

A. Client erhält keine IP-Adresse

Successful Connects→DHCP Classifier→Client Insights→Dynamic PCAP→Switch/VLAN/Server

Discover ohne Offer belegt den Timeout aus Clientsicht, aber nicht automatisch einen defekten DHCP-Server. VLAN, Relay, Snooping, Portpfad und Servererreichbarkeit bleiben zu prüfen.

B. APs einer Site offline

Offline Action→Scope→Switch/ISP/Cloud→lokal online?→gemeinsame Ursache

Sind alle APs hinter demselben Switch oder ISP betroffen, ist der einzelne AP als Root Cause weniger wahrscheinlich.

C. Schlechte Anwendungserfahrung

Client/App→Wireless SLE→Wired Path→WAN SLE→App-/Partner-Link

Guter RSSI schließt Capacity, Retries, Switch-, WAN- oder SaaS-Probleme nicht aus. Die Fehlerdomäne wird entlang des tatsächlichen Pfads ermittelt.

20. Supportfähige Eskalation

Auf der Ticketseite bietet Juniper Self-Help, Dokumentationshinweise und für Marvis-Abonnenten AI-generierte Antworten sowie Troubleshooting-Schaltflächen für betroffene Sites, Geräte und Clients.

Ein vollständiger Supportfall enthält

Organization, Site und Cloudregion
betroffene Device-/Client-IDs und keine bloßen Anzeigenamen
exakter Zeitraum mit Zeitzone
reproduzierbares Symptom und Business Impact
SLE, Classifier und User Minutes
relevante Events und Marvis-Action-Status
PCAP beziehungsweise technische Belege
bereits durchgeführte Änderungen und Ergebnis
Firmware, Topologie und effektive Konfiguration
klare technische Fragestellung

Vor dem Ticket: Marvis kann den Fall eingrenzen. Wenn keine belastbare Lösung entsteht, wird nicht weiter geraten, sondern mit vollständiger Evidenz eskaliert.

21. Governance für KI und Self-Driving

Kontrolle	Anforderung
Berechtigung	Organization-/Site-Scope und Action-spezifische Freigaben dokumentieren
Change-Klasse	Port Bounce, Port Disable, Firmware oder RF-Änderung nach Risiko einordnen
Ausnahmen	kritische Ports, Sites, Wartungsfenster und Sondergeräte berücksichtigen
Nachvollziehbarkeit	Action, Zeitpunkt, betroffene Objekte und Status protokollieren
Rollback	für reversible Aktionen klar definieren; Hardwarefehler separat behandeln
Validierung	AI Validated plus eigene SLE-/Serviceprüfung
Review	Fehlaktionen, Wiederholungen und Nutzen regelmäßig bewerten
Datenschutz	Client-, User-, Location- und PCAP-Daten nach Zweck minimieren

Automatisierung ist besonders wertvoll bei gut definierten, wiederholbaren Fehlerbildern mit begrenzter Aktion und messbarem Erfolg. Je größer der mögliche Ausfallradius, desto enger müssen Freigaben und Guardrails sein.

22. Fehlerbehebungs- und Abnahmecheckliste

Analyse

Symptom und Impact erfasst
Scope und Zeitraum korrekt
Telemetrielücke ausgeschlossen
SLE und Classifier geprüft
Marvis-Objektauflösung korrekt
Actions und Anomalien geprüft
Full-Stack-Pfad korreliert
Evidenz gesichert

Korrektur

kleinste wirksame Änderung
Risiko und Freigabe geklärt
Self-Driving-Scope geprüft
Rollback vorhanden
SLE danach verbessert
keine neue Nebenwirkung
Wiederauftreten beobachtet
Befund dokumentiert

Häufige Fehlannahmen

Behauptung	Bewertung	Fachliche Einordnung
„Mist AI ist nur ein Chatbot.“	Falsch	Conversation ist nur eine Oberfläche; SLEs, PACE, Actions, Minis und Automatisierung gehören ebenfalls zum System.
„Eine Marvis-Antwort beweist die Ursache.“	Falsch	Die Aussage wird mit Scope, Events, Messwerten und gegebenenfalls PCAP validiert.
„Self-Driving ist überall automatisch aktiv.“	Falsch	Freigaben und Defaults sind Action-spezifisch; DFS Optimization ist eine dokumentierte Sonderregel.
„AI Validated bedeutet dauerhaft fehlerfrei.“	Falsch	Das Muster wurde im Validierungszeitraum nicht erneut beobachtet.
„Marvis Minis sind echte Clients.“	Falsch	Sie simulieren Clienttransaktionen als Digital Experience Twin.
„Dynamic PCAP enthält immer den ganzen Paketinhalt.“	Falsch	Juniper beschreibt Verbindungs-/Übertragungsdaten und keine gespeicherte Payload; Captureumfang ist zu prüfen.
„DHCP Timeout beweist einen defekten Server.“	Falsch	Relay, VLAN, Snooping, Pfad oder Verlust können denselben Befund erzeugen.
„Korrelation ist Kausalität.“	Falsch	Eine zeitliche Beziehung ist eine Hypothese, bis sie technisch belegt ist.

Merksätze

Mist AI ist ein System, kein einzelner Algorithmus.
SLEs quantifizieren Nutzerwirkung; Classifier strukturieren die Ursache.
Marvis beschleunigt die Diagnose, ersetzt aber nicht die Beweisführung.
Driver Assist empfiehlt, Self-Driving handelt innerhalb definierter Grenzen.
AI Validated ist eine Beobachtung im Validierungsfenster.
Marvis Minis prüfen Experience ohne realen Benutzer.
Insights verbinden Zeit, Objekt, Event und Messwert.
Dynamic PCAP konserviert den Fehlerzeitpunkt; Manual PCAP prüft gezielt.
Korrelation erzeugt eine Hypothese, nicht automatisch Kausalität.
Jede Remediation endet mit einer messbaren Wirkungskontrolle.

Offizielle Grundlagen

Stand der fachlichen Prüfung: August 2026. Marvis-Funktionen, Action-Katalog, Self-Driving-Defaults, Firmwareanforderungen, Packet-Capture-Unterstützung, Rollen und Subscriptions können sich ändern. Für produktive Entscheidungen gelten die aktuelle Juniper-Dokumentation, Cloudregion, Plattform, Firmware und wirksame Konfiguration.