SLE
Eine in Mist messbare Service-Level-Erwartung an das Benutzererlebnis, etwa Verbindungszeit, Signalqualität oder mögliche Datenrate.
1. Lernziele
- SLE, SLA, KPI und Alarm fachlich unterscheiden,
- User Minutes und versuchsbasierte SLEs korrekt interpretieren,
- Erfolgsrate und Classifier-Anteil getrennt berechnen,
- die sieben Wireless-SLEs und ihre Messgrundlage erklären,
- Schwellen aus Anwendung und Clientrealität ableiten,
- Organization-, Site-, AP-, WLAN- und Client-Scope vergleichen,
- Classifier, Sub-Classifier und Affected Items systematisch nutzen,
- eine SLE-Hypothese durch Events, Logs und Paketdaten bestätigen.
Leitfrage: Welche Nutzer waren wann und in welchem Umfang betroffen – und welcher technische Beweis erklärt die als schlecht bewerteten Minuten oder Verbindungsversuche?
2. Was eine SLE ist – und was nicht
SLA
Eine vertragliche oder organisatorische Vereinbarung mit Leistungsumfang, Messfenster, Verantwortlichkeiten und Konsequenzen. Ein Mist-SLE ist nicht automatisch ein SLA.
KPI
Eine Kennzahl für Betrieb oder Zielsteuerung. Ein SLE kann als KPI verwendet werden, benötigt dann aber Governance und Kontext.
Alarm
Eine Benachrichtigung bei Zustand oder Anomalie. Eine schlechte SLE-Rate ist zunächst eine Messung und nicht automatisch ein Incident.
AP-Telemetrie→normalisierte Erfahrung→SLE + Threshold→Classifier→Root Cause Analysis
Mist sammelt Client- und AP-Zustände und ordnet sie messbaren Benutzererfahrungen zu. Das Ergebnis ist ein Ausgangspunkt für Priorisierung und Diagnose, nicht der alleinige Ursachenbeweis.
3. User Minutes, Versuche und Prozentwerte
User Minute
Eine User Minute entspricht vereinfacht einem verbundenen Gerät über eine Minute. Zehn Geräte über eine Minute ergeben zehn User Minutes; zehn Geräte über drei Minuten ergeben dreißig User Minutes.
User Minutes = Summe der verbundenen Client-Minuten im gewählten Scope
Erfolgsrate
Die Erfolgsrate zeigt, welcher Anteil der Samples beziehungsweise Versuche die SLE-Bedingung erfüllt hat.
Success Rate = 1 − (degraded Samples ÷ total Samples)
Classifier Impact
Classifier-Prozente beziehen sich auf die Fehler, nicht auf sämtliche Samples. Ein Classifier mit 70 Prozent erklärt 70 Prozent der als schlecht klassifizierten Samples.
Classifier Impact = Classifier degraded Samples ÷ Summe aller Classifier degraded Samples
Nicht verwechseln: Bei 95 Prozent SLE-Erfolg und 60 Prozent DHCP-Classifier sind nicht 60 Prozent aller Nutzer betroffen. DHCP erklärt 60 Prozent der verbleibenden 5 Prozent Fehler.
4. Wireless-SLE-Dashboard lesen
Navigation: Monitor → Service Levels → Wireless. Sichtbare Schaltflächen und Detailtiefe hängen von den vorhandenen Subscriptions ab.
| Bereich | Aussage | Prüfung |
|---|---|---|
| Users Timeline | Anzahl aktiver Benutzer im Zeitverlauf | Rückgang kann Feierabend, Ausfall oder Filtereffekt sein |
| System Changes | Konfigurations- und Radioänderungen | zeitliche Korrelation, nicht automatisch Kausalität |
| SLE Block links | Success Rate oder Messwert | Darstellungsmodus beachten |
| Timeline Mitte | Entwicklung im gewählten Zeitraum | Spitzen und Zeitfenster öffnen |
| Classifier rechts | Anteil der Fehler nach Ursachenklasse | Classifier anklicken und Sub-Classifier prüfen |
| Root Cause Analysis | Statistik, Verteilung, Scope und Affected Items | Client/AP/WLAN/Band/OS vergleichen |
Mit Success Rate wird die Zielerfüllung sichtbar; mit Values der zugrunde liegende durchschnittliche Wert. Hohe Durchschnittswerte können einzelne stark betroffene Benutzer verdecken, weshalb beide Ansichten benötigt werden.
5. Time to Connect
Time to Connect misst die Sekunden vom Association-Paket des Clients bis zu dem Moment, in dem der Client erfolgreich Daten übertragen kann. Der Schwellenwert ist konfigurierbar.
Association→Authorization→DHCP→Internet Services→Datenfähig
| Classifier | Bedeutung | Typische Beweise |
|---|---|---|
| Association | Association dauerte deutlich länger als der Durchschnitt | 802.11 Status, Retries, Security/PMF |
| Authorization | Authentifizierungs-/Autorisierungsphase war langsam | EAPOL, RADIUS-Latenz, Zertifikate |
| DHCP | DHCP-Timeout oder verzögerte Adressvergabe | DORA und Sub-Classifier Stuck/Nack/Unresponsive |
| Internet Services | Zugriff auf Internet-/Gateway-Dienste verzögert | ARP/ND, DNS, Gateway und Pfad |
Langsam ist nicht fehlgeschlagen: Ein Client kann sich erfolgreich verbinden, aber den gesetzten Zeitgrenzwert verfehlen. Das unterscheidet diese SLE von Successful Connects.
6. Successful Connects
Successful Connects bewertet Erfolg oder Fehlschlag initialer Verbindungen, Roams und laufender Konnektivität. Der Threshold ist nicht konfigurierbar; Juniper setzt als Erwartung 100 Prozent erfolgreiche Verbindungen.
| Classifier | Beispiel |
|---|---|
| Association | Client scheitert während der Association |
| Authorization | PSK/SAE/EAP/RADIUS schlägt fehl |
| DHCP | Renew Unresponsive, Nack, Incomplete oder Discover Unresponsive |
| ARP | Default-Gateway-ARP beim Join oder später schlägt fehl |
| DNS | DNS-Fehler während oder nach dem Verbindungsaufbau |
Interpretation
Ein einzelnes falsch konfiguriertes Testgerät kann bei kleinem Sample die Rate stark verschlechtern. Umgekehrt kann ein kleiner Prozentfehler bei zehntausenden Versuchen viele Benutzer betreffen. Deshalb werden Rate, absolute Versuche, Nutzeranzahl und Impact gemeinsam gelesen.
7. Coverage
Mist misst den RSSI aktiver Clients aus Sicht des AP – also den Client-Uplink. Diese Perspektive ist nicht identisch mit einem klassischen Survey, bei dem häufig der AP-Downlink am Messgerät betrachtet wird.
Coverage Success = User Minutes mit AP-gemessenem Client-RSSI innerhalb des konfigurierten Ziels
| Classifier | Bedeutung |
|---|---|
| Weak Signal | Client-Uplink-RSSI liegt unter dem gesetzten Ziel |
| Asymmetry Downlink | AP-Signal ist gegenüber der Clientseite schwächer |
| Asymmetry Uplink | Clientsignal ist gegenüber der AP-Seite schwächer |
Der Threshold wird in dBm gesetzt; negativere Werte sind schwächer. Eine pauschale Schwelle ohne Anwendung, Client-Sendeleistung und Datenratendesign kann Fehlbewertungen erzeugen.
Coverage ist nicht Kapazität: Ein Client kann starken RSSI und trotzdem schlechte Leistung durch Interferenz, Retries oder überlastete Airtime haben.
8. Roaming
Mist bewertet Roams zwischen APs und weist eine Qualitätsbewertung von 1 bis 5 zu. 1 bedeutet ausgezeichnet, 5 schlecht. Der Zielwert ist aktuell fest auf 2 gesetzt.
| Classifier | Sub-Classifier | Aktuelle Einordnung |
|---|---|---|
| Latency | Slow 11r Roams | 802.11r-Roam dauert länger als 400 ms |
| Latency | Slow Standard Roams | Standard-Roam dauert länger als 2 s |
| Latency | Slow OKC Roams | OKC-Roam dauert länger als 2 s |
| Stability | Failed to Fast Roam | Client und SSID sind 11r-fähig, Fast Roam bleibt aber instabil/langsam |
| Signal Quality | Interband Roam | schwaches Signal beim Bandwechsel |
| Signal Quality | Suboptimal Roam | Ziel-AP ist mehr als 6 dB schlechter oder unter Coverage-Ziel |
| Signal Quality | Sticky Client | Client bleibt, obwohl eine Option mit mehr als 6 dB Verbesserung existiert |
Die SLE bewertet das beobachtete Ergebnis; der Client trifft grundsätzlich die Roamingentscheidung. Ursache kann RF, Security, Treiber, Scanverhalten oder Anwendungstoleranz sein.
9. Throughput
Mist berechnet pro Client und Minute eine probabilistische Schätzung des erreichbaren Durchsatzes. Berücksichtigt werden unter anderem AP-Bandbreite, Last, Interferenz, Gerätetyp, Signalstärke und kabelgebundene Bandbreite.
Throughput SLE ≠ gemessener Speedtest ≠ tatsächlich übertragene Datenmenge
| Classifier | Bedeutung |
|---|---|
| Network Issues | kabelgebundener Pfad begrenzt die mögliche Datenrate |
| Coverage | schwaches Signal reduziert die mögliche Datenrate |
| Device Capability | Client kann etwa nur 20 MHz, einen Spatial Stream oder älteren Wi‑Fi-Standard |
| Capacity | AP-/Kanalbelastung oder Interferenz begrenzt Durchsatz |
Unter Capacity erscheinen beispielsweise High Bandwidth Utilization, Non-Wi‑Fi Interference, Excessive Client Load und Wi‑Fi Interference.
Realistischer Threshold: Ein 100-Mbit/s-Ziel bewertet einen 1×1-Legacy- oder IoT-Client möglicherweise dauerhaft schlecht, obwohl dessen Anwendung einwandfrei funktioniert.
10. Capacity
Capacity misst den Anteil der gesamten RF-Kanalkapazität, der für Clients verfügbar bleibt. Der Threshold gibt an, wie viel freie Kapazität mindestens vorhanden sein soll.
| Classifier | Interpretation | Erste Prüfung |
|---|---|---|
| Non-Wi‑Fi Interference | fremde nicht-802.11-Signale belegen Medium | Spektrum, Zeit und Ort |
| Client Usage | hohe Last der verbundenen Clients | Traffic, Anwendungen, Airtime |
| Wi‑Fi Interference | andere WLAN-Übertragungen konkurrieren | Co-/Adjacent-Channel, Kanalplan |
| Client Count | hohe Zahl assoziierter Clients | Verteilung, AP-Auswahl und aktive Nutzung |
Eine hohe Clientzahl ist nicht automatisch hohe Last, und hohe Kanalnutzung ist nicht automatisch schädlich. Entscheidend sind Airtime, Retry-Verhalten, Anwendung und tatsächlich betroffene User Minutes.
11. AP Health
AP Health verfolgt die Zeit, in der APs ohne Reboot oder Verlust der Cloud-Konnektivität betriebsbereit sind. Die Root-Cause-Logik kann gemeinsame Infrastrukturursachen erkennen.
| Classifier | Sub-Classifier/Beispiel |
|---|---|
| Low Power | unzureichende PoE-Leistung |
| AP Disconnected | Switch Down, Site Down, AP Unreachable oder AP Reboot |
| Ethernet | Speed/Duplex Mismatch oder CRC Errors |
| Network | Latency, Jitter oder Mist Edge Tunnel Down |
Wenn mehrere APs am selben Switch zeitgleich verschwinden, kann Mist dies als Switch Down statt als viele einzelne AP-Ausfälle darstellen. Diese Korrelation wird anschließend mit Switch-, Strom- und Uplinkdaten validiert.
Cloudverlust differenzieren: Ein AP kann zeitweise die Cloud verlieren, während bestehende lokale Clientdatenpfade weiterarbeiten. AP Health und Clientservice sind deshalb gemeinsam zu prüfen.
12. Schwellenwerte fachgerecht setzen
| SLE | Threshold | Ableitung |
|---|---|---|
| Time to Connect | konfigurierbare Sekunden | Nutzererwartung, EAP/Portal und DHCP-Realität |
| Successful Connects | nicht konfigurierbar; Ziel 100 % | jeder echte Fehlschlag ist relevant |
| Coverage | konfigurierbarer RSSI | Anwendung, Datenraten und schwächste unterstützte Clients |
| Roaming | fester Qualitätsscore 2 | aktuelle Produktlogik |
| Throughput | konfigurierbare Mbit/s | Anwendungsbedarf und Clientfähigkeit |
| Capacity | konfigurierbare freie RF-Kapazität | Lastprofil und Wachstumsreserve |
| AP Health | nicht frei als Ausfalltoleranz definieren | Verfügbarkeit wird grundsätzlich vollständig erwartet |
Schwellenprozess
- kritische Anwendungen und Clientklassen erfassen,
- technisch benötigte Mindestwerte herleiten,
- Ist-Baseline über repräsentative Wochen und Betriebszeiten prüfen,
- Threshold im Pilot setzen,
- False Positives und übersehene Nutzerprobleme bewerten,
- Wert, Begründung, Owner und Änderungsdatum dokumentieren.
Nicht auf Grün optimieren: Ein großzügigerer Threshold verbessert die Anzeige, nicht das Netzwerk. Änderungen werden fachlich begründet und in der Timeline berücksichtigt.
13. Classifier, Sub-Classifier und Root Cause
Classifier verteilen schlechte Samples auf technische Ursachenklassen. Sub-Classifier verfeinern diese Einordnung. Sie sind eine datenbasierte Hypothese, die durch Detaildaten bestätigt wird.
SLE schlecht→größter Classifier→Sub-Classifier→Distribution→Affected Items→Insights/Capture
| Ansicht | Frage |
|---|---|
| Statistics | Wie viele Versuche, User und Fehler stehen hinter dem Prozentwert? |
| Timeline | Wann begann und endete das Problem? |
| Distribution | Konzentriert es sich auf OS, Gerätetyp, WLAN, AP oder Band? |
| Affected Items | Wer scheitert häufig, und wer verursacht den größten Gesamtimpact? |
| Insights | Welche Client-/AP-Events und Messwerte liegen im Zeitfenster? |
| Packet Capture | Welche Protokollnachricht fehlt, scheitert oder kommt verspätet? |
14. Scope, Filter und Stichprobe
Eine identische Prozentzahl kann je Scope völlig verschiedene Bedeutung haben. Organisation, Site, AP, WLAN, Band, Clienttyp und Zeitfenster werden vor jeder Bewertung festgelegt.
| Scope | Nutzen | Risiko |
|---|---|---|
| Entire Organization | Sites priorisieren und Ausreißer erkennen | große Sites dominieren Aggregat |
| Site | lokalen Service bewerten | verschiedene Gebäude/WLANs vermischt |
| AP | räumlichen oder Infrastrukturfehler isolieren | Clientwanderung beeinflusst Stichprobe |
| WLAN | Security-/VLAN-/Dienstproblem trennen | WLANs können explizit von SLE ausgeschlossen sein |
| Client | individuelle Experience und Timeline | kein Beweis für Site-weites Problem |
| kurzes Zeitfenster | konkreten Incident untersuchen | kleine Samples und starke Schwankung |
| langes Zeitfenster | Trend und Wiederholung erkennen | kurze schwere Ausfälle werden geglättet |
Der Filter Hide Excluded WLANs blendet WLANs aus, bei denen die Wi‑Fi-SLE-Auswertung in der WLAN-Konfiguration ausgeschlossen wurde. Dieser Ausschluss muss dokumentiert sein, sonst entsteht ein verzerrter Servicebericht.
15. Baseline, Anomalien und System Changes
Mist vergleicht Beobachtungen mit normalem Verhalten und zeigt Konfigurations- beziehungsweise Radioänderungen in der Timeline. Eine zeitliche Überschneidung ist ein Hinweis, aber noch kein Kausalitätsbeweis.
| Beobachtung | Mögliche Deutung | Validierung |
|---|---|---|
| SLE fällt direkt nach WLAN-Change | Security/VLAN/Radio beeinflusst Clients | Change-Diff, betroffener Scope, Rollback/Pilot |
| SLE fällt ohne Change | externer Dienst, RF oder Clientupdate | Classifier, Provider-/Endpoint-Zeitlinie |
| Anomalie bei wenigen Nutzern | kleine Stichprobe weicht stark von Baseline ab | absolute Samples und Affected Items |
| Durchschnitt bleibt gut, Complaint steigt | kleine kritische Gruppe wird aggregiert verdeckt | WLAN-/Client-/OS-Distribution |
Baseline kann schlechte Normalität enthalten: „Wie immer“ ist nicht automatisch „fachlich ausreichend“. SLE-Threshold und Anomalieerkennung beantworten unterschiedliche Fragen.
16. Marvis Actions, Insights und Conversational Assistant
Marvis Actions
Hebt handlungsrelevante Probleme und betroffenen Scope hervor. Vor Umsetzung werden Beleg, Risiko und Change-Wirkung geprüft.
Insights
Liefert Ereigniszeitlinien und Client-/AP-Kontext für die SLE-Hypothese.
Conversational Assistant
Ermöglicht natürliche Abfragen zu Clients, Sites und Problemen; Ergebnis wird gegen Primärdaten validiert.
Clientbezogene Detailtiefe, Anomalieerkennung, Application Experience und weitere Funktionen hängen von Subscription und Integration ab. Das Fehlen einer Ansicht ist daher nicht automatisch ein Telemetriefehler.
Application Experience
Bei integrierten Zoom-/Teams-Daten oder modellierter Experience können gute und schlechte Anwendungs-User-Minutes zusätzlich nach Wireless, WAN und Clientbeitrag korreliert werden. Das ist eine andere Perspektive als die sieben grundlegenden Wireless-SLEs.
17. SLEs über API und Reporting
Mist stellt SLE-Metriken und Classifier über APIs bereit. Damit lassen sich Reports, Baselines und externe Dashboards reproduzierbar erzeugen.
| Reportingregel | Begründung |
|---|---|
| Scope und Zeitraum explizit speichern | Prozentwert ohne Nenner und Fenster ist nicht reproduzierbar |
| Thresholdversion erfassen | eine Änderung verschiebt Pass/Fail ohne Netzänderung |
| Samples total/degraded speichern | absolute Größen zeigen Stichprobenqualität |
| Classifier-Samples separat erfassen | Anteile beziehen sich nur auf Fehler |
| Zeitzone dokumentieren | Change-, Helpdesk- und Serverlogs müssen korrelieren |
| Subscription/Exclusions festhalten | sichtbarer Datenumfang kann sich unterscheiden |
Juniper weist darauf hin, dass SLE-Daten etwa alle zehn Minuten aktualisiert werden und bei dieser Granularität schwanken können. Für API-Monitoring werden in der offiziellen Anleitung einstündige Intervalle und eine Abfrage pro Stunde empfohlen.
Kein Blind-Polling: Häufigeres Abfragen erzeugt keine höhere Messauflösung und kann kurzfristige Schwankungen überbewerten.
18. Von der SLE zum Ursachenbeweis
Helpdeskmeldung, Anwendung, Client, Ort und exakte Zeit erfassen.
Site, WLAN, AP, Band, Clienttyp und ausreichendes Vergleichsfenster wählen.
langsamer Join, echter Fehlschlag, RF, Roam, Durchsatz, Kapazität oder AP Health?
Success Rate, Werte, Versuche, User Minutes und Nutzerzahl gemeinsam lesen.
größten Fehlerbeitrag, Sub-Classifier, Timeline und Distribution untersuchen.
häufig scheiternde Clients und größten Gesamtimpact unterscheiden.
Mist Events mit RADIUS, DHCP, DNS, Switch, Firewall und Anwendung korrelieren.
fehlende, verspätete oder abgewiesene Protokollnachricht identifizieren.
kleinste geeignete Maßnahme pilotieren und dieselbe SLE sowie den realen Dienst erneut testen.
| SLE | Nächster technischer Beweis |
|---|---|
| Time to Connect / Authorization | EAPOL und RADIUS-Latenz |
| Successful Connects / DHCP | DORA-Sequenz und DHCP-Serverlog |
| Coverage / Weak Signal | Client-Uplink-RSSI, SNR, Datenraten und Standort |
| Roaming / Latency | OTA-Roaming-Capture und Client Timeline |
| Throughput / Network | AP-Uplink, Switchqueue, WAN und kontrollierter Test |
| Capacity / Interference | Spektrum, Channel Utilization, Retry und Nachbarzellen |
| AP Health / Ethernet | PoE, LLDP, Linkrate und CRC-Zähler |
19. Betriebs- und Abnahmecheckliste
Konfiguration
- kritische Services und Clientklassen bekannt
- Thresholds fachlich begründet
- WLAN-Exclusions dokumentiert
- Subscription und sichtbare Funktionen geklärt
- Zeitzone und Reportingfenster festgelegt
- Owner und Reviewtermin definiert
Analyse
- Success Rate und absolute Samples geprüft
- User Minutes und Versuche unterschieden
- Classifier-Anteil korrekt interpretiert
- Scope/Distribution eingegrenzt
- Affected Items nach Impact priorisiert
- Ursache extern belegt
- Wirkung nach Change validiert
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „SLE und SLA sind dasselbe.“ | Falsch | Ein SLE ist eine Mess- und Erwartungsgröße; ein SLA ist eine Vereinbarung. |
| „70 % DHCP-Classifier heißt 70 % aller Nutzer.“ | Falsch | Der Classifier-Anteil bezieht sich auf die fehlerhaften Samples. |
| „Throughput SLE ist ein Speedtest.“ | Falsch | Sie schätzt probabilistisch den erreichbaren Clientdurchsatz. |
| „Coverage misst nur AP-Downlink.“ | Falsch | Mist verwendet den vom AP empfangenen Client-Uplink-RSSI. |
| „Schlechter SLE-Wert beweist die Ursache.“ | Falsch | Classifier liefert eine Hypothese; Logs und Pakete bestätigen sie. |
| „Ein grüner Durchschnitt bedeutet keine Nutzerprobleme.“ | Falsch | Kleine kritische Clientgruppen können im Aggregat verborgen sein. |
| „Ein lockerer Threshold verbessert den Dienst.“ | Falsch | Er verändert nur die Bewertung. |
Merksätze
- SLE ist eine Erwartungsmessung, nicht automatisch ein SLA.
- User Minutes normalisieren Benutzerzahl und Verbindungsdauer.
- Classifier-Anteile beziehen sich nur auf Fehler.
- Time to Connect misst langsam; Successful Connects misst gescheitert.
- Coverage betrachtet den Client-Uplink aus AP-Sicht.
- Throughput ist eine Schätzung, kein Speedtest.
- Capacity misst verfügbare RF-Kapazität, nicht nur Clientanzahl.
- Scope und Stichprobengröße entscheiden über die Aussage.
- Thresholdänderungen verändern Bewertung, nicht das Netz.
- Der SLE-Drill-down endet mit einem technischen Beweis.
Offizielle Grundlagen
- Wireless SLEs
- Overview of Juniper Mist Wi-Fi Assurance
- Using SLEs for Troubleshooting
- Troubleshoot Wireless Connectivity Issues
- Wireless Capacity SLE
- Use Mist SLEs and Insights with APIs
- AI-Native Operations Troubleshooting
- Application SLEs
- Marvis Large Experience Model
Stand der fachlichen Prüfung: August 2026. SLE-Namen, Classifier, Schwellenlogik, Subscriptionumfang und Benutzeroberfläche können sich ändern; für produktive Auswertung gilt die aktuelle Dokumentation der konkreten Mist-Region und Subscription.