Messung von QoS ist der Schritt, der aus „wir haben QoS konfiguriert“ ein belastbares Qualitätsversprechen macht. In vielen Netzen sind Prioritätsklassen, DSCP-Mappings und Shaper schnell eingerichtet – und trotzdem klagen Nutzer über schlechte Sprache, ruckelndes Video oder abreißende Sessions. Der Grund ist fast immer derselbe: Ohne Telemetry, aussagekräftige Counters und korrekt interpretierte Drop Reasons bleibt QoS ein Blindflug. Gerade Echtzeitdienste reagieren empfindlich auf Paketverlust, Jitter und Queueing-Delay, während klassische Interface-Auslastung oft harmlos aussieht. Moderne Plattformen liefern heute weit mehr als nur „Packets in/out“: Streaming Telemetry, per-Queue-Statistiken, Buffer-Occupancy, Scheduler-Delay, ECN/WRED-Metriken und detaillierte Drop-Gründe auf ASIC-Ebene. Wer diese Daten richtig liest, kann Engpässe eindeutig lokalisieren, Fehlklassifizierung erkennen, Bufferbloat nachweisen und die Wirksamkeit von Policies belegen. Dieser Artikel zeigt, wie Sie QoS-Messungen strukturiert aufbauen, welche Zähler wirklich zählen und wie Sie Drop Reasons so interpretieren, dass daraus klare Maßnahmen im Betrieb entstehen.
Warum „Link ist nicht voll“ kein QoS-Beweis ist
Ein häufiger Irrtum: Wenn ein Uplink bei 40–60 % Auslastung liegt, könne es keine Qualitätsprobleme geben. In der Realität entstehen Störungen oft durch Microbursts, ungünstige Puffer, falsches Queue-Mapping oder Congestion an einer anderen Stelle im Pfad. Besonders bei Echtzeittraffic ist Queueing-Delay tödlich: Ein paar hundert Millisekunden zusätzlicher Pufferzeit reichen aus, um Sprache zu stören, Videoframes zu verlieren oder WebRTC in Bitrate-Oszillation zu treiben – auch wenn der durchschnittliche Durchsatz moderat ist. QoS misst man deshalb nicht primär am Interface, sondern an den Queues.
- Microbursts: Kurze Lastspitzen können Buffer füllen, bevor 5-Minuten-Mittelwerte reagieren.
- Bufferbloat: Hohe Latenz ohne Drops ist möglich, wenn Puffer zu groß oder falsch verwaltet sind.
- Falsche Klassifizierung: Echtzeittraffic landet in Best Effort; „genug Bandbreite“ hilft dann nicht.
- Asymmetrie: Upstream kann congested sein, während Downstream entspannt wirkt.
Ein Messmodell für QoS: Von der Policy bis zum Symptom
Damit QoS-Messung nicht aus zufälligen Zähler-Screenshots besteht, hilft ein einfaches Modell: (1) Was ist die intendierte Policy (Klassen, Bandbreiten, Prioritäten)? (2) Wird Traffic korrekt klassifiziert und markiert? (3) Wie verhält sich der Scheduler unter Last (Queue-Delay, Drops, Shaping)? (4) Welche Auswirkungen sieht die Anwendung (Jitter, Loss, MOS, Video-Freeze)? Wenn Sie diese Kette konsequent abarbeiten, können Sie nahezu jede QoS-Frage beantworten – unabhängig vom Hersteller.
- Policy-Ebene: Klassenmodell, DSCP/CoS-Mapping, Shaper/Policer, LLQ/CBWFQ.
- Klassifizierung: Trefferquoten der Classifier, Re-Markings, „unmatched“ Traffic.
- Queueing: Queue-Occupancy, Queueing-Delay, Scheduler-Statistiken, Drops.
- Applikation: RTP/RTCP-Stats, WebRTC Telemetrie, Client Quality Indicators.
Telemetry verstehen: Streaming statt Polling
Traditionelles SNMP-Polling in 5-Minuten-Intervallen ist für QoS-Fehlerbilder oft zu träge. Moderne Netzwerke setzen zunehmend auf Streaming Telemetry (Push), bei der Geräte Metriken in kurzen Intervallen oder ereignisbasiert senden. Das ist besonders wertvoll für Microbursts, kurzfristige Queue-Spikes und transienten Drop. Wichtig ist, dass Sie Telemetry nicht nur „einsammeln“, sondern sinnvoll kuratieren: QoS erzeugt viele Metriken, und ohne Auswahl verlieren Sie sich im Rauschen.
Welche Telemetry-Metriken für QoS am meisten bringen
- Per-Queue Drops: Drops pro Klasse/Queue, idealerweise mit Grund (Drop Reason).
- Queue Depth/Occupancy: aktuelle und maximale Belegung (Bytes/Packets), ggf. als Zeitreihe.
- Queueing-Delay: geschätzte oder gemessene Verweilzeit in der Queue (Scheduler Delay).
- Shaper-Rate: aktuelle Shaping-Rate, Shaper-Backlog, Token-Bucket-Status.
- WRED/ECN: Markings und Drops nach Schwellen (wichtig bei TCP-lastigen Klassen).
Counters: Welche Zähler Sie wirklich interpretieren sollten
QoS-Counters lassen sich grob in drei Gruppen einteilen: Klassifizierungszähler (was wurde wo einsortiert?), Scheduler/Queue-Zähler (wie wurde es behandelt?) und Interface/Hardware-Zähler (was hat die Plattform tatsächlich gedroppt?). In vielen Fehleranalysen werden nur Interface-Discards betrachtet – und dann übersehen, dass Drops in einer Queue stattfinden, lange bevor sie als „Interface Drop“ sichtbar werden. Umgekehrt können Interface-Errors (CRC, Input Errors) auftreten, die QoS gar nicht betrifft. Der Trick ist, Zähler im Kontext zu lesen und zu korrelieren.
- Matched Packets/Bytes: pro Klasse; zeigt, ob Klassifizierung überhaupt greift.
- Offered Rate vs. Transmitted Rate: pro Klasse; zeigt Shaping oder Congestion in der Queue.
- Dropped Packets/Bytes: pro Klasse; zeigt echte Verluste innerhalb des QoS-Systems.
- Queue Depth Max: zeigt Burst-Verhalten und Bufferbloat-Risiko.
- Interface Errors: CRC, FCS, alignment; Hinweis auf physische Probleme, nicht QoS.
Drop Reasons: Warum ein Drop nicht gleich ein Drop ist
„Dropped packets“ ist eine zu grobe Aussage. Moderne Switch- und Router-ASICs können häufig den Grund eines Drops ausweisen: Tail Drop (Queue voll), WRED Drop (probabilistisch), Policer Drop (Rate überschritten), Buffer Exhaustion (Shared Buffer leer), MTU/Fragmentation-Themen, ACL/Policy Drop, TTL-Expired, L2-Table Miss, u. v. m. Die genaue Terminologie variiert je nach Hersteller, aber das Prinzip ist universell: Der Drop-Grund bestimmt die Maßnahme. Tail Drops in einer Video-Klasse erfordern andere Korrekturen als Policer Drops auf Voice oder Buffer-Exhaustion im Shared Pool.
Häufige Drop-Kategorien und was sie typischerweise bedeuten
- Tail Drop / Queue Full: Klassische Congestion; Queue zu klein, zu wenig Bandbreite, falsche Klassenlimits.
- Policer Drop: Rate überschritten; Policer zu aggressiv oder Traffic falsch markiert/klassifiziert.
- WRED Drop: Bewusste Drops zur TCP-Stabilisierung; falsch, wenn auf RTP/UDP angewendet.
- Buffer Exhaustion / Shared Buffer: Plattformressourcen erschöpft; Microbursts, viele gleichzeitige Queues oder falsch dimensionierte Buffer-Pools.
- ACL/Policy Drop: Sicherheits-/Filterregel; QoS kann korrekt sein, Traffic wird aber blockiert.
- L2/L3 Lookup Drops: z. B. ARP/ND/Route Issues; zeigt oft Control-Plane/Forwarding-Probleme.
Queueing-Delay und Bufferbloat: Das unsichtbare QoS-Problem
In Echtzeitnetzen ist Delay oft gefährlicher als Drop, weil es sich schleichend einschleicht und von klassischen Countern nicht immer erfasst wird. Bufferbloat entsteht, wenn Puffer zu groß oder falsch genutzt werden und Pakete lange warten, statt früh verworfen oder sauber geschedult zu werden. Das ist besonders relevant an Internet-Uplinks, in CPEs, bei VPN-Tunneln und bei asymmetrischen Links. Wenn Ihre Telemetry Queue-Delay oder Queue-Depth als Zeitreihe liefert, können Sie Bufferbloat sichtbar machen: Die Queue füllt sich, Delay steigt, Applikationen melden Jitter/RTT-Spikes – und trotzdem sind Drops minimal.
- Symptom: Hohe Latenz/Jitter bei niedrigen Drop-Raten.
- Typische Ursache: Fehlendes Shaping, zu große Puffer im Modem/CPE, falsche Scheduler-Parameter.
- Messhinweis: Queue-Occupancy und Delay korrelieren mit RTC-Qualitätsmetriken.
Shaping vs. Policing messen: Woran Sie den Unterschied erkennen
Shaping und Policing werden in der Praxis häufig verwechselt – und auch in Countern nicht sauber getrennt, wenn man nicht genau hinsieht. Shaping führt zu Backlog: Pakete werden verzögert, aber nicht zwingend gedroppt. Policing führt zu Drops: Überschreitet Traffic die Rate, wird verworfen oder re-markiert. In Echtzeitumgebungen ist Shaping oft die bessere Wahl, weil es Priorisierung ermöglicht und Verlust minimiert. Wenn Sie QoS messen, achten Sie darauf, ob eine Klasse Backlog aufbaut (Queue-Depth steigt, Drop bleibt niedrig) oder ob direkt Drops auftreten (Policer Drops steigen).
- Shaper-Indikatoren: Backlog/Queue-Depth, Shaper-Rate am Limit, wenig Drops.
- Policer-Indikatoren: Drops/Re-marks bei Überschreitung, oft ohne hohen Queue-Backlog.
- RTC-Auswirkung: Policer Drops führen sofort zu Audio-/Video-Artefakten.
Fehlklassifizierung erkennen: Der unterschätzte Klassiker
Viele QoS-Probleme entstehen nicht durch zu wenig Bandbreite, sondern durch falsche Einordnung. Wenn RTP in Best Effort landet, ist selbst ein perfekt konfigurierte LLQ nutzlos. Daher sind Klassifizierungszähler essenziell: Wie viele Pakete treffen pro Klasse ein? Wie viele Pakete bleiben „unmatched“? Gibt es Re-Markings am Edge, die DSCP zurücksetzen? Eine besonders hilfreiche Methode ist, Traffic im Problemzeitfenster zu betrachten: Steigt die Best-Effort-Klasse stark an und gleichzeitig verschwindet Traffic aus der erwarteten Echtzeitklasse, ist Fehlklassifizierung sehr wahrscheinlich.
- Matched vs. Expected: Stimmen die Klassen-Volumina mit Ihrer Traffic-Realität überein?
- Unmatched/Default Class: Wächst sie bei Echtzeitproblemen, fehlt oft eine Regel oder Trust Boundary.
- Re-Mark Counters: Zeigen, ob Geräte DSCP anpassen oder zurücksetzen.
WRED/ECN und Drop-Politik: Richtig für TCP, gefährlich für RTP
Random Early Detection (WRED) und Explicit Congestion Notification (ECN) sind Mechanismen, die TCP-Flows helfen können, Congestion früh zu erkennen und ihre Rate zu senken. Für UDP-basierte Echtzeitmedien ist das jedoch meist ungeeignet: WRED erzeugt Drops, die RTP direkt beschädigen. Deshalb ist bei QoS-Messungen wichtig, zu wissen, in welchen Klassen WRED/ECN aktiv ist und welche Drop- oder Marking-Zähler dort ansteigen. Wenn Sie WRED Drops in einer Media-Klasse sehen, ist das ein starkes Indiz für eine falsche Policy oder ein unpassendes Template.
- WRED Drops: sollten primär in datenlastigen TCP-Klassen sichtbar sein, nicht bei Echtzeitmedien.
- ECN Marks: sinnvoll, wenn Endpunkte ECN nutzen; sonst verpufft der Effekt.
- Messbar machen: getrennte Counter für Drops und Marks pro Klasse.
ASIC- und Plattformlimits: Wenn Drops nicht aus QoS kommen, sondern aus Ressourcen
Geräte droppen nicht nur wegen Congestion in einer QoS-Queue. In Hochlastsituationen können Hardware-Ressourcen limitieren: Shared Buffer, VOQ-Engpässe in Chassis-Systemen, Headroom in TCAM/ACL-Processing, oder Limitierungen bei Encapsulation (VXLAN, IPsec). Solche Drops sehen oft anders aus als klassische Tail Drops: Sie tauchen als „buffer exhaustion“, „no resource“, „egress queue starvation“ oder herstellerspezifische Begriffe auf. Hier hilft Telemetry, die Buffer-Pools und Auslastung sichtbar macht, sowie die Korrelation mit Microburst-Indikatoren.
- Shared Buffer Drops: oft microburst-getrieben; erfordern Design- oder Plattformanpassungen.
- VOQ/Chassis-Effekte: Drops können nur auf bestimmten Linecards/Ports auftreten.
- Encap-Overhead: Tunnels erhöhen Burstiness und können Buffer schneller füllen.
End-to-End-Korrelation: Netzwerkmetriken mit Applikationsqualität verbinden
QoS-Messung ist am stärksten, wenn Sie Netz- und Applikationssicht zusammenbringen. Bei Sprache sind RTP/RTCP-Statistiken (Loss, Jitter) oder MOS-ähnliche Indikatoren wertvoll. Bei WebRTC kommen zusätzlich RTT, verfügbare Bitrate und Events wie Transport-Fallback (UDP → TCP/TLS) hinzu. Bei IPTV/Multicast helfen Sequenzverlustmessungen an Empfängern. Wenn Sie diese Applikationsmetriken zeitlich mit Queue-Delay und Drops korrelieren, können Sie Ursache und Wirkung sauber nachweisen: „Um 10:14 steigen Drops in der Media-Queue am Standort-Uplink, gleichzeitig steigt RTP-Loss beim Receiver.“ Das ist deutlich belastbarer als „gefühlt war das Netz langsam“.
- Zeitstempel: Alle Systeme sollten konsistente Zeit haben (NTP), sonst scheitert Korrelation.
- Problemfenster: Minuten- oder Sekundenauflösung, nicht nur Tagesmittelwerte.
- Pfadbewusstsein: Messen an den wirklichen Engpässen, nicht nur am Core.
Praktischer Analyse-Workflow: So interpretieren Sie Counters und Drop Reasons systematisch
Ein strukturierter Workflow verhindert, dass Sie in Daten ertrinken. Starten Sie immer mit dem Symptom (Audio stottert, Video friert, IPTV pixelig), bestimmen Sie das Zeitfenster und prüfen Sie dann in der Reihenfolge: Klassifizierung → Queueing → Drops/Reasons → Plattform/Physik. Erst wenn Sie wissen, ob RTP/Media überhaupt in der richtigen Klasse ist, lohnt es sich, Queue-Details zu interpretieren. Anschließend prüfen Sie, ob der Drop-Grund zu Congestion, Policing oder Ressourcenmangel passt. Zum Schluss schließen Sie physische Fehler aus, weil CRC-Errors jedes QoS-Modell ad absurdum führen können.
- Schritt 1: Zeitfenster und betroffene Flows/Standorte festlegen.
- Schritt 2: Klassifizierungszähler prüfen (Matched/Unmatched, Re-Mark).
- Schritt 3: Queue-Occupancy und Queue-Delay als Zeitreihe ansehen.
- Schritt 4: Drops pro Klasse auswerten und Drop Reasons zuordnen.
- Schritt 5: Plattform-/Buffer-Pools und physische Fehler (CRC) prüfen.
- Schritt 6: Mit Applikationsmetriken (RTP/WebRTC) korrelieren und Maßnahmen ableiten.
Typische Muster und ihre Interpretation: Von „Tail Drop“ bis „Policy Drop“
Im Betrieb tauchen wiederkehrende Muster auf, die Sie mit etwas Übung schnell erkennen. Tail Drops in Best Effort bei hoher Last sind meist akzeptabel, solange Echtzeitklassen stabil bleiben. Tail Drops in einer Media-Klasse sind ein klares Zeichen für Unterdimensionierung oder falsche Priorisierung. Policer Drops in einer Voice-Klasse deuten auf zu niedrige Policer-Werte oder Fehlmarkierung hin. Buffer-Exhaustion weist eher auf Microbursts oder Plattformlimits hin als auf „zu wenig Bandbreite“. Policy Drops zeigen meist Filter-/Security-Themen oder unerwartete Traffic-Pfade.
- Tail Drop in Media/Voice: QoS-Design oder Kapazität an Engpass prüfen (Shaping, Bandbreitenreserve, Klassentrennung).
- Policer Drop auf Echtzeit: Policer entschärfen, Shaping bevorzugen, Markierung und Trust Boundary prüfen.
- Buffer Exhaustion: Microbursts analysieren, Buffer-Tuning/Plattformwahl/Traffic-Glättung betrachten.
- ACL/Policy Drops: Pfad/Firewall-Regeln überprüfen, besonders bei NAT, WebRTC, SIP, Multicast-Control.
Messbarkeit operationalisieren: Dashboards, Baselines und Alarmierung
Damit QoS-Messung im Alltag hilft, braucht es Baselines und gezielte Alarme. Ein gutes Dashboard zeigt nicht „alles“, sondern die entscheidenden Indikatoren pro Engpass: Queue-Delay und Drops der Echtzeitklassen, Shaper-Auslastung am Standort-Uplink, Unmatched-Traffic in Default-Class, sowie physische Error-Raten. Alarme sollten priorisiert sein: Ein einzelner Drop in Best Effort ist irrelevant, ein plötzlicher Anstieg von Drops oder Delay in der Voice-/Media-Klasse ist ein Incident. Baselines helfen, saisonale Muster (z. B. Backup-Fenster) von echten Anomalien zu trennen.
- Baselines: Normalwerte für Queue-Delay, Drops, Shaper-Headroom, Unmatched-Anteile.
- Alarme: Fokus auf Echtzeitklassen, Drop Reasons und Delay-Spikes.
- Drilldown: Von Standort → Interface → Queue → Drop Reason → Flow/Anwendung.
