QoS-Dokumentation: Klassen, Markierungen, Policies und SLAs

Eine saubere QoS-Dokumentation ist der oft unterschätzte Schlüssel, um Sprach- und Videodienste stabil zu betreiben, kritische Applikationen zuverlässig zu priorisieren und Provider-SLAs realistisch einzuhalten. In vielen Netzwerken existiert Quality of Service zwar „irgendwie“ in der Konfiguration – ein paar Klassen, ein paar Markierungen, vielleicht eine Policy am WAN-Edge – aber niemand kann im Alltag schnell beantworten: Welche Klassen gibt es? Wer darf markieren? Wo wird vertraut, wo wird neu markiert? Welche Queues existieren auf welcher Plattform? Welche Bandbreiten sind zugesichert, welche nur „best effort“? Genau diese Transparenz entscheidet darüber, ob QoS im Incident hilft oder nur zusätzliche Komplexität erzeugt. In Enterprise-Umgebungen mit SD-WAN, Hybrid-Cloud, Voice/Video, VDI, OT/IoT und mehreren Providern wird QoS schnell zu einem Ende-zu-Ende-Thema: vom Client über Access/Distribution/Core bis zum WAN/Internet und zurück. Dieser Artikel zeigt, wie Sie QoS professionell dokumentieren: Klassenmodell, Markierungsstrategie, Policies, Queueing/Shaping, Trust Boundaries, Messbarkeit und die Übersetzung in SLAs – als Living Documentation, die im Betrieb wirklich genutzt wird.

Warum QoS ohne Dokumentation fast immer scheitert

QoS ist nur dann wirksam, wenn es konsistent ist. Inkonsistenz entsteht meist nicht aus bösem Willen, sondern aus fehlender gemeinsamer Sprache: Das Netzwerkteam spricht von DSCP und Queues, Applikationsteams von „kritisch“ und „nicht kritisch“, Provider von Class-of-Service und SLA-Klassen. Ohne dokumentierte Zuordnung entstehen typische Probleme: Applikationen werden falsch markiert, Trust-Modelle werden unbewusst verletzt, Bandbreiten werden doppelt zugesichert, oder Policies greifen nur auf einem Teilpfad.

• Markierungschaos: DSCP-Werte werden von Clients willkürlich gesetzt oder unterwegs überschrieben.
• Unklare Trust Boundaries: Niemand weiß, an welchen Ports/QoS-Grenzen Markierungen „glaubwürdig“ sind.
• Provider-Mismatch: interne Klassen passen nicht zu Provider-CoS; Traffic landet im falschen SLA-Bucket.
• Fehlende End-to-End-Sicht: QoS wird am WAN konfiguriert, aber Access/Core ignorieren es.
• Keine Messbarkeit: Es gibt Policies, aber keine Metriken, ob sie greifen (Drops/Queueing/Delay).

QoS als End-to-End-Design: Begriffsklärung in der Dokumentation

Eine gute QoS-Dokumentation beginnt mit klaren Begriffen, damit alle Stakeholder dasselbe meinen. QoS umfasst mehrere Mechanismen, die zusammenspielen: Klassifizieren, Markieren, Policen anwenden, Queuing/Scheduling, Shaping/Policing und Monitoring. Gleichzeitig müssen Sie zwischen L2- und L3-Markierungen unterscheiden und den „Vertrauensbereich“ definieren.

• Klassifizierung: Traffic wird anhand von Kriterien einer Klasse zugeordnet (z. B. DSCP, Port, Applikation, NBAR).
• Markierung: Setzen oder Überschreiben von DSCP (Layer 3) und ggf. 802.1p/CoS (Layer 2).
• Queuing/Scheduling: Warteschlangen und Scheduling-Mechanismen bestimmen, welcher Traffic zuerst bedient wird.
• Shaping: Glätten des Traffic auf eine Rate, um Providergrenzen einzuhalten und Drops zu vermeiden.
• Policing: Hartes Begrenzen; Überschuss wird gedroppt oder remarkiert (im WAN oft riskant für Echtzeit).
• Trust Boundary: Stelle, ab der Markierungen akzeptiert werden (z. B. IP-Phone-Port ja, beliebiger Client-Port nein).

Für eine fachlich saubere Referenz zu DSCP und dem DiffServ-Modell ist ein Blick in die IETF-Dokumentation sinnvoll, z. B. über den RFC Editor als zentrale Quelle für Internet-Standards.

Das Klassenmodell: Wenige Klassen, klare Bedeutung

Der häufigste Fehler in QoS ist ein zu komplexes Klassenmodell. In der Praxis funktionieren 4–8 Klassen meist besser als 15, weil sie leichter zu implementieren, zu mappen und zu überwachen sind. Ihre Dokumentation sollte pro Klasse definieren: Zweck, typische Applikationen, Markierung (DSCP/CoS), Priorität, Queueing-Strategie, Bandbreitenzusicherung und Drop-Verhalten.

Ein praxistaugliches Beispiel für ein 6-Klassen-Modell

• Realtime (Voice): VoIP RTP, sehr niedrige Latenz/Jitter, strikte Priorität, DSCP EF.
• Interactive Video: Videokonferenzen, hohe Bandbreite, niedrige Latenz, DSCP AF4x/CS4.
• Business Critical: ERP/VDI/Transaktionen, verlässliche Bandbreite, DSCP AF3x.
• Signaling/Control: Call Signaling, Routing, Management (vorsichtig), DSCP CS3/CS2 je nach Konzept.
• Best Effort: Standardtraffic, DSCP 0.
• Scavenger/Bulk: Backups, Updates, große Transfers, DSCP CS1 (oder explizite Low-Priority-Policy).

Wichtig: Das Modell ist weniger entscheidend als seine Konsistenz. Wenn Sie EF als Voice definieren, muss das überall gelten – Access, Core, WAN, SD-WAN und Cloud-Anbindung.

Markierungsstrategie: Wer darf markieren, wer nicht?

Die Markierungsstrategie ist das Herzstück einer QoS-Dokumentation. Sie legt fest, ob Markierungen vom Endgerät übernommen („trust“) oder am Netzrand gesetzt („remark“) werden. Ohne diese Regeln ist QoS entweder wirkungslos (alles wird auf Best Effort zurückgesetzt) oder unsicher (Clients können sich unberechtigt in Prioritätsqueues „hochmarkieren“).

Trust Boundaries sauber dokumentieren

• Trusted: IP-Telefone (Voice), Videoendpunkte, definierte Mediensysteme, kontrollierte Applikations-Gateways.
• Conditional Trust: Serverports nur nach Policy (z. B. über NAC/802.1X, Profiling, oder feste Server-Tags).
• Untrusted: Standard-User-Ports, Gäste, IoT ohne Kontrolle (hier meist remark auf Best Effort).

Markierungsregeln pro Netzabschnitt

• Access: Klassifizieren (z. B. Phone vs. PC), Markieren/Remarken, CoS-zu-DSCP-Übersetzung bei Bedarf.
• Campus/Core: Markierungen meist beibehalten, Queueing konsistent, Congestion Points definieren.
• WAN/SD-WAN Edge: Shaping auf Provider-Rate, Mapping zu Provider-CoS, Schutz der Realtime-Klasse.
• Cloud Edge: Realistisch prüfen, ob DSCP end-to-end erhalten bleibt (Cloud/Internet kann remarken).

Dokumentieren Sie ausdrücklich, wo Markierungen verloren gehen können (z. B. Internetpfade, bestimmte Tunnel/Encapsulations) und wie Sie damit umgehen (z. B. Applikationsbasierte Klassifizierung am Edge statt Vertrauen auf DSCP).

Policies: Von „Klassen“ zu konkreten Regeln

Ein Klassenmodell ist erst dann operativ, wenn es in Policies übersetzt ist. Ihre QoS-Dokumentation sollte nicht jede CLI-Zeile kopieren, aber den Policy-Intent so festhalten, dass ein Engineer die Umsetzung nachvollziehen und prüfen kann: Welche Klassen existieren, welche Queueing-Mechanismen gelten, welche Bandbreiten sind reserviert, was passiert bei Congestion?

Policy-Intent, der dokumentiert werden sollte

• Classification: Welche Merkmale ordnen Traffic einer Klasse zu (DSCP, Applikation, Ports, ACLs)?
• Queueing: Welche Klassen haben Priority Queue (LLQ), welche Weighted Fair Queue?
• Bandwidth: Prozentuale oder absolute Reserven, Minimum vs. Maximum, Burst-Verhalten.
• Shaping/Policing: Wo wird geformt, wo begrenzt? Auf welcher Rate? Mit welchen Konsequenzen?
• Remarking: Wird bei Überschreitung remarkiert (z. B. AF3x → AF1x) oder gedroppt?

Queueing, Shaping und Congestion Points: Der „Ort“, an dem QoS wirkt

QoS ist nur dort relevant, wo Congestion entsteht. Deshalb sollte Ihre Dokumentation die Congestion Points benennen: WAN-Uplinks, Internet Breakouts, WLAN-Backhaul, Provider-Circuits, VPN-Tunnel, Cloud-Interconnects, manchmal auch Access-Uplinks in dichten Umgebungen. An diesen Stellen müssen Queueing und Shaping korrekt dimensioniert sein.

Was Sie pro Congestion Point dokumentieren sollten

• Interface/Link-Typ: WAN-Circuit, DIA, MPLS, SD-WAN Tunnel, Internet Edge, Cloud Connect.
• Effective Bandwidth: tatsächliche nutzbare Rate (Overhead, Provider-Policer, Tunnel-Encap berücksichtigen).
• Shaping Rate: bewusst unter Provider-Policer, um Drops zu vermeiden.
• Queue Layout: Anzahl Queues, LLQ-Anteil, WFQ-Verteilung.
• Drop-Strategie: WRED/RED (falls genutzt), Tail Drop, Remarking-Policy.

DSCP/CoS-Mapping: L2 und L3 konsistent verbinden

In Campus- und Datacenter-Umgebungen treffen Layer-2- und Layer-3-Markierungen aufeinander: 802.1p/CoS im VLAN-Tag und DSCP im IP-Header. Ihre Dokumentation sollte festlegen, ob und wo Mapping stattfindet (CoS->DSCP oder DSCP->CoS), und welches Mapping als Standard gilt. Ohne Mapping entstehen häufig „Schwarze Löcher“: Traffic ist markiert, aber auf dem nächsten Segment landet er in einer anderen Klasse.

• Standardmapping: definierte Tabelle, die CoS-Werte auf DSCP-Klassen abbildet (und umgekehrt).
• Trunk-Regeln: wie CoS über Trunks behandelt wird, und welche Geräte CoS vertrauen dürfen.
• Voice-Port-Logik: IP-Phone setzt CoS/DSCP, Switch vertraut dem Phone-Port, PC wird ggf. remarkiert.

QoS und SD-WAN: Applikations-Intent und Underlay/Overlay trennen

Mit SD-WAN verschiebt sich QoS häufig von „Interface-Policy“ zu „Intent“: Applikationen werden erkannt, in Klassen einsortiert und je nach Linkqualität über unterschiedliche Underlays geroutet. Dokumentation muss deshalb zwei Ebenen beschreiben: das Applikations-/Overlay-Policy-Modell und die physische Underlay-QoS (Provider-Circuits, Shaping, CoS-Mapping).

• App-to-Class Mapping: welche Applikationen gehören in welche QoS-Klasse?
• SLA-Policies: welche Klasse hat welche Grenzwerte für Loss/Jitter/Delay?
• Path Selection: wann wird ein Pfad gemieden, wann failover, wann active/active?
• Provider-Mapping: wie werden Klassen auf MPLS/Internet-CoS abgebildet?

QoS und SLAs: Dokumentation als Übersetzer zwischen Technik und Vertrag

Ein häufiger Konflikt: Das Netzwerkteam definiert 6 Klassen, der Provider liefert 3 CoS-Klassen. Oder das Business erwartet „ruckelfreies Video“, aber der Vertrag garantiert nur Best Effort im Internet. Ihre QoS-Dokumentation sollte deshalb eine „SLA-Mapping“-Sektion enthalten: Welche internen Klassen entsprechen welchen Provider-Klassen, und welche garantierten Parameter gelten (oder gelten ausdrücklich nicht)?

Was ein SLA-Mapping enthalten sollte

• Provider-CoS-Klassen: Namen, Kennzeichnung (z. B. DSCP-Werte, MPLS EXP/CoS), Bedingungen.
• Interne Klassen: Mapping-Tabelle (z. B. Realtime → Provider Voice).
• SLA-Parameter: Latenz, Jitter, Loss, Verfügbarkeit – und Scope (welche Strecken, welche Zeiten?).
• Messmethodik: wie wird SLA verifiziert (Provider-Reports, eigene Messpunkte, Synthetic Monitoring)?

Messbarkeit und Nachweis: QoS ist nur so gut wie sein Monitoring

QoS-Dokumentation muss prüfbar sein. Deshalb sollten Sie pro Klasse Metriken und Standardchecks definieren: Queue Drops, Queue Depth, Shaping Drops, Policy Match Counters, Latenz/Jitter/Loss pro Pfad. Für den Betrieb ist wichtig, dass diese Checks in Runbooks und Dashboards erreichbar sind.

Praktische Monitoring-Checks pro Klasse

• Policy Counters: Match-Counts pro Klasse (wird Traffic richtig klassifiziert?)
• Drops: Tail Drops/WRED-Drops pro Queue (wo entsteht Congestion?)
• Delay/Queue Depth: Indikator für Pufferung (Jitter-Risiko für Realtime)
• Path KPIs: RTT, Loss, Jitter pro Underlay/Link (besonders für Voice/Video)
• End-to-End Tests: Synthetic VoIP/Video Tests, falls verfügbar

Dokumentationsartefakte: Was Sie konkret erstellen sollten

Damit QoS-Dokumentation betriebstauglich bleibt, hilft eine klare Artefaktliste. Diese Artefakte können als Wiki-Seiten, Markdown in Git (Documentation-as-Code) oder als Kombination aus SoT + Portal geführt werden.

• QoS Klassenkatalog: Klasse, Zweck, DSCP/CoS, Priorität, Mindest-/Max-Bandbreite, typische Apps.
• Markierungs- und Trust-Policy: Trust Boundaries, Remarking-Regeln, Mapping CoS<>DSCP.
• Policy-Matrix: pro Domäne (Access/Core/WAN/SD-WAN/Cloud) die angewendeten Policies als Intent.
• Congestion-Point-Landkarte: wo QoS wirken muss, inkl. Shaping-Raten und Queue-Layouts.
• SLA-Mapping: interne Klassen → Provider-CoS → SLA-Parameter, inkl. Messmethodik.
• Runbooks: Troubleshooting-Flows für „Voice jitter“, „Video drops“, „Bulk verdrängt Business“.

Governance: QoS als Living Documentation statt einmaliges Projekt

QoS veraltet, wenn Applikationen sich ändern, neue Standorte hinzukommen oder Provider-CoS angepasst wird. Deshalb braucht QoS-Dokumentation Governance: Owner, Review-Zyklen und Done-Kriterien in Changes. Besonders wichtig: Neue Applikationen müssen in das Klassenmodell eingeordnet werden, bevor sie produktiv breit ausgerollt werden.

Definition of Done für QoS-relevante Änderungen

• Applikation/Service ist einer QoS-Klasse zugeordnet (inkl. DSCP/CoS und Begründung)
• Markierungsstrategie und Trust Boundary sind geprüft (wer markiert, wo wird vertraut?)
• WAN/SD-WAN-Mapping und Shaping-Raten sind validiert
• Monitoring/Dashboards sind aktualisiert (Counters, Drops, Path KPIs)
• SLA-Mapping ist geprüft, wenn Provider betroffen ist

Wenn Sie Change- und Knowledge-Management strukturiert einbetten möchten, kann ein ITIL-orientierter Ansatz helfen; eine Übersicht dazu bietet ITIL Best Practices.

Typische QoS-Fehler und wie Dokumentation sie verhindert

• Zu viele Klassen: niemand kann sie konsistent mappen; Lösung: 4–8 stabile Klassen.
• Unklare Markierungen: DSCP-Werte ohne Regeln; Lösung: Markierungsstrategie + Trust Boundaries.
• Provider-Policer schlägt Shaper: Drops trotz QoS; Lösung: Shaping unter Provider-Rate dokumentieren und umsetzen.
• Voice in LLQ ohne Grenzen: LLQ kann andere Klassen verhungern lassen; Lösung: LLQ-Anteil und Policer/Guardrails dokumentieren.
• Kein Monitoring: QoS wirkt „gefühlt“; Lösung: Counters, Drops, KPIs und Runbooks verpflichtend.
• Cloud/Internet ignoriert DSCP: Markierungen gehen verloren; Lösung: Pfadrealität dokumentieren und ggf. Edge-Klassifizierung nutzen.

Checkliste: QoS-Dokumentation für Klassen, Markierungen, Policies und SLAs

• Ein Klassenkatalog existiert (Zweck, Apps, DSCP/CoS, Priorität, Bandbreitenlogik, Drop-Verhalten)
• Markierungsstrategie ist definiert (wer markiert, wo wird vertraut, wo wird remarkiert)
• Trust Boundaries sind dokumentiert (z. B. Phone-Port trusted, User-Port untrusted)
• Congestion Points sind benannt (WAN, Internet Edge, SD-WAN Tunnel, Cloud-Interconnect) inkl. Shaping-Raten
• CoS<>DSCP-Mapping ist standardisiert und konsistent über die Domänen hinweg
• Policy-Intent ist dokumentiert (Klassifizierung, Queueing, Shaping/Policing, Remarking)
• SLA-Mapping ist vorhanden (interne Klassen → Provider-CoS → SLA-Parameter + Messmethodik)
• Monitoring ist definiert (Counters, Drops, Queue Depth, Path KPIs) und in Dashboards/Runbooks verlinkt
• Governance existiert (Owner, Review-Zyklen, Definition of Done für QoS-relevante Changes)
• Primärquellen sind verlinkt (z. B. IETF/RFCs über den RFC Editor für DSCP/DiffServ)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.