QoS-Fehler, die Telcos teuer werden, sind selten spektakuläre „One-Liner“-Bugs. Sie sind meistens stille Design- und Betriebsfehler, die sich erst in Busy Hour, bei Failover oder an Domänenübergängen zeigen – und dann richtig Geld kosten: durch SLA-Pönalen, erhöhte Trouble-Tickets, eskalierende NOC-Aufwände, teure Interconnect-Upgrades im Krisenmodus und vor allem durch Kundenabwanderung, wenn Voice knackt oder Video ruckelt. Das Tückische: Viele Stolperfallen entstehen aus gut gemeinten Maßnahmen. Eine zu große LLQ soll Voice schützen, führt aber bei Fehlmarkierung zu Premium-Inflation. Ein „sicherer“ Policer soll Fairness herstellen, erzeugt aber Drop-Cluster und ruiniert Echtzeit. Ein Routing-Failover soll Verfügbarkeit erhöhen, verursacht jedoch Reordering und Jitterspitzen, weil Backup-Pfade QoS-semantisch nicht gleichwertig sind. Ein Template-Rollout soll standardisieren, driftet aber nach wenigen Monaten, weil lokale Hotfixes nicht zurückgeführt werden. Genau deshalb lohnt sich eine klare Liste der häufigsten Fehlerbilder: Sie hilft, Risiken früh zu erkennen, Abnahmen gezielt zu planen und QoS-Change Management so aufzusetzen, dass Qualität nicht nur im Normalbetrieb, sondern auch in Spitzen und Störungen stabil bleibt. In diesem Artikel finden Sie die Top 20 Stolperfallen aus Telco-Praxis und Carrier-Design – jeweils mit typischer Auswirkung, warum der Fehler so teuer wird und woran Sie ihn im Monitoring schnell erkennen.
Stolperfalle 1: LLQ ohne hartes Limit
- Warum teuer: Premium-Inflation führt zu Starvation anderer Klassen; im Peak dropt sogar Voice oder Control.
- Typisches Symptom: LLQ dauerhaft gefüllt, Queueing Delay steigt, EF-Drops in Busy Hour.
- Quick Fix: LLQ immer limitieren und EF nur aus kontrollierten Quellen akzeptieren (Trust Boundary).
Stolperfalle 2: EF/Voice blind vertrauen (fehlende Trust Boundary)
- Warum teuer: Fremde oder falsche Markierungen blähen Premiumqueues auf; SLAs werden instabil.
- Typisches Symptom: EF-Volumen unplausibel hoch, Remarking fehlt oder steigt plötzlich an.
- Quick Fix: DSCP-Whitelist/Conditional Trust, Profilierung pro Kunde/Service, Überschuss remarken.
Stolperfalle 3: QoS am falschen Ort oder in der falschen Richtung
- Warum teuer: Policy ist „da“, wirkt aber nicht am Engpass; Troubleshooting dauert ewig.
- Typisches Symptom: Konfig sieht korrekt aus, aber Classify-Hits/Queue-Werte sind irrelevant, QoE bleibt schlecht.
- Quick Fix: Engpass lokalisieren; QoS primär am Egress des Engpass-Interfaces umsetzen.
Stolperfalle 4: DSCP↔CoS↔MPLS-TC Mapping-Drift
- Warum teuer: Ein Segment behandelt EF/AF anders; Quality ist standortabhängig und schwer erklärbar.
- Typisches Symptom: DSCP-Verteilung ändert sich an Übergängen, Classify-Hits fehlen in einzelnen Domänen.
- Quick Fix: zentrale Mappingtabellen, Templates pro Netzrolle, regelmäßige Compliance-Checks.
Stolperfalle 5: IPv6 wird vergessen (Dual-Stack QoS-Lücke)
- Warum teuer: Kundenqualität driftet je nach Protokoll; „sporadische“ Probleme sind schwer reproduzierbar.
- Typisches Symptom: IPv4 stabil, IPv6 knackt/ruckelt; Classify-Hits nur für IPv4.
- Quick Fix: IPv6 Traffic Class gleichwertig behandeln, Policies und Mappings paritätisch pflegen.
Stolperfalle 6: Tunnel/Overlay verliert Markierungen (Inner/Outer falsch)
- Warum teuer: Underlay queued Best Effort, obwohl Inner-DSCP korrekt ist; Echtzeit leidet über VPN/SD-WAN.
- Typisches Symptom: QoE schlecht nur „im Tunnel“, Outer-DSCP/TC zeigt BE-Verhalten.
- Quick Fix: Outer-DSCP/TC kontrolliert mappen, Trust Boundary beibehalten, MTU/Overhead berücksichtigen.
Stolperfalle 7: Policer auf Echtzeit (Voice/Video) als Standard
- Warum teuer: harte Drops erzeugen Knacken/Freezes; Beschwerden steigen sofort.
- Typisches Symptom: Policer-Drops in Premiumklassen, Drop-Cluster bei Video-Bursts.
- Quick Fix: Shaping statt Policing, Überschuss remarken, Burstfenster realistisch dimensionieren.
Stolperfalle 8: Burst-Parameter zu klein (Token Bucket „zu eng“)
- Warum teuer: Microbursts werden unnötig gedroppt; QoE kippt trotz ausreichender Durchschnittskapazität.
- Typisches Symptom: kurze Drop-Cluster, obwohl Links nicht voll wirken; Video-Keyframes triggern Drops.
- Quick Fix: Burstfenster erhöhen, Shaping vor harte Policers setzen, Perzentile messen.
Stolperfalle 9: Shaping fehlt an rate-limitierten Übergängen (Bufferbloat)
- Warum teuer: Latenz/Jitter explodieren ohne Drops; Probleme sind schwer „sichtbar“ und dauern lange.
- Typisches Symptom: MOS fällt, Jitter steigt, aber Drops sind niedrig; Queueing Delay Peaks hoch.
- Quick Fix: Egress-Shaping knapp unter Linkrate/Profil, kontrollierte Queue-Limits.
Stolperfalle 10: Queue-Limits „nach Gefühl“ (zu groß oder zu klein)
- Warum teuer: zu groß → Bufferbloat; zu klein → Tail Drops und Cluster-Loss.
- Typisches Symptom: entweder hohe Delay-Perzentile ohne Drops oder Drop-Cluster bei Bursts.
- Quick Fix: Queue-Limits in Millisekunden budgetieren, pro Klasse unterschiedliche Ziele.
Stolperfalle 11: WRED/Drop-Strategie falsch eingesetzt
- Warum teuer: falsche Drop-Charakteristik erzeugt Durchsatzwellen oder schadet Video unnötig.
- Typisches Symptom: Video pendelt stark, BE throughput instabil, Drops treten „ungünstig“ auf.
- Quick Fix: Drop-Strategien auf Traffictyp abstimmen; Echtzeit nicht über aggressive Random Drops „bestrafen“.
Stolperfalle 12: Premium- und Best-Effort-Budgets nicht plausibilisiert
- Warum teuer: Klassenanteile passen nicht zum realen Trafficmix; Busy Hour eskaliert.
- Typisches Symptom: Video verhungert oder BE erzeugt Dauerstau; Premium wirkt instabil.
- Quick Fix: Budgets anhand realer Telemetrie (Traffic pro Klasse, Perzentile) iterativ anpassen.
Stolperfalle 13: ECMP/LAG Hotspots ignorieren (Lastverteilung ungleich)
- Warum teuer: einzelne Member-Links droppen, obwohl Gesamtbündel Headroom hat; sporadische QoE-Probleme.
- Typisches Symptom: Drops/Queueing Peaks nur auf einem LAG-Member, „sporadisch“ nach Hashing-Events.
- Quick Fix: per-member Telemetrie, Hashing/Entropy optimieren, Pfade qualitativ angleichen.
Stolperfalle 14: Failover-/FRR-Pfade nicht QoS-semantisch gleichwertig
- Warum teuer: Umschalten verursacht Knacken/Freezes; Kunden merken Ausfälle „als Qualitätseinbruch“.
- Typisches Symptom: QoE schlecht nur bei Link-Events; DSCP/TC-Mapping im Backup-Pfad abweichend.
- Quick Fix: Backup-Pfade verifizieren, N+1 Kapazität prüfen, Shaping gegen Umschaltbursts.
Stolperfalle 15: Reversion/Flapping in Ringnetzen unterschätzt
- Warum teuer: mehrfaches Umschalten erzeugt wiederholt Microbursts und Delay-Sprünge; Echtzeit leidet dauerhaft.
- Typisches Symptom: kurze, wiederholte QoE-Einbrüche; Schutzschaltungen korrelieren mit Jitterpeaks.
- Quick Fix: Stabilitäts-Timer, non-revertive oder verzögerte Reversion, Event-Korrelation im Monitoring.
Stolperfalle 16: Peering/Interconnect als „Best Effort Zone“ ohne Kapazitätsdisziplin
- Warum teuer: Abendliche Congestion führt zu massenhaft Tickets; QoS kann Peering-Überlast nicht ersetzen.
- Typisches Symptom: QoE schlecht nur zu bestimmten Zielen; Port-Auslastung 95/99 hoch; Drops am NNI.
- Quick Fix: Headroom planen, Perzentile monitoren, ggf. mehrere Exits/Peering-Standorte.
Stolperfalle 17: „QoS wirkt nicht“ – weil Messung falsch ist
- Warum teuer: falsche Diagnosen führen zu falschen Änderungen; Change-Churn erzeugt neue Incidents.
- Typisches Symptom: nur RTT/Ping betrachtet, keine Klassenprobes, keine Queueing Delay Perzentile.
- Quick Fix: active Probes pro Klasse, Sekundenfenster, Perzentile, Queue-/Policer-Telemetrie.
Stolperfalle 18: Abnahme nur Off-Peak, keine Busy-Hour- oder Bursttests
- Warum teuer: Rollout wirkt „grün“, kippt im Peak; Rollback im Krisenmodus.
- Typisches Symptom: Probleme treten erst Stunden später auf; vor dem Change alles „ok“.
- Quick Fix: Abnahmeplan mit Lastmustern, Microburst-Tests, Busy-Hour-Verifikation und Failover-Test.
Stolperfalle 19: Templates ohne Governance (QoS-Drift durch Hotfixes)
- Warum teuer: Netz wird inkonsistent; Qualität wird standortabhängig; Troubleshooting explodiert.
- Typisches Symptom: gleiche Rolle, unterschiedliche Queue-Parameter; plötzliches Verhalten nach Updates/Hotfixes.
- Quick Fix: versionierte Golden Templates, Compliance-Checks, Ausnahmeprozess, Drift-Dashboards.
Stolperfalle 20: QoS als Ersatz für Kapazitätsplanung verwenden
- Warum teuer: Engpässe bleiben dauerhaft aktiv; QoS verteilt nur den Schmerz; SLAs werden instabil.
- Typisches Symptom: Premiumklassen arbeiten ständig am Limit, BE Dauerstau, wiederkehrende Peak-Incidents.
- Quick Fix: Kapazität/Headroom planen (Perzentile), TE/Pfadwahl optimieren, Overbooking-Grenzen operationalisieren.
So nutzen Sie die Top 20 als sofortiges Audit-Framework
- Schritt 1: Starten Sie bei den „harten“ No-Go-Signalen: EF-Drops, Policer-Drops auf Echtzeit, fehlendes Shaping am Engpass.
- Schritt 2: Prüfen Sie Mapping-Kohärenz (DSCP↔CoS↔TC, IPv6, Tunnel Outer/Inner) an allen Domänenübergängen.
- Schritt 3: Validieren Sie, dass die Messung stimmt: Klassenprobes, Perzentile, Sekundenfenster, Telemetrie pro Klasse.
- Schritt 4: Koppeln Sie QoS mit Kapazitätsdisziplin: Hotspots, Interconnect-Headroom, Failover-Kapazität.
Häufige Fragen aus der Praxis
Welche drei Fehler sind am häufigsten und am teuersten?
- Fehlende Trust Boundary (Premium-Inflation) kombiniert mit zu großer oder unlimitierter LLQ.
- Fehlendes Shaping an rate-limitierten Übergängen (Bufferbloat und Jitterpeaks).
- Mapping-Drift über Domänenübergänge (DSCP↔CoS↔TC) inklusive IPv6/Tunnel-Outer-Header.
Was ist das schnellste Signal, dass QoS gerade Geld verbrennt?
EF/Voice-Drops, steigende Queueing Delay 99.-Perzentile in Voice/Control oder ein plötzlich unplausibler Anstieg des EF-Volumens. Diese drei Signale korrelieren sehr stark mit hörbaren Problemen und steigenden Ticketzahlen.
Wie verhindere ich, dass wir bei jedem QoS-Problem „an den Gewichten drehen“?
Indem Sie Ursachen-orientiert arbeiten: Erst Markierung und Classify-Hits verifizieren, dann Queueing Delay/Drops pro Klasse prüfen, dann Policer/Shaper Events auswerten, und erst danach Gewichte anpassen. Zusätzlich hilft ein standardisierter Abnahme- und Change-Prozess, damit Änderungen nicht im Blindflug passieren.
