QoS Flows dokumentieren: Marking, Queues und Policer über Domänen

QoS Flows dokumentieren ist in Enterprise-Netzen der Unterschied zwischen „QoS ist konfiguriert“ und „QoS wirkt zuverlässig über Domänen“. Viele Organisationen haben irgendwo eine QoS-Policy auf dem WAN-Edge, vielleicht noch ein Voice-VLAN im Campus – und trotzdem klagen Anwendungen über Jitter, Packet Loss oder „spiky“ Latenzen. Der Grund ist selten ein einzelnes Gerät, sondern fehlende End-to-End-Transparenz: Marking wird an einer Stelle gesetzt, an der nächsten überschrieben; Queues sind je Plattform unterschiedlich gemappt; Policer schneiden Traffic ab, bevor er die priorisierte Queue erreicht; und zwischen Campus, Datacenter, Cloud und SD-WAN existieren unterschiedliche QoS-Domänen, die nicht sauber verbunden sind. Professionelle QoS-Dokumentation macht diesen Pfad sichtbar: von der Markierung (DSCP/CoS) über Klassifizierung und Queueing bis zu Shaping und Policing – und zwar pro Domäne und an den Übergängen. Dieser Artikel zeigt, wie Sie QoS Flows so dokumentieren, dass Betrieb, Architektur und Troubleshooting schneller werden: mit „One Flow per Use Case“-Diagrammen, einer Marking- und Queue-Matrix, klaren Trust Boundaries („wo vertrauen wir Markings?“) sowie einer Governance, die Drift verhindert und SLAs nachvollziehbar macht.

Warum QoS ohne Flow-Dokumentation häufig ins Leere läuft

QoS ist ein End-to-End-Thema, aber Konfigurationen werden oft lokal optimiert. Das führt zu klassischen Problemen:

• Marking-Drift: DSCP/CoS wird gesetzt, dann an einer Domänengrenze neu markiert oder auf Best Effort zurückgesetzt.
• Queue-Mismatch: „EF“ bedeutet in Domäne A eine strikte Priority Queue, in Domäne B landet es in einer normalen Queue.
• Policer vor der falschen Stelle: Traffic wird gepoliced, bevor er priorisiert wird – Voice/Realtime bricht trotzdem.
• Keine klaren Trust Boundaries: Endgeräte markieren beliebig, oder Network vertraut Markings an Stellen, wo es nicht sollte.
• Unklare SLA-Übersetzung: Verträge nennen Latenz/Jitter/Loss, aber niemand weiß, welche Queue-/Shaping-Parameter das absichern sollen.

QoS-Flows zu dokumentieren heißt, diese Brüche sichtbar zu machen und die QoS-Logik als „Pipeline“ zu beschreiben: Marking → Classification → Queueing → Scheduling → Shaping/Policing, inklusive Domänenübergängen.

Begriffe und Bausteine: Marking, Queues, Policer, Shaper

Damit Teams konsistent arbeiten, sollte die Dokumentation die zentralen Bausteine präzise definieren:

• Marking: Kennzeichnung von Paketen, typischerweise als DSCP im IP-Header (Layer 3) und/oder CoS/802.1p im VLAN-Tag (Layer 2).
• Classification: Zuordnung von Traffic zu Klassen (z. B. Voice, Video, Critical Apps, Best Effort) anhand Markings oder anderer Merkmale.
• Queueing: Ablage klassifizierter Pakete in Warteschlangen (Queues), die unterschiedlich bedient werden.
• Scheduling: Algorithmus, der bestimmt, welche Queue wann sendet (Priority, Weighted Fair Queuing, etc.).
• Policer: begrenzt Rate durch Drop/Mark-Down (hart), oft am Ingress oder in Provider-Edges.
• Shaper: glättet Traffic auf eine Zielrate (soft), häufig am Egress, um Congestion kontrolliert zu erzeugen.

Für DSCP/PHB-Konzepte sind RFCs seriöse Referenzen: RFC 2474 (DiffServ) und RFC 2598 (EF PHB). Für Assured Forwarding (AF) ist RFC 2597 relevant.

QoS-Domänen verstehen: Campus, WAN, Datacenter, Cloud, SD-WAN

Ein zentraler Dokumentationsfehler ist, QoS als einheitliches System zu betrachten. In Wirklichkeit existieren QoS-Domänen, in denen Marking und Queueing konsistent sind – und an den Grenzen wird übersetzt oder neu bewertet. Typische Domänen:

• Access/Campus: CoS auf Trunks, DSCP auf L3, Trust meist nur an definierten Ports (IP Phones, APs).
• WAN/Provider: Provider-Klassen, CIR/EIR, Policer/Remarking, SLA-Grenzen.
• SD-WAN Overlay: Traffic-Klassen und SLA-basierte Pfadwahl, ggf. eigenes Marking oder Copy/Preserve.
• Datacenter Fabric: Leaf/Spine Queueing, Microbursts, ggf. DCB/ECN (je nach Umgebung).
• Cloud: eingeschränkte QoS-Kontrolle, oft nur Marking/Traffic Engineering indirekt; entscheidend sind Egress-Policies und Gateways.

Ihre QoS-Dokumentation sollte pro Domäne definieren: Welche Klassen gibt es? Welche Markings gelten? Welche Queues existieren? Und wo findet Übersetzung statt?

Das Diagramm-Portfolio: „One Flow per Use Case“ statt QoS-Spaghetti

QoS wird erst verständlich, wenn Sie konkrete Flows dokumentieren. Statt „QoS allgemein“ zu erklären, definieren Sie wenige, relevante Use Cases und zeichnen für jeden einen Flow über Domänen. Ein bewährtes Minimum:

• Voice (Realtime): IP Phone/WLAN Client → Campus → WAN/SD-WAN → DC/UC-Cluster oder SaaS.
• Video/Conferencing: Client → PoP/SASE → Internet/SaaS → Rückweg, inkl. Jitter-Sensitivität.
• Business Critical App: ERP/OT → WAN → DC/Cloud, mit garantierter Mindestbandbreite.
• Bulk/Backup: Replikation/Backups → WAN/DCI, bewusst depriorisiert oder zeitgesteuert.
• Management/Control: Monitoring/Telemetry/AAA/DNS – oft klein, aber kritisch, nicht in Best Effort „ertränken“.

Jeder Flow bekommt ein Diagramm, das Marking, Queueing und Policer als „Gates“ entlang des Pfades zeigt. Wenn Sie Diagramme versionierbar halten möchten, sind Mermaid oder PlantUML als Diagram-as-Code-Optionen geeignet.

Marking dokumentieren: DSCP/CoS als „Contract“

Marking ist die Sprache, mit der Domänen miteinander sprechen. Wenn Marking unklar ist, können Queues nicht konsistent wirken. Eine professionelle Doku enthält deshalb ein Marking-Register (Marking Catalog), ähnlich einem API-Contract.

Inhalte eines Marking Catalog

• Traffic Class: Voice, Video, Critical Data, Best Effort, Scavenger, Management
• DSCP: z. B. EF, AF41, AF31, CSx (konkret festlegen)
• CoS/802.1p: Mapping für L2-Trunks (z. B. CoS 5 für Voice)
• Trust Boundary: wo darf dieses Marking gesetzt/übernommen werden (IP Phone Ports, AP Uplinks, Router Edge)?
• Remarking Rules: wo wird Marking überschrieben (z. B. untrusted → Best Effort)
• Owner & Review: Verantwortliche Rolle, Rezertifizierungstermin

Das verhindert, dass jedes Team seine eigene DSCP-Sprache erfindet. RFC-Referenzen für die DiffServ-Architektur: RFC 2475 (DiffServ Architektur) und RFC 2474 (DS Field).

Queues dokumentieren: Queue-Mapping pro Plattform und Domäne

Queues sind nicht universell: Vendoren und Plattformen implementieren Scheduling unterschiedlich. Deshalb muss Dokumentation zwei Ebenen trennen:

• Logische Queues: das domänenweite Modell (z. B. 6 Klassen: Realtime, Video, Critical, Standard, Bulk, Scavenger).
• Physische Queues: konkrete Queue-IDs und Scheduler je Plattform (Switch, Router, SD-WAN Edge, Firewall, WLAN Controller).

Die zentrale Artefaktform ist eine Queue-Matrix: „Traffic Class/DSCP → Queue/PHB → Scheduler-Parameter“. Diese Matrix existiert pro Domäne, und an Domänengrenzen gibt es eine „Translation Matrix“.

Typische Felder einer Queue-Matrix

• Class (z. B. Voice)
• DSCP/CoS (z. B. EF/CoS5)
• Queue Type (Priority/Weighted)
• Min/Max Bandwidth (Guarantee/Cap)
• Drop Policy (Tail Drop, WRED – falls genutzt)
• Remarking on Congestion (falls genutzt)

Policer und Shaper dokumentieren: Wo wird geschnitten, wo wird geglättet?

QoS scheitert häufig an Policing: Traffic wird am falschen Punkt hart gedroppt oder heruntermarkiert, wodurch selbst priorisierte Klassen instabil werden. Dokumentation sollte daher Policer und Shaper als explizite „Knoten“ in den Flow-Diagrammen darstellen.

• Ingress Policer: häufig am Provider-Edge oder am WAN-Uplink; dokumentieren, welche Klassen wie behandelt werden (drop vs. remark).
• Egress Shaper: typischerweise am Kundenedge, um den Uplink auf eine realistische Rate zu shapen und Congestion kontrolliert im eigenen Gerät zu erzeugen.
• Hierarchie: zuerst shapen, dann innerhalb des Shapers Queues bedienen (klassisches Muster), damit Priorisierung nicht „im Provider“ verloren geht.
• Ausnahmen: z. B. Bulk-Traffic bewusst streng policen, Realtime niemals policen, sondern nur priorisieren und ggf. begrenzen.

Wichtig: Dokumentieren Sie nicht nur „es gibt einen Policer“, sondern den Zweck („Schutz gegen Überbuchung“, „CIR Einhaltung“) und die Auswirkungen auf Klassen.

Domänengrenzen dokumentieren: Trust, Translation und Preservation

Die wichtigste Stelle in QoS-Flow-Dokumentation sind Übergänge zwischen Domänen. Hier entscheidet sich, ob Marking und Priorisierung überleben.

Typische Domänengrenzen

• Access → Distribution: CoS/DSCP Trust am Edge, Remarking untrusted Clients.
• Campus → WAN: Mapping in Provider-Klassen, Shaping/Policing, MPLS EXP (falls genutzt) oder DSCP Preservation.
• WAN → DC: Rückübersetzung in DC-Queue-Modell, ggf. neue Trust Boundary.
• SD-WAN → Internet/SASE: Traffic-Klassen werden in SASE-Policies überführt, Logs/Evidence ändern sich.

Einheitliche Darstellung als „QoS Gate“

• Trust Gate: „Marking trusted“ oder „remark to default“
• Translation Gate: „DSCP EF → Provider Class Gold“
• Enforcement Gate: „Policer CIR 100M, exceed remark/drop“

So kann ein Engineer bei Problemen sofort prüfen, an welchem Gate die Priorisierung verloren geht.

QoS und WLAN: Besonderheiten bei Roaming, Airtime und Marking

Wenn QoS-Flows WLAN berühren, kommen zusätzliche Faktoren hinzu: Airtime ist begrenzt, Roaming erzeugt kurze Unterbrechungen, und Marking wird nicht immer 1:1 übertragen. Eine gute QoS-Doku sollte mindestens festhalten:

• WMM-Klassen: wie Voice/Video/Best Effort/Background gemappt sind (WMM Access Categories).
• Trust Boundary: ob Clients DSCP setzen dürfen oder ob der Controller/AP markiert.
• Roaming Policies: welche Schwellenwerte gelten (RSSI/SNR), weil Roaming-Ereignisse Voice beeinflussen können.
• Backhaul: AP-Uplinks müssen QoS Markings übernehmen (Trunks/CoS), sonst endet QoS am Access Point.

QoS über SD-WAN: Klassen, SLA und Pfadwahl als Teil der Doku

SD-WAN bringt häufig ein eigenes Klassifizierungsmodell: Applikationen werden erkannt, Traffic Klassen zugeordnet, und Pfade werden anhand SLA-Metriken gewählt (Loss/Latenz/Jitter). Ihre QoS-Flow-Doku sollte daher SD-WAN als Domäne mit eigener Policy-Logik behandeln:

• Traffic Classes: welche SD-WAN-Klassen entsprechen Ihren DSCP-Klassen.
• SLA Thresholds: ab wann wird umgeschaltet (z. B. Loss > 1% → Pfadwechsel).
• Overlay vs. Underlay: wird DSCP im Overlay erhalten, kopiert oder neu gesetzt?
• DIA Breakouts: welche Klassen dürfen lokal ins Internet, welche müssen über zentralen Egress/SASE.

Für SLO/SLI-Begriffe ist Google SRE – Service Level Objectives eine gute Referenz, um QoS-Ziele in messbare Indikatoren zu übersetzen.

Messbarkeit und Evidence: QoS-Doku ohne Telemetrie bleibt Theorie

QoS ist nur so gut wie seine Messbarkeit. Eine professionelle Dokumentation verlinkt daher zu Monitoring- und Evidence-Artefakten, ohne in Tool-Details zu versinken:

• SLIs: Loss, Jitter, Latenz pro Klasse, Queue Drops, Policer Drops, Queue Utilization.
• Messpunkte: wo wird gemessen (Edge, Hub, Provider handoff, SASE PoP)?
• Alerts: Schwellenwerte pro Klasse (z. B. Voice Jitter > X ms), inklusive Eskalationspfad.
• Runbooks: „QoS Degradation“, „Marking Drift“, „Policer Drops“ als SOPs.

Das macht QoS auditfähig und betrieblich robust: Sie können nachweisen, dass Klassen existieren und wirken.

Governance: QoS als „Living Documentation“ mit Reviews und DoD

QoS driftet schnell, wenn neue Sites, neue Provider oder neue Applikationen hinzukommen. Deshalb sollte QoS-Dokumentation wie Code behandelt werden:

• Definition of Done: keine neue App-Klasse, keine neue Site, kein neuer Provider ohne Update von Marking Catalog, Queue-Matrix und relevanten Flow-Diagrammen.
• Pull Requests/Merge Requests: Änderungen werden reviewed (NetOps + WAN/SD-WAN Owner, bei Egress/SASE zusätzlich Security).
• CI Checks: Broken Links, Metadatenpflicht (Owner, Datum, Scope), Linting der Tabellen/Registry.

Referenzen: GitHub Pull Requests und GitLab Merge Requests. Für CI: GitHub Actions.

Typische Anti-Pattern bei QoS-Flow-Dokumentation

• QoS nur im WAN: Marking im Campus fehlt; Lösung: Trust Boundaries und Marking Catalog end-to-end.
• DSCP überall „trusted“: Missbrauch möglich; Lösung: Trust nur an definierten Ports, sonst Remarking.
• Queues ohne Domänenübersetzung: EF landet anderswo; Lösung: Queue-Matrix und Translation Matrix.
• Policer ohne Flow-Kontext: harte Drops unerwartet; Lösung: Policer/Shaper als Gate im Flow-Diagramm.
• Keine Messbarkeit: QoS bleibt Glaubensfrage; Lösung: SLIs, Messpunkte, Alerts und Runbooks verlinken.
• Alles in einem Diagramm: unlesbar; Lösung: „One Flow per Use Case“ und klare Layered Views.

Checkliste: QoS Flows dokumentieren über Marking, Queues und Policer über Domänen

• Das Hauptkeyword „QoS Flows dokumentieren“ ist als Portfolio umgesetzt (Flow-Views pro Use Case, Marking Catalog, Queue-Matrix, Translation Matrix, Domain Boundary Views)
• Marking ist als Contract dokumentiert (DSCP/CoS pro Klasse, Trust Boundaries, Remarking Rules) mit RFC-Referenzen (RFC 2474, RFC 2475)
• Queues sind domänenweit logisch definiert und plattformspezifisch gemappt (Queue-Matrix), inkl. Scheduler-Parameter
• Policer und Shaper sind als explizite Gates im Flow sichtbar (wo wird geschnitten, wo geglättet, welche Klassen betroffen)
• Domänengrenzen (Campus/WAN/DC/SD-WAN/SASE/Cloud) sind als Trust/Translation/Enforcement Gates dokumentiert
• WLAN-spezifische QoS-Aspekte sind berücksichtigt (WMM-Klassen, Roaming, AP-Uplink Marking)
• SD-WAN Policy-Logik ist integriert (Traffic Classes, SLA Thresholds, Pfadwahl, DIA Breakouts) und SLO/SLI-Begriffe sind sauber verwendet (SRE SLOs)
• Messbarkeit und Evidence sind verankert (SLIs: Loss/Jitter/Latenz, Queue Drops, Policer Drops; Messpunkte; Alerts; Runbooks)
• Dokumentation ist „living“ (DoD, PR/MR Reviews, CI Checks), unterstützt durch GitHub Actions
• PHB-Referenzen sind gesetzt (EF: RFC 2598, AF: RFC 2597)

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.