QoS Compliance Audits: Evidence, Config Exports und Counter Reports

QoS Compliance Audits sind der strukturierte Weg, um Quality of Service nicht nur zu konfigurieren, sondern nachweisbar zu betreiben – gegenüber Kunden, internen Governance-Teams, Providern oder im Rahmen von SLA- und Sicherheitsanforderungen. In vielen Organisationen ist QoS über Jahre gewachsen: verschiedene Templates je Standort, unterschiedliche Vendor-Defaults, gelegentliche „Hotfix“-Policies im Incident und eine Dokumentation, die der Realität hinterherläuft. Spätestens wenn es um Auditfragen geht („Wie stellen Sie sicher, dass Voice priorisiert wird?“ oder „Wo ist belegt, dass DSCP korrekt gemappt wird?“), reicht ein Screenshot aus einem Dashboard nicht mehr. Ein belastbarer QoS Compliance Audit braucht drei Säulen: Evidence (Beweise aus Messdaten und Beobachtung), Config Exports (konfigurationsseitiger Nachweis, dass die richtigen Policies existieren und gebunden sind) sowie Counter Reports (operativer Nachweis, dass die Policies tatsächlich greifen und nicht nur „auf dem Papier“). Dieser Artikel zeigt, wie Sie QoS Compliance Audits aufbauen, welche Artefakte Auditoren typischerweise akzeptieren, wie Sie Konfigurations- und Telemetry-Daten in eine nachvollziehbare Beweiskette überführen und welche typischen Fallstricke Sie vermeiden sollten, damit ein Audit nicht zur nervösen Improvisation wird.

Was „QoS Compliance“ in der Praxis bedeutet

Compliance im QoS-Kontext ist selten eine einzelne Metrik. Es geht um die Übereinstimmung zwischen einem definierten Standard (Klassenmodell, DSCP/CoS-Matrix, Trust Boundary, Scheduling-Intent) und dem tatsächlichen Zustand im Netzwerk. Ein Audit fragt daher nicht nur „Gibt es QoS?“, sondern:

• Existenz: Sind Policies und Mappings überall vorhanden, wo sie laut Standard sein müssen?
• Konsistenz: Sind Klassen, Markierungen und Queue-Zuordnungen über Standorte und Vendoren hinweg gleich?
• Wirksamkeit: Greift die Policy bei realem Traffic (Classifier-Hits), und schützt sie Echtzeit unter Last (Queues/Drops)?
• Nachvollziehbarkeit: Gibt es dokumentierte Standards, Versionierung, Review Gates und Rezertifizierungen?

Ein gutes Audit liefert daher eine Beweiskette von „Standard“ → „Konfiguration“ → „Betrieb/Telemetry“.

Audit-Scope definieren: Ohne Scope keine belastbare Evidence

QoS ist end-to-end, aber Audits müssen pragmatisch bleiben. Entscheidend ist, den Scope so zu schneiden, dass er auditierbar ist: welche Standorte, welche Pfade, welche Services (Voice/Video/RTC), welche Geräteklassen (Access/WAN/Security), welche Provider-Übergaben. In vielen Fällen ist ein risikobasierter Scope sinnvoll: Engpässe und Echtzeitpfade zuerst (WAN-Edges, Aggregation, WLAN, Security Stacks), Core/Transit nur soweit nötig, um Mapping-Konsistenz zu belegen.

• Services: z. B. Voice/Video/UCaaS, Contact Center, IMS/SIP Trunks.
• Congestion Domains: Uplinks und Aggregationspunkte, an denen Queueing real entsteht.
• Domänengrenzen: Provider-Übergaben, Interconnects, Cloud-Onramps.
• Zeitraum: z. B. letzte 30/90 Tage plus definierte Peak-Zeiten (Busy Hour).

Die Evidence-Pyramide: Von Papier zu messbarem Nachweis

Audits scheitern oft daran, dass nur eine Ebene geliefert wird: entweder Konfigurationen ohne Betriebsnachweis oder KPI-Dashboards ohne Mapping- und Attachment-Belege. Robust ist eine Evidence-Pyramide mit drei Ebenen:

• Design Evidence: Standarddokumente (Klassenmodell, DSCP/CoS/WMM-Matrix, Trust Boundary, Intent).
• Config Evidence: Exporte, die zeigen, dass Policies existieren, korrekt benannt und korrekt gebunden sind.
• Runtime Evidence: Counter Reports und Telemetry, die belegen, dass Traffic tatsächlich in den Klassen läuft und Queues wie geplant wirken.

Je stärker die Runtime-Evidence, desto weniger Diskussion entsteht über „theoretisch vorhanden“ vs. „praktisch wirksam“.

Config Exports: Was Sie aus Konfigurationen wirklich beweisen müssen

Config Exports sind im Audit der Nachweis, dass Ihr Netzwerk dem Standard entspricht. Wichtig ist, nicht ganze Konfigurationen unstrukturiert zu dumpen, sondern gezielt die QoS-relevanten Blöcke zu exportieren: Class-Maps, Policy-Maps, DSCP->Queue Mapping, Interface Attachments, Shaper/Policer-Definitionen und Trust Boundary Regeln. Außerdem muss nachvollziehbar sein, welche Version des Templates oder Standards verwendet wird.

• Klassendefinitionen: welche DSCP/ACL/Match-Kriterien gehören zu VOICE/MEDIA/SIGNAL/BE/BULK?
• Scheduling/Shaping: LLQ/Strict Priority, Bandbreitenanteile, Shaper-Rate und Hierarchien.
• Interface Attachments: wo ist die Policy gebunden (WAN egress ist meist auditkritisch)?
• Trust Boundary/Rewrite: wo wird DSCP trusted, wo normalisiert, wo re-marked?
• Overlay/Encapsulation: Regeln für DSCP inner->outer Copy, falls relevant.

Attachment-Nachweis: Der häufigste Compliance-Fail

In Audits ist „Policy existiert, aber nicht gebunden“ ein Klassiker. Deshalb sollten Config Exports immer einen expliziten Attachment-Teil enthalten, der zeigt, dass die QoS-Policy an den richtigen Interfaces und in der richtigen Richtung aktiv ist. Besonders wichtig ist der Egress an Engpässen (WAN/Internet-Uplinks) und kritische Übergänge (Security, Tunnel-Edges).

Naming und Versionierung: Warum Auditoren Konsistenz sehen wollen

Sauberes Naming ist nicht nur „Ordnung“, sondern Auditfähigkeit. Wenn Klassen und Policies überall anders heißen, wird Evidence schwer vergleichbar. Ein QoS Compliance Audit profitiert enorm von standardisierten Namen (z. B. QOS_CLASS_VOICE, QOS_POLICY_WAN_EGRESS) und von Template-Versionen (V1/V2). Damit können Sie zeigen, dass Standorte einer definierten Version entsprechen und Abweichungen identifizierbar sind.

• Standardisierte Class-Namen: erleichtern Counter Reports und Vergleichbarkeit.
• Policy-Namen nach Rolle/Richtung: minimieren Fehlattachments.
• Versionskennzeichen: macht Migrationen auditierbar und Rollbacks nachvollziehbar.

Counter Reports: Der operative Beweis, dass QoS greift

Counter Reports sind die zweite Säule eines QoS Compliance Audits: Sie zeigen, dass Traffic tatsächlich in den vorgesehenen Klassen landet (Classifier-Hits) und wie die Queues sich verhalten (Queue Depth/Delay, Drops). Für Audits sind diese Berichte besonders wertvoll, weil sie zwischen „Konfiguration vorhanden“ und „Konfiguration wirksam“ unterscheiden. Ein guter Counter Report ist zeitlich eingegrenzt (z. B. Busy Hour), klassenspezifisch (Voice/Media/Signal/BE/Bulk) und enthält idealerweise sowohl Volumen als auch Ereignisse (Drops, Delay-Spitzen).

• Classifier-Hits: Packets/Bytes pro Klasse belegen Klassifizierung und Marking-Konsistenz.
• Per-Class Drops: zeigen, ob Echtzeitpakete betroffen sind oder ob BE/Bulk die Last trägt.
• Queue Depth/Delay: belegt, ob Congestion kontrolliert in Ihren Queues stattfindet.
• Drop Reasons: liefern „warum“ (Tail Drop, Policer, Buffer Exhaustion) für Root Cause und Governance.

Evidence aus Telemetry: Perzentile, Peaks und „High-Signal“ Zeitfenster

Audits werden überzeugender, wenn Sie nicht nur Mittelwerte zeigen. Für Echtzeit sind Peaks entscheidend, daher sind Perzentile (95p/99p) und Peak-Werte (Max Queue Depth/Delay) wichtig. Statt „Durchschnittslast“ sollten Sie Zeitfenster wählen, in denen QoS wirklich gefordert ist: Meeting-Peaks, Busy Hour im Contact Center, Wartungsfenster mit Updates, internationale Traffic-Spitzen. So belegen Sie, dass QoS nicht nur in ruhigen Zeiten „gut aussieht“, sondern unter realer Konkurrenz schützt.

• Queue Delay 99p: zeigt, ob Echtzeit in Spitzen gefährdet ist.
• Peak Queue Depth: macht Microbursts und Bufferbloat-Tendenzen sichtbar.
• Bad-Call-Rate/MOS-Perzentile: falls verfügbar, verbindet QoS mit QoE.
• Change-Overlays: markieren, ob QoS-Änderungen Auswirkungen hatten.

Beweisketten bauen: Vom Symptom zur Konfiguration

Ein starkes Audit liefert nicht nur Rohdaten, sondern eine nachvollziehbare Beweiskette. Beispielhaft für Echtzeit:

• Policy Standard: Voice ist in Klasse VOICE, strikt priorisiert und begrenzt; Media ist separat limitiert.
• Config Export: zeigt DSCP-Matching, Queueing-Parameter, Shaping und Attachment am WAN-Egress.
• Counter Report: zeigt, dass Voice-Traffic tatsächlich in VOICE matched und kaum/keine Drops hat.
• Telemetry: zeigt niedrige Voice Queue Delay/Depth auch in Busy Hour; Drops treten primär in BE/Bulk auf.

Das ist ein auditierbarer Nachweis: Standard eingehalten, wirksam, unter Last.

Audit-Artefakte strukturieren: Was in ein QoS Evidence Pack gehört

Damit ein Audit effizient ist, sollten Sie ein standardisiertes Evidence Pack erstellen, das wiederverwendbar ist. Es muss nicht jedes Detail enthalten, aber alles, was für Nachvollziehbarkeit und Vergleichbarkeit nötig ist.

• QoS Standard Dokument: Klassenmodell, DSCP/CoS/WMM-Matrix, Trust Boundary, Designprinzipien.
• Scope & Inventory: Liste der auditrelevanten Geräte/Interfaces/Standorte/Interconnects.
• Config Exports: QoS-Blöcke (class/policy/maps, mappings, attachments, shapers/policers) pro Gerät oder Template.
• Counter Reports: Classifier-Hits, Per-Class Drops, Queue Stats im definierten Zeitraum.
• Telemetry Dashboards/Exports: Perzentile und Peaks, idealerweise mit Change-Markern.
• Ausnahmen & Risiken: dokumentierte Abweichungen, geplante Remediations, Zeitplan.

Compliance Checks, die Sie automatisieren sollten

QoS Compliance wird deutlich einfacher, wenn Sie wiederkehrende Checks automatisieren. Viele Audit-Fails sind deterministisch: Policy fehlt am Interface, DSCP->Queue Mapping weicht ab, Trust Boundary ist inkonsistent, unerlaubte Policers auf Voice existieren. Diese Checks lassen sich regelmäßig als „Rezertifizierung“ laufen lassen und als Evidence für kontinuierliche Kontrolle nutzen.

• Attachment Check: ist die richtige QoS-Policy am richtigen Egress-Interface gebunden?
• Mapping Check: DSCP/MPLS TC/CoS Mapping entspricht der Source of Truth.
• Trust Boundary Check: Marking wird nur an definierten Punkten trusted und sonst normalisiert.
• Guardrail Check: keine Policers auf Echtzeit, kein WRED auf RTP-Klassen, LLQ begrenzt.
• Runtime Check: Default/Unmatched-Anteil bleibt im erwarteten Band; Classifier Drift wird erkannt.

Typische Audit-Failures und wie Sie sie vermeiden

• Policy nicht gebunden: Konfiguration existiert, aber nicht am WAN-Egress; Attachment-Report verpflichtend machen.
• DSCP drift: gleiche Klasse hat unterschiedliche Markierungen je Standort; zentrale DSCP-Matrix und Mapping-Checks.
• Fehlklassifizierung: Voice läuft in Best Effort; Classifier-Hits und Default/Unmatched-Reports einfordern.
• Unkontrollierte Congestion: kein Shaping, Congestion passiert im Modem/Provider; Shaping-Standard als Compliance-Kriterium.
• Policer auf Echtzeit: sporadische Drops und schwer nachweisbare QoE-Probleme; Guardrail „Never Event“ definieren.
• Nur Mittelwerte: Peaks fehlen im Reporting; Perzentile und Busy-Hour-Fenster aufnehmen.

Rezertifizierung als Audit-Booster: Kontinuierliche Compliance statt punktuelle Prüfung

Auditoren bewerten nicht nur den Zustand, sondern auch den Prozess. Wenn Sie eine regelmäßige QoS-Rezertifizierung nachweisen können (z. B. quartalsweise oder nach Major Changes), steigt die Glaubwürdigkeit erheblich. Eine Rezertifizierung sollte immer dieselben Evidence-Artefakte erzeugen: kurze Config-Compliance-Checks, definierte Telemetry-Auszüge aus Peak-Zeiten und eine Abweichungsliste mit Remediation. Das macht QoS Compliance zu einem Betriebssystem, nicht zu einem Projekt.

• Periodische Reports: Mapping/Attachment/Guardrail-Checks plus Peak-Telemetry.
• Change-getrieben: nach Upgrades/Providerwechseln/SD-WAN-Policy-Changes automatisch rezertifizieren.
• Audit Trail: Versionen, Review Gates, Rollbacks und Lessons Learned dokumentieren.

Pragmatische Audit-Checkliste: QoS Compliance mit Evidence, Exports und Counters

• Standard: Klassenmodell + DSCP/CoS/WMM-Matrix + Trust Boundary dokumentiert und versioniert.
• Scope: Congestion Domains, Engpässe, Interconnects und relevante Services klar definiert.
• Config Exports: Klassen/Policies/Mappings/Shaper/Policer + Attachments in der richtigen Richtung.
• Counter Reports: Classifier-Hits, Default/Unmatched, Per-Class Drops, Drop Reasons im Peak-Zeitfenster.
• Telemetry Evidence: Queue Delay/Depth 95p/99p, Peak Depth, Shaper-Headroom, Trendvergleich.
• Abweichungen: dokumentierte Exceptions mit Risiko und Remediation-Plan.
• Rezertifizierung: regelmäßiger Nachweis, dass QoS kontinuierlich geprüft und nicht nur „einmal gebaut“ wird.