Hierarchical QoS (HQoS) ist im Carrier- und Telco-Betrieb eines der wichtigsten Designmuster, weil es zwei Kernprobleme gleichzeitig löst: Erstens bringt es Congestion an einen kontrollierbaren Ort (Access Shaping), und zweitens verteilt es innerhalb dieser kontrollierten Rate die Ressourcen sauber auf Service Queues (Voice, Video, Business, Best Effort, Bulk). Genau diese Kombination ist in der Praxis der Unterschied zwischen „QoS ist konfiguriert“ und „QoS liefert stabil messbare Qualität“. Ohne Shaping liegt die Warteschlange oft beim Provider, im CPE, in einem Access-Modem oder in einem Black-Box-Segment, und Ihre priorisierten Queues greifen nur eingeschränkt. Ohne Service Queues kann Shaping zwar Bursts glätten, aber Echtzeitverkehr wird weiterhin von Bulk-Transfers verdrängt. HQoS verbindet beide Ebenen: Ein Parent-Shaper begrenzt die Gesamtrate (pro Anschluss, pro Service, pro Kunde oder pro Tunnel), während darunter Child-Policies echte Klassenbehandlung umsetzen – meist mit limitierter Priority Queue für Voice, gewichteten Queues für Video/Business und AQM/ECN für Best Effort. Damit wird Access nicht nur „schnell“, sondern planbar: Latenzspitzen sinken, Jitter wird kontrollierbar, Drop-Bursts werden seltener, und Noisy-Neighbor-Effekte lassen sich auch in Multi-Tenant-Umgebungen zuverlässig verhindern.
Warum HQoS im Access so gut funktioniert: Engpasskontrolle statt Hoffnung
Access-Links sind die natürliche Congestion Domain: letzte Meile, Uplink zum BNG/PE, Metro-Aggregation oder Shared Medium (PON/DOCSIS). In all diesen Fällen ist die verfügbare Rate entweder begrenzt, variabel oder mit vielen Teilnehmern geteilt. Klassische QoS-Ansätze scheitern hier häufig aus einem einfachen Grund: Die entscheidende Queue liegt nicht dort, wo Ihre QoS-Policy aktiv ist. Wenn die Warteschlange beim Provider oder im CPE-Modem entsteht, wird Voice zwar markiert, aber nicht unbedingt priorisiert. HQoS löst das, indem es Congestion in den eigenen Einflussbereich zieht (durch Shaping) und dann innerhalb dieser kontrollierten Warteschlange konsequent priorisiert (durch Service Queues).
- Queue-Lage: HQoS sorgt dafür, dass die kritische Warteschlange am eigenen Gerät entsteht.
- Reproduzierbarkeit: gleiche Last erzeugt gleiches Verhalten, weil Scheduling lokal ist.
- Skalierbarkeit: per Subscriber/Service/Kunde lassen sich Profile standardisieren und automatisieren.
- SLA-Fähigkeit: Queue-Delay und Drops sind messbar und domänenscharf zuordenbar.
HQoS in einem Bild: Parent formt, Child priorisiert
Hierarchisches QoS besteht aus mindestens zwei Ebenen. Der Parent ist typischerweise ein Shaper: Er setzt eine Obergrenze für die Abflussrate und puffert Bursts. Unter diesem Parent hängt eine oder mehrere Child-Policies, die den Traffic in Klassen einteilen und pro Klasse Scheduling und Drop-Verhalten definieren. In vielen Provider-Designs ist diese Hierarchie pro Subscriber, pro EVC, pro VRF oder pro Tunnel realisiert. Der Parent stellt sicher, dass die Gesamtrate dem Produktprofil entspricht (z. B. 100 Mbit/s), die Child-Queues stellen sicher, dass Voice auch bei Upload-Backups noch sauber durchkommt.
- Parent (Shaper): kontrolliert Gesamtbandbreite und Burstiness, verhindert Black-Box-Queueing.
- Child (Service Queues): verteilt Ressourcen auf Klassen (Voice, Video, Business, BE, Bulk).
- Optionaler Grandparent: in Aggregation-Szenarien zusätzlich ein Gesamtshaper für ein Interface oder Link-Bundle.
Access Shaping: Warum „ein bisschen darunter“ nicht trivial ist
Access Shaping ist nicht einfach „Rate = Vertragsrate“. In der Praxis müssen Sie die tatsächlich nutzbare Rate treffen. Dazu gehören Layer-2-Overhead (z. B. VLAN/QinQ), Encapsulation (z. B. IPsec/GRE/VXLAN), Provider-Policer-Verhalten und bei Shared Medium sogar variable Kapazität. Wird zu hoch geshaped, wandert die Congestion wieder in den Provider oder ins Modem – Ihre Service Queues verlieren Wirkung. Wird zu niedrig geshaped, verschenken Sie Kapazität und erzeugen unnötige eigene Congestion. Ein gutes HQoS-Design nutzt daher eine konservative, messgetriebene Shaper-Rate und validiert sie über Queue-Delay, Drops und Utilization-Perzentile.
- Overhead einrechnen: effektive Nutzrate ist kleiner als Linkrate, besonders bei Tunneln.
- Upstream priorisieren: Upload ist häufig der echte Echtzeit-Schmerzpunkt; Shaping dort besonders wichtig.
- Failover-Headroom: Backup-Pfade sind oft enger; Shaper-Profile müssen Worst Case abdecken.
- Messbasierte Kalibrierung: Queue-Delay p95/p99 und Drops zeigen, ob der Shaper „richtig sitzt“.
Service Queues: Wie Sie innerhalb des Shapers Voice & Video stabil halten
Die Child-Policy ist das eigentliche QoS: Hier werden Klassen definiert und Scheduling festgelegt. Für Echtzeit ist ein bewährtes Muster: Voice in eine limitierte Priority Queue (LLQ), Video in eine gewichtete Echtzeitklasse, Business in eine bevorzugte Klasse, Best Effort mit AQM/ECN gegen Bufferbloat, Bulk/Scavenger nachrangig. Der entscheidende Punkt im HQoS-Kontext: Die Budgets beziehen sich auf die Parent-Rate, nicht auf die physische Linkrate. Wer hier falsch rechnet, bekommt entweder Starvation (LLQ zu groß) oder Voice-Drops (LLQ zu knapp).
- Voice (LLQ): strikt priorisiert, aber strikt limitiert, kurze Queue-Limits gegen Jitter.
- Video/Interactive: gewichtete Klasse mit Mindestanteil; Video nicht in die LLQ.
- Business Critical: bevorzugt, aber fair; stabilisiert SaaS/VDI/Transaktionen.
- Best Effort: AQM/ECN zur Latenzstabilisierung, statt „große Buffers“.
- Bulk/Scavenger: bewusst nachrangig, damit Backups/Updates Echtzeit nicht verdrängen.
Warum HQoS Noisy Neighbors verhindert: Per-Subscriber und Per-Service Fairness
In Access- und Aggregationsnetzen ist Noisy Neighbor ein Dauerproblem: Ein Teilnehmer oder ein Service erzeugt Bursts, die andere verdrängen. HQoS adressiert das strukturell, weil der Parent pro Subscriber/Service die Gesamtrate begrenzt. Ein Teilnehmer kann dann nicht mehr „das ganze Interface“ füllen, sondern nur sein Profil. Innerhalb dieses Profils sorgt die Child-Policy dafür, dass der Teilnehmer seine eigenen Klassen sinnvoll priorisiert. In Provider-Designs ist das besonders wertvoll, weil es betriebliche Konflikte reduziert: SLA-Verletzungen lassen sich domänenscharf auf ein Profil und eine Congestion Domain zurückführen.
- Per-Subscriber Shaping: verhindert, dass einzelne Teilnehmer Aggregationsressourcen dominieren.
- Per-EVC/VRF Shaping: Business-Services bekommen planbare Profile, unabhängig von anderen Services.
- Multi-Service Interfaces: mehrere Profile auf einem Port werden konsistent steuerbar.
HQoS und Policing: Wann degradieren besser ist als droppen
HQoS wird oft mit Policing kombiniert, insbesondere an Trust Boundaries oder zur Durchsetzung von Produktprofilen. Policing ist jedoch für Echtzeit gefährlich, weil es Drops erzeugt. In HQoS-Designs ist deshalb häufig eine „degrade statt drop“-Strategie sinnvoll: Überschreitungen in Premiumklassen (z. B. zu viel EF) werden in eine niedrigere Klasse ummarkiert, statt in der Echtzeitklasse hart verworfen zu werden. Der Parent-Shaper stabilisiert die Gesamtrate, die Child-Queues schützen echte Echtzeit, und Policer verhindern Missbrauch – ohne dass Voice sofort hörbar leidet.
- Ingress Enforcement: Missmarking erkennen und normalisieren, bevor es Premium-Queues flutet.
- Degradation: Überschreitungen ummarkieren, damit LLQ stabil bleibt.
- Drop als letzte Option: nur bei klaren Missbrauchsszenarien oder harten SLA-Grenzen.
Bufferbloat im HQoS: Warum Queue-Limits und AQM dazugehören
Ein häufiger Fehler ist, HQoS nur als „Shaper + Queues“ zu verstehen und die Pufferdimensionierung zu ignorieren. Wenn Best Effort eine riesige Queue hat, kann sie trotz Shaping Latenzspitzen erzeugen, die interaktive Anwendungen quälen. Wenn die Voice-Queue zu groß ist, steigt Jitter trotz Priorität. Deshalb gehört zu HQoS immer auch eine Buffer-Strategie: kurze Queue-Limits für Echtzeit, moderate Limits für Video/Business und AQM/ECN für Best Effort, um Congestion früh und kontrolliert zu signalisieren.
- Echtzeitqueues kurz: minimiert Jitter und verhindert „versteckte“ Delay-Spitzen.
- Best Effort mit AQM/ECN: reduziert RTT-Spitzen unter Mischlast.
- Short-interval Monitoring: Mikrobursts zeigen sich in p95/p99, nicht im Mittelwert.
Typische HQoS-Topologien: Access, Aggregation und Tunnel
HQoS ist nicht auf einen Gerätetyp beschränkt. Es taucht überall dort auf, wo Sie (1) Profile durchsetzen und (2) innerhalb der Profile Servicequalität priorisieren müssen. Typische Szenarien sind: Broadband/BNG mit Per-Subscriber Shaping, Business-Services auf Ethernet-Access (EVC) mit per Service Shaper, Mobile Backhaul per Site-Profil, SD-WAN/IPsec-Edges pro Tunnelprofil, oder EVPN/VXLAN-Borders mit Service-Budgets. Die Prinzipien bleiben gleich, aber die Engpässe unterscheiden sich: Im Tunnelkontext müssen Sie Overhead und Outer Header Marking berücksichtigen, im Metro-Kontext Failover-Pfade und Ring-Congestion Domains.
- Broadband: per Subscriber Shaping + Child-Queues schützt Voice/Video im Upstream.
- Business Ethernet: per EVC/VRF Shaping + Serviceklassen für SLA-taugliche Produkte.
- IPsec/SD-WAN: per Tunnel Shaping, Outer DSCP korrekt setzen, dann Klassen im Child.
- Metro-Ringe: HQoS hilft, Services fair zu halten, auch nach Switchover.
Fehlerbilder: Wenn HQoS zwar konfiguriert ist, aber nicht wirkt
Viele HQoS-Probleme folgen wiederkehrenden Mustern. Häufig ist der Parent zu hoch (Queue liegt beim Provider), die LLQ zu groß (Starvation), die LLQ zu klein (Voice-Drops), oder Overhead wurde ignoriert (Policer greift zu früh). Ebenso häufig ist Drift: Templates sind nicht konsistent über Geräte/Linecards ausgerollt, sodass die gleiche Klasse an verschiedenen Stellen anders behandelt wird. Ein stabiles HQoS-Design braucht deshalb klare Profile pro Linkrolle und eine Rezertifizierung im Betrieb.
- Congestion außerhalb: Shaper zu hoch → Drops beim Provider, HQoS scheinbar „wirkungslos“.
- Starvation: LLQ zu groß oder Missmarking → andere Klassen verhungern.
- Voice-Drops: LLQ zu knapp oder Overhead nicht eingerechnet.
- Bufferbloat: Queue-Limits/AQM fehlen → hohe Delay-Perzentile trotz ausreichend Bandbreite.
- Drift: unterschiedliche Geräte interpretieren Klassen verschieden → QoS-Löcher.
Messbarkeit: HQoS ohne Queue- und Shaper-Telemetrie ist nicht betreibbar
HQoS lässt sich hervorragend messen – wenn Sie die richtigen KPIs betrachten. Für den Parent sind Shaper-Auslastung, Shaper-Drops (falls vorhanden) und Queue-Delay relevant. Für die Child-Queues sind Queue-Delay und Drops pro Klasse entscheidend, ergänzt um Marking-Integrität (DSCP/TC-Verteilung) und Policer-/Remarking-Zähler an Trust Boundaries. Besonders wichtig sind Perzentile (p95/p99) in kurzen Zeitfenstern, weil HQoS-Probleme oft in Peak-Minuten auftreten: Mikrobursts, Backup-Starts, große Uploads oder Failover.
- Parent Health: Shaper-Rate vs. tatsächliche Auslastung, Queue-Delay, Bursts.
- Child Health: Delay/Drops pro Klasse, besonders Voice und Control.
- Marking Integrity: Klassenverteilungen zeigen Missmarking und Policy-Fehler.
- Event-Korrelation: Failover/Maintenance mit HQoS-KPIs verknüpfen.
Blueprint: HQoS als wiederholbares Access-Design
Ein robustes HQoS-Design beginnt mit einem schlanken Klassenmodell (Network Control, Voice, Video/Interactive, Business, Best Effort, Bulk). Danach definieren Sie Profile: Parent-Shaper pro Subscriber/Service/Tunnel knapp unter der realen nutzbaren Rate (inklusive Overhead und Headroom). Unter dem Parent implementieren Sie Child-Queues: Voice als limitierte Priority Queue, Video/Business als gewichtete Klassen, Best Effort mit AQM/ECN, Bulk nachrangig. Trust Boundaries sorgen dafür, dass nur erlaubte Markings in Premiumklassen gelangen, und Policer/Degradation verhindern Missbrauch, ohne Voice durch harte Drops zu zerstören. Abschließend etablieren Sie Telemetrie: Shaper- und Queue-Health, Delay/Drops p95/p99, Marking-Verteilungen und Event-Korrelation. So kombinieren Sie Access Shaping und Service Queues nicht als „Konfigurationsdetail“, sondern als Carrier-Grade Muster, das auch unter Mikrobursts, Busy Hour und Failover reproduzierbar Voice und andere kritische Dienste schützt.
