QoS Audits sind der praktische Weg, um Quality-of-Service nicht nur technisch zu konfigurieren, sondern revisionssicher zu belegen: Welche Policies sind aktiv? Welche Markings werden akzeptiert oder verändert? Wo entstehen Drops und warum? In Telco- und Enterprise-Umgebungen reicht es für Compliance, Kundenverträge oder interne Governance nicht aus, „wir haben QoS eingerichtet“ zu sagen. Prüfer, Kunden oder interne Kontrollinstanzen erwarten nachvollziehbare Nachweise über den Zustand des Netzes zu einem bestimmten Zeitpunkt – inklusive Versionsstand, Rollout-Umfang, Wirksamkeit an Engpässen und einer konsistenten Mess- und Reportinglogik. Genau hier trennt sich „QoS ist konfiguriert“ von „QoS ist auditierbar“: Revisionssicherheit bedeutet, dass Sie Konfigurationen, Zustände und Messdaten manipulationsarm erfassen, konsistent korrelieren und wiederholbar auswerten können. Dieser Artikel zeigt, wie Sie QoS Audits so aufbauen, dass Policies, Markings und Drops belastbar nachgewiesen werden – ohne sich in Tool-Dschungel oder reinen CLI-Screenshots zu verlieren.
Was ein QoS Audit leisten muss: Konfiguration, Betrieb und Wirkung
Ein professionelles QoS Audit beantwortet drei Fragen: Erstens, ob die vorgesehenen QoS-Policies tatsächlich ausgerollt und aktiv sind (Configuration Compliance). Zweitens, ob Markierungen und Trust Boundaries so funktionieren wie definiert (Marking Integrity). Drittens, ob die QoS-Mechanik im Betrieb die gewünschte Wirkung erzielt – insbesondere an Congestion Points (Effectiveness). Revisionssicherheit entsteht, wenn diese drei Ebenen über Zeit nachvollziehbar sind, inklusive Change-Historie und Messmethodik.
- Configuration Compliance: Welche Policy ist wo aktiv? Entspricht sie dem Standard/Template?
- Marking Integrity: Werden DSCP/PCP/MPLS-TC korrekt übernommen, gemappt oder remarkt?
- Effectiveness: Gibt es Queue-Drops, Queue-Delay, Policer-Drops oder Missbrauch?
- Traceability: Wann wurde was geändert, durch wen, mit welchem Ticket/Change?
Audit-Scope festlegen: Welche Domänen und Übergänge sind prüfkritisch?
QoS wirkt nicht überall gleich. Deshalb sollte ein Audit den Scope klar definieren: Access, Aggregation, Core, Interconnect, Cloud-Edge und Overlay-Tunnel sind typische Prüfdomänen. Besonders prüfkritisch sind Übergänge, weil dort Markings häufig verloren gehen oder falsch gemappt werden: LAN↔WAN, Ethernet↔IP, IP↔MPLS, Overlay↔Underlay, Provider↔Provider. Ein revisionssicherer Nachweis zeigt nicht nur „im Core stimmt es“, sondern belegt die Kette an den relevanten Übergängen.
- Access/Edge: Trust Boundary, Subscriber-/Service-Policies, HQoS, Policer/Shaper.
- Aggregation: Engpässe, Mikrobursts, Queue-Limits, Class-Based Scheduling.
- Core: konsistente Klassenbehandlung, MPLS-TC/DSCP-Modelle, Failover-Pfade.
- Interconnect: definierte Profile, Mapping-Regeln, realistische Kontrollgrenzen.
- Overlay: DSCP Copy Inner↔Outer, MTU/Fragmentierung, per-Tunnel QoS.
Revisionssicherer Nachweis beginnt mit Standards: Referenzmodell und Mappingtabellen
Ein Audit kann nur prüfen, was klar definiert ist. Deshalb braucht es ein QoS-Referenzmodell: Traffic Classes, zugelassene Markings, Queueing-Verhalten, Shaping/Policing-Regeln und eine zentrale Mappingtabelle (DSCP↔PCP↔MPLS-TC). Revisionssicher heißt: versioniert, freigegeben, nachvollziehbar. Ohne diese Basis werden Audits zu Diskussionen über „was war gemeint“ statt zu einer Prüfung über „was ist umgesetzt“.
- Klassenkatalog: Name, Zweck, Beispiele, zulässige DSCP-Werte, Trust-Regeln.
- PHB-Definition: Queue-Typ, Scheduler, Drop-Policy, Queue-Limits, Prioritätslimits.
- Mappingtabellen: DSCP↔PCP↔MPLS-TC, ggf. WMM für WLAN-nahe Domänen.
- Produkt-/Service-Profile: welche Kunden/Services dürfen welche Klassen nutzen?
Policies revisionssicher nachweisen: Konfiguration, Aktivität und Rollout-Abdeckung
Der häufigste Audit-Fehler ist, nur Konfigurationen zu sammeln, aber nicht zu beweisen, dass sie aktiv sind und wo sie aktiv sind. Revisionssicher ist eine Kombination aus: Snapshot (Konfiguration), State (aktiv gebunden an Interface/Service) und Inventory (welche Geräte/Interfaces gehören zum Scope). Ziel ist ein Nachweis, der auch Monate später reproduzierbar ist: „Auf diesen 1.247 Interfaces waren am Stichtag diese QoS-Policies aktiv – identisch zu Template-Version X.“
- Inventory-Export: Geräte, Rollen, Interfaces, Linktypen, Kunden-/Servicezuordnung.
- Policy-Bindings: pro Interface/Service nachweisen, welche Policy tatsächlich gebunden ist.
- Template-Compliance: Abgleich gegen Referenz/Golden Config, inklusive Abweichungsreport.
- Versionierung: Policy-Version und Rollout-Zeitpunkt dokumentieren (Change-ID/Ticket).
Typische Nachweisartefakte (auditfest aufbereitet)
- Konfigurations-Snapshots: signiert/immutable gespeichert, mit Zeitstempel und Geräte-ID.
- State-Exports: aktive Policy-Bindings und Interface-Status (nicht nur „in config vorhanden“).
- Diff-Reports: Abweichungen vom Standard mit Begründung und Ablaufdatum (Exception Register).
Markings revisionssicher nachweisen: Trust Boundaries, Remarking und Mapping-Integrität
Markings sind im Audit besonders kritisch, weil sie die Grundlage jeder Klassenbehandlung bilden. Ein revisionssicherer Nachweis umfasst drei Ebenen: Definition (welche Markings sind erlaubt), Enforcement (wo werden sie geprüft/remarked) und Integrity (bleiben sie über Domänen hinweg erhalten). Praktisch bedeutet das: Sie dokumentieren Trust Boundaries, zeigen die konkreten Remarking-Regeln und belegen durch Messungen oder Stichproben, dass DSCP/PCP/MPLS-TC korrekt gemappt sind.
- Trust Boundary Nachweis: an welchen Kanten wird Marking vertraut, an welchen normalisiert?
- Allowlist-Policy: nicht erlaubte DSCP-Werte werden auf Best Effort gesetzt.
- Mapping-Konsistenz: DSCP↔PCP↔MPLS-TC auf allen relevanten Plattformen gleich.
- Overlay-Integrität: DSCP Copy Inner↔Outer nachweisen, damit Underlay-QoS wirkt.
Wie man Marking-Integrität praktisch belegt
- Stichproben mit Paketmitschnitt: an definierten Messpunkten DSCP/PCP/Tunnel-Header prüfen.
- Flow-/Telemetry-Daten: Verteilung der DSCP-Werte pro Interface und Richtung; Ausreißer identifizieren.
- Counter für Remarking: Zähler für ummarkierte Pakete als Nachweis für Enforcement.
Drops revisionssicher nachweisen: Queue-Drops, Policer-Drops und die Ursache dahinter
„Es gibt Drops“ ist auditseitig wertlos, wenn nicht klar ist, welche Drops, in welcher Klasse, zu welchem Zeitpunkt und aus welchem Grund. Revisionssichere Drop-Nachweise unterscheiden mindestens drei Kategorien: Drops durch Queue-Overflow (Congestion), Drops durch Policing (Profilüberschreitung/Missbrauch) und Drops durch physikalische Fehler (CRC, Link-Issues). Zusätzlich ist Queue-Delay als Frühindikator wichtig, weil er zeigt, dass Congestion entsteht, bevor Drops sichtbar werden.
- Queue-Drops: pro Klasse, pro Interface, mit Zeitfenster und Peak-/Perzentil-Auswertung.
- Policer-Drops/Remarking: Beleg, dass Profile durchgesetzt werden (oder zu knapp sind).
- Congestion-Indikatoren: Queue-Delay, Queue-Depth, ECN/WRED-Marks (falls genutzt).
- Physikalische Drops: separate Behandlung, weil QoS hier nicht die Ursache ist.
Wichtige Audit-Frage: „Drop ist nicht gleich Drop“
Ein LLQ-Drop in einer Voice-Klasse hat eine andere Bedeutung als ein Best-Effort Tail Drop oder ein Policer-Drop durch Missmarking. Revisionssicher wird es, wenn Sie Drop-Arten klassifizieren und mit der Policy-Logik verknüpfen: Wo dürfen Drops überhaupt auftreten? Welche Klassen sollten nahezu dropfrei sein? Und welche Drops sind erwartbar (z. B. Scavenger unter Congestion)?
Mess- und Reportinglogik: Statistik, Zeitfenster, Perzentile
Audits scheitern oft an uneinheitlicher Statistik. Ein Team berichtet Monatsmittelwerte, ein anderes 95. Perzentile in 5-Minutenfenstern, ein drittes schaut auf Peaks. Revisionssichere Reports definieren daher: Zeitfenster, Aggregationsebene und Statistik eindeutig. Für QoS sind Perzentile oft sinnvoller als Mittelwerte, weil kurze, heftige Peaks für Voice/Video entscheidend sind. Gleichzeitig sollten Reports die Messstrecke nennen: Messpunkte und Domänenabgrenzung müssen klar sein.
- Zeitfenster: z. B. 5 Minuten für operative Sicht, 1 Monat für Compliance.
- Statistik: p95/p99 für Delay/Utilization, absolute Counts für Drops, Rate pro Sekunde für Peaks.
- Scope: pro Standort, pro Link, pro Klasse; nicht nur global aggregiert.
- Messstrecke: innerhalb eigener Domäne vs. bis Cloud/Interconnect getrennt ausweisen.
Chain-of-Custody: Wie Audit-Daten manipulationsarm gespeichert werden
Revisionssicherheit ist nicht nur „was“ Sie messen, sondern auch „wie“ Sie es ablegen. Ein auditfester Nachweis benötigt eine nachvollziehbare Datenkette: wer hat wann welche Daten erhoben, wo wurden sie gespeichert, und wie wird Integrität sichergestellt? Praktisch heißt das: unveränderliche Speicherung (Write Once, Read Many oder zumindest immutability), klare Zeitstempel, eindeutige Identifikatoren und idealerweise kryptografische Hashes, damit Manipulation erkennbar wäre.
- Immutable Storage: Snapshots und Exporte versioniert und unveränderlich speichern.
- Time Sync: konsistente Zeitbasis (NTP/PTP), sonst sind Korrelationen wertlos.
- Hashes/Signaturen: Integrität von Reports und Rohdaten nachweisbar machen.
- Retention: Aufbewahrungsfristen je nach SLA/Compliance definieren.
Audit-Playbook: Ein wiederholbarer Ablauf für QoS Audits
Damit QoS Audits nicht jedes Mal neu erfunden werden, lohnt sich ein Playbook. Es strukturiert die Datenerhebung, die Prüfregeln und die Berichtslogik. Ein guter Ablauf kombiniert Konfigurationsprüfung (Templates/Bindings), Marking-Integrität (Trust/Mappings) und Wirksamkeitsprüfung (Drops/Delay) in einem wiederholbaren Prozess. So wird der Audit nicht zur „Punkt-in-Zeit“-Aktion, sondern zu einem kontinuierlichen Qualitätsnachweis.
- Scope & Inventory: Zielsysteme, Rollen, Interfaces, Services und Domänen festlegen.
- Config Snapshot: Konfigurationen ziehen, versionieren, signieren.
- Binding Verification: aktive Policy-Bindings und Laufzeitstate exportieren.
- Marking Tests: Mappingtabellen prüfen, Stichproben messen, Remarking-Zähler auswerten.
- Drop/Delay Analysis: Klassenweise Drops und Queue-Delay im definierten Zeitfenster auswerten.
- Exception Handling: Abweichungen dokumentieren, Owner/Deadline, Risiko und Maßnahmenplan.
- Report: standardisierte Struktur mit Anhang der Rohdatenreferenzen und Hashes.
Häufige Audit-Failure-Patterns und wie Sie sie vermeiden
Ein QoS Audit kann formal korrekt wirken und trotzdem keinen echten Nachweis liefern. Typische Fehler sind: nur CLI-Auszüge ohne Kontext, fehlende Bindings, fehlende Zeitfenster, fehlende Abdeckung von Engpässen oder fehlende Unterscheidung von Drop-Arten. Ebenso häufig: Marking wird dokumentiert, aber nicht verifiziert; oder QoS wird im Core geprüft, obwohl die Congestion im Access sitzt. Ein revisionssicheres Audit adressiert genau diese Lücken.
- „Policy ist in der Config“: ohne aktives Binding kein Nachweis der Wirkung.
- „Drops sind da“: ohne Klassenzuordnung und Ursache keine Aussagekraft.
- „DSCP ist gesetzt“: ohne Mapping- und Trust-Nachweis keine End-to-end Integrität.
- Keine Failover-Prüfung: Backup-Pfade ohne QoS brechen SLOs genau dann, wenn es zählt.
- Fehlende Messlogik: Mittelwerte verschleiern Peaks; Perzentile und kurze Zeitfenster fehlen.
Audit-ready QoS: Wie Sie Governance, Templates und Monitoring zusammenführen
Der sicherste Weg zu revisionssicheren QoS Audits ist ein audit-ready Design: Standards definieren Klassen, Markings und Limits; Templates setzen sie konsistent um; Monitoring liefert die Wirksamkeitsdaten; und Rezertifizierungsprozesse verhindern Drift. Wenn diese Elemente verzahnt sind, wird der Audit zum Export eines bestehenden Systems – nicht zum hektischen Sammeln von Screenshots kurz vor dem Termin. Damit lassen sich Policies, Markings und Drops nicht nur nachweisen, sondern auch erklären: Was ist normal, was ist Abweichung, und welche Maßnahmen sind geplant oder bereits umgesetzt?
