Das Blueprint „Metro QoS“ beschreibt, wie Sie in Metro-Netzen – typischerweise ringbasierten Transport- und Aggregationsdomänen zwischen Access, regionalen PoPs und Core – Quality of Service so designen, dass Echtzeitdienste stabil bleiben und Engpässe kontrolliert behandelt werden. Metro-Ringe sind in der Praxis der Ort, an dem viele „lokale“ Access-Ströme zusammenlaufen: Business-Standorte, Mobile Backhaul, Edge Clouds, öffentliche Einrichtungen, SIP/IMS-Edges oder Video-Distribution. Gerade weil Metro-Domänen oft hochverfügbar ausgelegt sind (Ring Protection, Fast Reroute, Dual-Homing), neigt man dazu, QoS als nachrangig zu behandeln: „Der Ring hat genug Bandbreite.“ In Wirklichkeit entstehen Degradationen häufig genau hier – nicht unbedingt durch dauerhafte Auslastung, sondern durch Microbursts, ungleichmäßige Traffic-Verteilung nach Schutzumschaltungen, falsche Shaping Points, inkonsistentes DSCP/CoS-Mapping oder Queueing in den falschen Geräten. Ein Metro QoS Blueprint setzt deshalb auf drei Kernelemente: ein ringtaugliches Congestion-Domain-Modell, bewusst platzierte Shaping Points (damit Congestion in kontrollierten Queues passiert) und ein konsistentes Queueing-/Klassenschema, das Multi-Vendor und Interconnects übersteht. Dieser Artikel zeigt die wichtigsten Designmuster für Ring-Design, Shaping und Queueing in Metro-Netzen – inklusive operativer Messpunkte, mit denen Sie „Metro QoS“ nachweisen können.
Was Metro-Netze besonders macht: Aggregation, Schutzumschaltung und Burstiness
Metro-Domänen unterscheiden sich von Campus- oder reinen Backbone-Netzen durch ihren Mix aus Aggregation und Nähe zum Access. Viele Quellen senden gleichzeitig in Richtung weniger Sammelpunkte. Dadurch entstehen Microbursts, die selbst bei moderaten Durchschnittsraten zu Queue-Spikes führen. Zusätzlich verändert Schutzumschaltung die Traffic-Verteilung: Wenn ein Ringsegment ausfällt, fließt Verkehr plötzlich über andere Links, und zuvor unkritische Abschnitte werden Engpässe. Metro QoS muss diese Dynamik berücksichtigen: QoS darf nicht nur im „Normalbetrieb“ funktionieren, sondern auch im Schutzfall.
- Aggregation: viele Access-Links bündeln sich auf wenige Ringsegmente oder PoP-Uplinks.
- Ring Protection: Umschaltungen verändern Pfade, Linkauslastungen und Engpassorte.
- Microbursts: synchrone Senderereignisse, TCP-Bursts und Encapsulation erzeugen Peak Queue Depth.
- Multi-Service: Voice/Video/Backhaul/Business-Data teilen dieselbe Metro-Infrastruktur.
Congestion Domains im Metro: Wo QoS wirklich wirken muss
Ein Metro QoS Blueprint beginnt nicht mit Klassen, sondern mit Congestion Domains. In vielen Metro-Designs sind Links im Core-Ring hochdimensioniert, aber Engpässe entstehen an anderen Stellen: an Access-Aggregationsknoten, an PoP-Uplinks in Richtung Core/DC, an Übergängen zu Provider-Services oder an Rate-Limited Customer Hand-offs. Die wichtigste Frage lautet: Wo entsteht Queueing tatsächlich? QoS muss dort sitzen, wo die Ressource knapp wird – und zwar in der richtigen Richtung (meist egress).
- PoP-Uplinks: Übergang Metro → Core/DC ist häufig die zentrale Congestion Domain.
- Aggregation Nodes: viele Access-Ports auf wenige Ringports; Burstiness macht Queueing sichtbar.
- Customer/Partner Hand-offs: CIR/PIR-policed Übergaben erzeugen Drops, wenn Sie nicht vorgelagert shapen.
- Reroute-Szenarien: Schutzfall kann neue Congestion Domains erzeugen; diese müssen im Design mitgedacht werden.
Ring-Design und QoS: Warum Topologie die Queue-Strategie bestimmt
Im Ring sind Pfade oft bidirektional, und Traffic kann je nach Schutzmechanismus auf die „andere Seite“ wechseln. Das hat direkte QoS-Konsequenzen: Ein Shaper, der nur auf einem Pfad wirkt, kann im Failover-Fall plötzlich wirkungslos sein. Ebenso kann ein Queue-Profil, das auf einem Ringsegment ausreichend ist, nach Reroute zu klein werden. Ein Metro QoS Blueprint behandelt QoS deshalb als Bestandteil des Resilienzdesigns: Jede kritische Klasse muss im Normal- und Schutzfall eine konsistente Behandlung erhalten.
- Symmetrische Policies: QoS-Policies und Shaping Points so setzen, dass beide Ringrichtungen abgedeckt sind.
- Failure-Mode Dimensionierung: Klassenreserven und Queue-Profile auch für Schutzbetrieb planen.
- Path Consistency: DSCP/CoS-Mapping und Queue-Interpretation dürfen sich beim Pfadwechsel nicht ändern.
Shaping Points: Der wichtigste Hebel für kontrolliertes Metro-Queueing
In Metro-Netzen ist Shaping oft der entscheidende Unterschied zwischen „QoS wirkt“ und „QoS sieht nur gut aus“. Viele Übergänge sind rate-limited: Kunden-CIRs, Wholesale-Profile, Hand-offs zu anderen Domänen oder DC/Cloud-Onramps. Wenn Sie erst nach dem Policer ansetzen, entstehen Drops oder Delay außerhalb Ihrer Kontrolle. Der Blueprint setzt deshalb auf bewusst platzierte Shaping Points: Sie shapen knapp unter der Rate des nächsten Engpasses, damit Congestion in Ihren kontrollierten Queues entsteht und Echtzeitklassen geschützt bleiben.
- Pre-Policer Shaping: vor rate-limited Übergaben shapen, um Policer Drops zu vermeiden.
- PoP-Egress Shaping: Metro→Core/DC Übergänge shapen, um Peak Queueing zu kontrollieren.
- Per-Service Shaping: bei Multi-Service-Aggregation hierarchisch shapen (Service-/Slice-/VRF-Level).
- Schutzfall-Headroom: Shaper-Werte so wählen, dass sie auch bei Reroute nicht sofort in Overlimit laufen.
HQoS im Metro: Hierarchien für Fairness und Isolation
Metro-Domänen tragen häufig mehrere „Kunden“ oder logische Services: Enterprise-VRFs, Mobile Backhaul, 5G Slices, öffentliche Dienste, IPTV, interne Management-Traffic. Ein flacher Scheduler kann hier schnell unfair werden: Ein lauter Service verdrängt andere. HQoS löst das, indem es oben eine Gesamtbegrenzung pro Service (oder pro Übergabe) definiert und darunter die Klassen priorisiert. So erreichen Sie sowohl Isolation (ein Service kann nicht alles dominieren) als auch echte Echtzeitschutzklassen innerhalb jedes Service.
- Service-Level Shaper: begrenzt Gesamttraffic pro VRF/Slice/Kunde.
- Class-Level Scheduling: Voice/Low-Latency vor Media vor Daten, mit klaren Limits.
- Guardrails: keine unlimitierten Priority-Queues, Policers in Echtzeitklassen vermeiden.
Queueing-Blueprint: Klassen, die Metro-tauglich sind
Ein Metro-Queueing-Schema muss zwei Dinge können: Es muss genügend Granularität bieten, um Echtzeit zu schützen, und es muss über Vendoren, Domänen und Interconnects hinweg konsistent bleiben. Ein bewährtes Schema arbeitet mit wenigen, klaren Klassen: Low-Latency/Voice, Media/Video, Control/Signal, Business-Critical Data, Best Effort und Bulk/Background. Wichtig ist, dass diese Klassen in DSCP/CoS/MPLS-TC sauber abgebildet sind und dass Mapping-Tabellen zentral verwaltet werden.
- LOW_LATENCY/VOICE: streng priorisiert, begrenzt, kleine Buffers für niedrigen Delay.
- MEDIA: hohe Priorität, aber limitiert; schützt Video ohne Voice zu verdrängen.
- SIGNAL/CONTROL: stabil für Signalisierung und Steuerung, damit Services auch unter Last funktionieren.
- CRITICAL: wichtige Daten, bevorzugt, aber nicht strict.
- BESTEFFORT: Standardverkehr.
- BULK: gedrosselt, „opferbar“ unter Congestion.
Marking und Interworking: DSCP, CoS und MPLS TC in Metro-Domänen
Metro-Netze sind häufig Mischdomänen: Ethernet-Access, MPLS/SR im Core, VLAN CoS an Übergaben, DSCP im IP-Teil, ggf. Segment Routing Policies und EVPN. QoS scheitert hier oft an Interworking: Ein DSCP-Wert wird auf dem ersten Gerät korrekt klassifiziert, aber in der MPLS-Domäne in eine falsche TC gemappt oder am Ethernet-Hand-off zurückgesetzt. Ein Metro QoS Blueprint fordert deshalb eine zentrale Mapping-Matrix und klare Trust Boundaries an Übergängen: Markierungen werden nur dort trusted, wo sie kontrolliert sind, und sonst normalisiert.
- Mapping-Matrix: DSCP ↔ CoS ↔ MPLS TC als Source of Truth.
- Trust Boundary: Whitelist-Markierungen, Re-Marking an Übergaben statt blindem Trust.
- Interop-Checks: regelmäßige Prüfung, dass DSCP/TC in allen Domänen die gleiche Queue-Semantik hat.
Schutzumschaltung und QoS: Was im Failure-Mode geprüft werden muss
Metro-QoS ist erst dann „richtig“, wenn es auch im Schutzfall funktioniert. Das bedeutet: Sie müssen testen, ob bei Reroute die gleichen Klassen weiterhin geschützt sind, ob Shaping Points weiterhin „vor“ dem Engpass liegen, und ob die neue Pfadseite nicht in einen Policer läuft. In der Praxis sind Failure-Mode-Tests ein häufiger Blind Spot, weil sie operativ aufwendig wirken. Ein Blueprint reduziert dieses Risiko, indem er standardisierte Failure-Mode-Checks definiert: definierte Testfenster, synthetische Probes, Queue- und Drop-Metriken pro Ringrichtung.
- Reroute Test: kontrollierte Umschaltung (oder Simulation) und Beobachtung der QoS-KPIs.
- Guardrails: Voice Queue Delay 99p und Voice Drops dürfen nicht steigen.
- Shaper Validierung: Headroom und Backlog prüfen, ob Congestion weiterhin kontrolliert ist.
Monitoring in Metro QoS: Welche Panels NOC-Teams brauchen
Metro-Netze sind groß, daher muss Monitoring hochsignalig sein. Linkauslastung allein reicht nicht, weil Microbursts und Queueing-Spitzen entscheidend sind. Ein Metro QoS Blueprint setzt auf wenige Kernpanels, die pro Congestion Domain standardisiert werden: Queue Delay/Depth (Perzentile), Per-Class Drops, Drop Reasons, Shaper-Headroom und Class Utilization. Ergänzend sind Top-Offender-Ansichten hilfreich: Welche Ringsegmente, PoPs oder Übergaben verursachen die meisten Delay-Spitzen?
- Queue Delay 95p/99p: für LOW_LATENCY/VOICE und MEDIA an Shaping Points und PoP-Uplinks.
- Peak Queue Depth: Microburst-Indikator im Ring und an Aggregation.
- Per-Class Drops: Voice/Media Drops als Incident-Signal, BE/Bulk Drops als Kontext.
- Drop Reasons: Tail Drop vs. Policer vs. Buffer Exhaustion als Root-Cause-Hinweis.
- Shaper Headroom: zeigt dauerhafte Sättigung und Capacity-Risiken.
Typische Metro-QoS-Fallstricke und schnelle Gegenmaßnahmen
- QoS „wirkt nicht“: Congestion findet im Provider-Policer statt; pre-police shapen und Mapping prüfen.
- Voice schlecht bei Reroute: Policies nur auf einer Ringrichtung oder falsche Failure-Mode-Dimensionierung; symmetrische QoS und Schutzfall-Headroom.
- Microburst-Drops trotz niedriger Auslastung: Peak Queue Depth hoch, Buffer Exhaustion; Buffer-/Queue-Profile anpassen, Burstiness reduzieren.
- Klassen-Drift: DSCP/CoS/MPLS-TC inkonsistent; zentrale Mapping-Matrix und Compliance-Checks.
- Policer trifft Echtzeit: Policer Drops in Voice/Media; Policer entschärfen, Shaping nutzen, Premiumlimits korrekt setzen.
Validation und Rollout: Metro QoS als lifecyclefähiges Blueprint
Ein Metro-Blueprint ist nur dann nachhaltig, wenn es getestet und progressiv ausgerollt wird. Für Metro QoS sind Regression Tests besonders wichtig: Sie beweisen, dass Änderungen an Mapping, Queue-Profilen oder Shaping Points nicht zu regressiven Echtzeitproblemen führen. Canary-Rollouts sind auch im Metro sinnvoll: erst einzelne Ringe oder PoPs, dann Wellen. Guardrails sollten strikt sein, weil Metro-Änderungen große Blast Radii haben können.
- Regression Suite: Voice-like Probe + Congestion-Proof + Mapping/Attachment Checks.
- Canary Rollout: einzelne Ringsegmente/PoPs, danach progressive Ausweitung.
- Rollback: versionierte Policies, atomarer Switch auf Vorversion.
- Evidence Packs: Config Exports + Counter Reports + Telemetry-Auszüge für Audit und Providerdialog.
Pragmatische Metro QoS Checkliste: Ring-Design, Shaping Points und Queueing
- Congestion Domains: PoP-Uplinks, Aggregation Nodes, rate-limited Hand-offs und Schutzfallpfade identifizieren.
- Shaping Points: vor Engpässen shapen (pre-police), Realrate berücksichtigen, Schutzfall-Headroom einplanen.
- HQoS: Service-Level Shaping + Class-Level Scheduling für Isolation und Fairness.
- Klassenmodell: LOW_LATENCY/VOICE, MEDIA, SIGNAL, CRITICAL, BE, BULK – konsistent über Domänen.
- Interworking: DSCP ↔ CoS ↔ MPLS TC Mapping zentral verwalten; Trust Boundaries und Re-Marking definieren.
- Monitoring: Queue Delay/Depth (Perzentile), Per-Class Drops, Drop Reasons, Shaper-Headroom als Standardpanels.
- Failure-Mode Tests: Reroute-Validierung mit Guardrails für Voice/Media.
- Lifecycle: Regression, Canary, Rollback und Compliance Audits als fester Bestandteil des Betriebs.
