Eine QoS Review Checkliste ist das wirksamste Instrument, um Quality of Service von „funktioniert auf meinem Lab“ zu „robust im Betrieb“ zu bringen. In der Praxis scheitern QoS-Projekte selten an fehlendem Willen, sondern an fehlenden Experten-Gates: Markierungen driften, Policies werden am falschen Interface gebunden, Shaping fehlt, eine Priority-Queue ist unlimitiert, oder ein VPN/SD-WAN-Tunnel kopiert DSCP nicht auf den Outer Header. Solche Fehler sind tückisch, weil sie oft erst in Peak-Zeiten sichtbar werden – dann aber mit hohem Impact auf Voice, Video, WebRTC, Contact Center oder Telco-Services. Eine gute QoS Review Checkliste zwingt deshalb zu einem systematischen Durchgang durch Design und Konfiguration: Engpassmodell (Congestion Domains), Klassenmodell und Marking-Matrix, Trust Boundary, Queueing/Scheduling/Shaping, Interworking (DSCP/CoS/MPLS TC/WMM), Overlay/Security-Effekte, Observability sowie Tests, Rollout und Rollback. Der Nutzen ist doppelt: Erstens sinkt das Betriebsrisiko, weil typische „Never Events“ vorab abgefangen werden. Zweitens wird QoS auditierbar, weil Sie Evidence und Standards direkt in den Review-Prozess integrieren. Dieser Artikel liefert eine praxistaugliche QoS Review Checkliste mit Experten-Gates, die sich für Enterprise- und Telco-nahe Netze eignet und die Sie als Review-Standard in Architektur- und Change-Prozessen verankern können.
Wie man die Checkliste benutzt: Gates statt „alles auf einmal“
Eine QoS Review funktioniert am besten als Gate-System. Jedes Gate beantwortet eine klare Frage und hat klare Pass/Fail-Kriterien. Fällt ein Gate durch, wird nicht „weiterdiskutiert“, sondern es wird korrigiert oder bewusst als Ausnahme dokumentiert. So vermeiden Sie, dass Reviews zu Meinungsrunden werden. In der Praxis bewährt sich folgende Reihenfolge: erst Design- und Engpasslogik, dann Marking/Trust, dann Queueing/Shaping, dann Interworking/Overlays, dann Observability und schließlich Testing/Rollout.
- Gate-Logik: jedes Gate hat Ziel, Prüfpunkte und typische Failure Patterns.
- Evidence-first: Entscheidung basiert auf Metriken/Exports, nicht auf Annahmen.
- Ausnahmen: jede Abweichung braucht Risikoanalyse und Remediation-Plan.
Gate 1: Congestion Domains – Wo entsteht Queueing wirklich?
QoS ist nur dort wirksam, wo Congestion entstehen kann. Deshalb ist das erste Experten-Gate immer das Engpassmodell. Wenn nicht klar ist, wo Bandbreite knapp wird, landen Policies oft am falschen Ort. Prüfen Sie, ob die relevanten Engpässe identifiziert und als Congestion Domains beschrieben sind: WAN/Internet-Uplinks, Aggregationslinks, WLAN-Airtime-Zonen, VPN/SD-WAN-Underlays, Security-Pipelines, Metro-/PoP-Uplinks, Interconnects. Ein wichtiger Review-Punkt ist der Richtungsbezug: Congestion ist häufig egress-getrieben, insbesondere am Uplink.
- Pfadidentifikation: welche Pfade tragen Voice/Video/RTC und wo sind die Engpässe?
- Egress-Fokus: sind QoS-Policies an den tatsächlichen Egress-Interfaces geplant?
- Ownership: endet Congestion in einer Black Box (Modem/Provider/Cloud)? Wenn ja: Shaping-Plan?
- Schutzfälle: ändern Failover/Reroute Engpassorte (Metro-Ring, SD-WAN)?
Gate 2: Klassenmodell – Wenige robuste Klassen, klare Semantik
Ein häufiges Problem ist ein zu großes Klassenmodell oder ein Modell ohne klare Semantik. Für die meisten Netze sind 4–6 Klassen ausreichend: VOICE/AUDIO, MEDIA/VIDEO, SIGNAL/CONTROL, BESTEFFORT, BULK (optional CRITICAL). Entscheidend ist, dass jede Klasse eine klare Definition hat: welche Anwendungen/Flows gehören hinein, welche Markierungen gelten, welche Priorität und welche Limits sind vorgesehen. Ein Review sollte explizit fragen: Was passiert mit „neuen“ oder unbekannten Workloads? Dafür ist die Default-Klasse wichtig.
- Semantik: ist klar, was Voice vs. Media vs. Signal bedeutet?
- Abbildbarkeit: passt das Modell auf alle Plattformen (WLAN/WMM, Router, Core)?
- Limits: sind Klassen so dimensioniert, dass sie nicht verhungern oder alles verdrängen?
- Default-Handling: wohin geht unbekannter Traffic, und wie wird Drift erkannt?
Gate 3: Marking-Matrix und Interworking – DSCP, CoS, WMM, MPLS TC
QoS scheitert häufig nicht am Scheduler, sondern an inkonsistenten Markierungen. Dieses Gate prüft, ob eine DSCP/CoS/WMM/MPLS-TC-Matrix als Source of Truth existiert und ob alle Domänen sie konsistent interpretieren. Besonders wichtig sind Übergänge: Ethernet-Access (802.1p), WLAN (WMM), IP-Transport (DSCP), MPLS/SR (TC). Ohne konsistentes Interworking gibt es „Klassen-Sprünge“, die im Incident kaum erklärbar sind.
- Source of Truth: existiert eine zentrale Mapping-Tabelle mit Versionierung?
- Domain-Grenzen: wird DSCP↔CoS↔WMM↔TC sauber gemappt?
- Multi-Vendor: sind Vendor-Defaults überschrieben oder zumindest dokumentiert?
- Drift-Checks: gibt es automatische/regelmäßige Prüfungen der Mapping-Konsistenz?
Gate 4: Trust Boundary – Wer darf markieren, wo wird normalisiert?
Dieses Gate entscheidet über Stabilität und Missbrauchsschutz. Ohne Trust Boundary markiert irgendwann „alles“ Premium, und Ihre Voice-/Low-Latency-Queues werden wertlos. Zu strenge Normalisierung wiederum drückt echte Echtzeit in Best Effort. Der Review muss daher konkret sein: Welche Endgeräte sind trusted (IP-Phones, Room Systems, managed Clients)? Welche Segmente sind untrusted (BYOD, Gäste)? Wo wird Marking neu gesetzt (SBC, Edge, UC-Gateway)? Und wie wird das operational überprüft (Default/Unmatched Drift, Re-Marking Counter)?
- Trusted Set: definierte Geräte/Ports/VLANs/SSIDs, die DSCP setzen dürfen.
- Untrusted Set: Normalisierung/Whitelist, um Marking Abuse zu verhindern.
- Re-Marking Policy: deterministisch statt „zufälliges“ DSCP-Löschen in Firewalls/Overlays.
- Evidence: Monitoring von Default/Unmatched und Re-Marking-Events.
Gate 5: Scheduling – Priority nur dort, wo sie wirklich hingehört
Die wichtigste Frage lautet: Welche Klasse bekommt strict priority, und ist sie begrenzt? In den meisten Designs ist Voice/Audio die einzige Kandidatin für strict priority. Video/Media sollte in der Regel nicht strict priorisiert werden, sondern als hohe Priorität mit Limits laufen. Dieses Gate prüft außerdem Fairness: Kann Best Effort noch funktionieren? Verhungert Signal/Control nicht? Ist Bulk bewusst opferbar? Ohne diese Balance ist QoS zwar „priorisiert“, aber nicht robust.
- LLQ/Strict Priority: nur für Voice, mit klarer Obergrenze (Ceiling).
- Media-Limits: Media hoch priorisiert, aber begrenzt, um Voice nicht zu verdrängen.
- Control-Stabilität: Signal/Control bekommt Schutz, damit Sessions stabil bleiben.
- Bulk-Containment: Bulk wird gedrosselt und darf Delay/Drops tragen.
Gate 6: Shaping Points – Congestion in kontrollierte Queues holen
Dieses Gate ist oft der Unterschied zwischen „QoS theoretisch“ und „QoS praktisch“. Prüfen Sie, ob an den echten Engpässen Realrate-Shaping geplant ist und ob Overhead (VLAN, PPPoE, IPSec, Encapsulation) berücksichtigt wird. Besonders relevant sind Uplinks (Upstream!), Interconnect-Übergaben mit Provider-Policern und SD-WAN/Internet-Breakouts. Ohne Shaping passieren Queueing und Drops oft im Provider-Buffer oder in CPEs, wo Sie keine Klassenkontrolle haben.
- Realrate: Shaper knapp unter effektiver Nutzrate, nicht blind auf Vertragsrate.
- Overhead: IPSec/PPPoE/VLAN reduzieren Nutzrate; Shaper muss darunter liegen.
- Pre-Policer Shaping: vor rate-limited Hand-offs shapen, um Policer Drops zu vermeiden.
- HQoS: Parent Shaper + Child Klassen für planbare Verteilung.
Gate 7: Overlay und VPN QoS – DSCP Preservation inner/outer
Overlays sind ein klassischer QoS-Killer, wenn DSCP nicht korrekt behandelt wird. Dieses Gate prüft, ob DSCP im inneren Paket erhalten bleibt und ob der Outer Header so markiert wird, dass das Underlay die richtigen Queues nutzt. Ebenso wichtig ist die Stelle der QoS-Policy: Oft ist der Engpass am Underlay-Egress, nicht am Tunnelinterface. Für SD-WAN muss zudem sichergestellt sein, dass Pfadwechsel die QoS-Semantik nicht brechen.
- Inner→Outer: Copy oder Mapping von DSCP auf Outer DSCP ist definiert und getestet.
- Underlay QoS: Queueing/Shaping am Underlay-Egress vorhanden.
- SD-WAN Steering: Echtzeit darf nicht auf Pfade ohne QoS-Reserven wechseln.
- Guardrails: Policer Drops in Echtzeitklassen sind ein „Never Event“.
Gate 8: Security-Pfad – DPI/Decryption als Latenz- und Jitter-Faktor
Firewalls, IPS und Decryption können zu Processing-Engpässen werden und Jitter erzeugen, selbst wenn Links nicht ausgelastet sind. Dieses Gate prüft, ob Echtzeitpfade durch Security-Funktionen gezielt optimiert sind: selektive Inspection, ausreichender Headroom, DSCP Preservation oder kontrolliertes Re-Marking. Wichtig ist außerdem, dass Monitoring beidseitig der Security-Komponente möglich ist, um Security-bedingte Latenz von klassischer Congestion zu unterscheiden.
- Processing Headroom: CPU/Crypto/Session-Kapazität ist für Peaks dimensioniert.
- Selective Inspection: Echtzeit weniger tief inspizieren als Datenklassen, wo möglich.
- DSCP Handling: Markierungen werden preservt oder deterministisch neu gesetzt.
- Evidence: Vor/Nach-Messung von QoE und Queue-Metriken an Security-Interfaces.
Gate 9: WLAN und Access – WMM, Airtime und Roaming
Wenn Voice/Video über WLAN läuft, ist Airtime die Engpasswährung. Dieses Gate prüft, ob DSCP korrekt auf WMM gemappt wird und ob WLAN-spezifische Metriken überwacht werden: Airtime Utilization, Retry Rates, PHY-Raten und Roaming-Ereignisse. Ohne diese Sicht kann ein Team „QoS ist korrekt“ sagen, während die Funkrealität die Qualität zerstört.
- WMM Mapping: DSCP/CoS→WMM konsistent, Voice in WMM Voice, Video in WMM Video.
- Airtime KPIs: Airtime, Retries, PHY-Rate, Kanalbelegung als QoE-Treiber.
- SSID/Rollen: Trennung von Guest/BYOD vs. Corporate Voice/RTC sinnvoll umgesetzt.
Gate 10: Observability – QoS muss beweisbar sein
Ein Experten-Review ist unvollständig, wenn die Policy zwar „schön“ ist, aber niemand sie im Betrieb nachweisen kann. Dieses Gate fordert High-Signal KPIs: Queue Delay/Depth (Perzentile), Per-Class Drops, Drop Reasons, Shaper-Headroom und Classifier-Hits/Default/Unmatched. Für Echtzeit gehören QoE-KPIs dazu (MOS, Bad-Call-Rate, RTP/WebRTC Jitter/Loss). Entscheidend ist die Auflösung: Peaks sind wichtiger als Mittelwerte.
- Queue Delay 95p/99p: Voice/Media an den Congestion Domains.
- Per-Class Drops: Voice Drops sind Incident; BE/Bulk Drops sind Kontext.
- Drop Reasons: Tail Drop vs. Policer vs. Buffer Exhaustion als Root-Cause-Beschleuniger.
- Classifier Drift: Default/Unmatched-Anteil und Re-Marking-Events.
- QoE KPIs: MOS/Bad-Call-Rate oder RTP/WebRTC Stats zur Korrelation.
Gate 11: Tests – Mechanik, Congestion-Proof und Failure-Mode
QoS ohne Tests bleibt eine Annahme. Ein Review sollte mindestens drei Testarten verlangen: Mechaniktests (Policy greift, Mapping stimmt), Congestion-Proof (Bulk saturiert Engpass, Echtzeit bleibt stabil) und Failure-Mode-Tests (Reroute/FRR/SD-WAN Pfadwechsel). Pass/Fail-Kriterien sollten perzentilbasiert sein und „Never Events“ enthalten, etwa Policer Drops in Voice.
- Mechanik: Classifier-Hits, DSCP Preservation, DSCP→Queue Mapping, Attachment am richtigen Egress.
- Congestion-Proof: Voice bleibt stabil, Media kontrolliert, BE/Bulk trägt Einbußen.
- Failure-Mode: Pfadwechsel darf QoS-Semantik nicht brechen, Echtzeit-KPIs dürfen nicht regressieren.
Gate 12: Rollout- und Rollback-Plan – Canary als Standard
Selbst perfekte Designs können im Feld scheitern, weil reale Last, Providerpuffer oder Gerätequirks anders sind. Daher ist ein Canary-Rollout mit Guardrails und Rollback Pflicht. Dieses Gate prüft: Gibt es Pilot-/Canary-Standorte, gibt es eine Control Group, sind Stop-Regeln definiert (Voice Drops, Policer Drops, Delay 99p), und ist Rollback atomar (Template-Version wechseln statt live editieren)?
- Canary Sites: low-risk, repräsentativ, high-complexity (WLAN/RTC/hoher Upload).
- Stop-Regeln: Voice Drops, Policer Drops, Voice Delay 99p, Default/Unmatched Drift.
- Rollback: Versionierung, atomarer Switch, KPI-Rückkehr zur Baseline als Nachweis.
Gate 13: Compliance und Dokumentation – QoS auditfähig machen
QoS-Reviews sind die beste Stelle, um Auditfähigkeit einzubauen: Standards, Konfigurationsauszüge, Counter Reports und Telemetry-Evidence. Dieses Gate fordert, dass Änderungen dokumentiert und rezertifizierbar sind: Welche Version, welche Devices, welche Mappings, welche Tests, welche Ergebnisse. So wird QoS nicht nur „gebaut“, sondern kontinuierlich kontrolliert.
- Standards: Klassenmodell, Mapping-Matrix, Trust Boundary als versionierte Dokumente.
- Config Exports: relevante QoS-Blöcke und Attachments als Evidence.
- Counter Reports: Classifier-Hits und Per-Class Drops als Wirksamkeitsnachweis.
- Rezertifizierung: periodisch oder nach Major Changes, mit standardisiertem Evidence Pack.
„Never Events“: Sofortige Fail-Kriterien für Experten-Reviews
- Unlimitierte Priority-Queue: strict priority ohne Ceiling für Voice/Audio.
- Video in Voice-LLQ: Media/Video in strict priority, ohne Limits.
- Kein Shaping am Engpass: Congestion passiert im Provider-/Modem-Puffer statt in kontrollierten Queues.
- Policer auf Echtzeit: Policer Drops in Voice/Media oder harte Rate-Limits ohne Burst-Toleranz.
- DSCP Drift: unterschiedliche DSCP→Queue Mappings über Domänen/Vendoren ohne dokumentierte Ausnahme.
- Kein DSCP Copy im VPN: Outer DSCP bleibt 0, Underlay sieht Best Effort.
- Keine Observability: keine Queue Delay/Depth, keine Per-Class Drops, keine Drop Reasons.
Pragmatische QoS Review Checkliste als kompakte Gate-Übersicht
- Gate 1: Congestion Domains identifiziert, Egress-Engpässe klar, Schutzfälle berücksichtigt.
- Gate 2: kleines Klassenmodell mit klarer Semantik und Dimensionierung.
- Gate 3: DSCP/CoS/WMM/MPLS-TC Mapping als Source of Truth, Interworking geprüft.
- Gate 4: Trust Boundary definiert, Missmarking-Schutz vorhanden, Drift-Monitoring geplant.
- Gate 5: Scheduling korrekt: Voice strict (begrenzt), Video limitiert, Bulk gedrosselt.
- Gate 6: Shaping Points auf Realrate, Overhead berücksichtigt, pre-police Shaping wo nötig.
- Gate 7: VPN/SD-WAN DSCP Preservation inner/outer, Underlay QoS aktiv.
- Gate 8: Security-Pfad Latenz/Jitter berücksichtigt, DSCP Handling klar.
- Gate 9: WLAN/WMM und Airtime-KPIs integriert, SSID/Rollen sauber.
- Gate 10: Observability: Queue Delay/Depth, Drops, Drop Reasons, QoE-KPIs, Perzentile.
- Gate 11: Tests: Mechanik, Congestion-Proof, Failure-Mode, Pass/Fail Kriterien.
- Gate 12: Rollout: Canary, Guardrails, Control Group, atomarer Rollback.
- Gate 13: Compliance: Dokumentation, Evidence Packs, Rezertifizierung.
