QoS im Core wird in vielen Telco- und Carrier-Designs nach dem Motto „Core is uncongested“ behandelt: Der Backbone ist hochkapazitiv, stark redundant und so dimensioniert, dass Engpässe eigentlich in Access oder Aggregation entstehen sollten. Diese Annahme ist in vielen Netzen zwar häufig richtig – aber nicht immer. Genau deshalb lohnt es sich, QoS im Core nicht als „optional“ zu betrachten, sondern als Stabilitäts- und Konsistenzschicht, die gerade in Ausnahmefällen den Unterschied macht. Denn Congestion im Core entsteht typischerweise nicht durch dauerhaft zu wenig Bandbreite, sondern durch Betriebsrealitäten: Failover-Events, Wartungsumleitungen, ungleichmäßige Traffic-Muster, Mikrobursts, Hotspots durch Anycast/CDN-Routing, TE-Fehlkonfigurationen, kapazitätsarme Interconnects oder schlicht durch unerwartete Nachfrage (z. B. Großevents, Software-Updates, DDoS-ähnliche Lastspitzen). Wenn dann im Core keine konsistente Klassenbehandlung vorhanden ist, werden Echtzeitdienste wie Voice und interaktives Video sofort spürbar schlechter, während die Ursachenanalyse schwierig bleibt. Ein professionelles Core-QoS-Design akzeptiert daher: Der Core ist meist wenig belastet, aber er ist nicht immun gegen Congestion – und genau für diese Situationen brauchen Sie saubere Klassenmodelle, kontrolliertes Queueing, passende Shaping-Strategien an Übergängen und Telemetrie, die Queue-Delay und Drops sichtbar macht.
Warum die Aussage „Core is uncongested“ historisch sinnvoll war
Backbones wurden traditionell so geplant, dass sie nicht der Flaschenhals sind. Hohe Linkkapazitäten, kurze Hop-Anzahlen und starke Redundanz sollten sicherstellen, dass die meisten Staus am Rand passieren. Zudem war das Traffic-Profil früher oft vorhersehbarer: weniger Video, weniger Cloud-Backups, weniger massive Software-Distributionen. In solchen Netzen konnte QoS im Core tatsächlich als „Konsistenzmaßnahme“ gelten, nicht als zwingender Congestion-Mechanismus.
- Hohe Kapazität: 10G/100G/400G Links reduzieren die Wahrscheinlichkeit dauerhafter Engpässe.
- Redundanz: viele Pfade, schnelle Konvergenz, weniger „einzelne“ Bottlenecks.
- Kurze Pfade: geringere Latenz- und Queueing-Summen über wenige Hops.
- Klare Hierarchie: Access/Aggregation als natürliche Congestion Domains.
Warum das heute nicht immer stimmt: Core-Congestion ist oft ereignisgetrieben
Moderne Netze sind dynamischer. Congestion im Core ist häufig nicht „dauerhaft“, sondern entsteht in Zeitfenstern und Szenarien, die im Mittelwert unsichtbar sind. Genau das macht sie gefährlich: Die Telemetrie zeigt vielleicht 40% Durchschnittsauslastung, während in kurzen Intervallen Queue-Delay und Drops auftreten. Für Echtzeitdienste reicht ein kurzer Stau, um Jitter-Buffer zu überfordern oder Paketverlust hörbar zu machen.
- Wartung und Umleitungen: geplante Arbeiten verlagern Traffic auf weniger Pfade.
- Failover: ein Link-/Node-Ausfall bündelt Ströme, Backup-Pfade haben oft weniger Headroom.
- Hotspot-Routing: Anycast, CDN-Placement und BGP-Policies konzentrieren Traffic auf wenige Knoten.
- Traffic-Spikes: Updates, große Events, neue Releases erzeugen synchronisierte Lastwellen.
Congestion Domains im Core: Nicht der ganze Backbone ist einheitlich
Ein häufiger Denkfehler ist, den Core als homogenes Netz zu betrachten. In der Praxis hat der Core mehrere Congestion Domains: bestimmte Knoten fungieren als Hubs, bestimmte Link-Bündel sind häufiger Ziel von Umleitungen, und bestimmte Übergänge (z. B. zu DCs, Cloud-Interconnects oder Internet-Edges) sind deutlich stärker belastet. Wenn Sie QoS im Core planen, müssen Sie diese Domains explizit definieren – genauso wie im Metro-Ring oder im Access.
- Core-to-Edge Übergänge: Links Richtung Internet/Peering/BNG/Service Edge sind oft heißer als reine Transit-Links.
- DC/Cloud Hubs: Data Center und Cloud-Gateways ziehen massive Ost-West- und Nord-Süd-Ströme an.
- Regional Hubs: Aggregation großer Regionen in wenige Backbone-Knoten erzeugt Hotspots.
- TE/Policy Domains: SR/TE oder MPLS-TE kann Traffic bündeln, wenn Policies ungünstig sind.
Mikrobursts im Core: Warum hohe Kapazität Drops nicht ausschließt
Mikrobursts sind kurze, intensive Traffic-Spitzen, die Warteschlangen in Millisekunden füllen können. Im Core treten sie vor allem an Fan-in Punkten auf: viele schnelle Eingänge speisen in einen Ausgang, der zwar hochkapazitiv ist, aber in einem Moment dennoch überrannt wird. Das führt zu kurzzeitigen Queue-Overflows oder zu stark schwankender Queue-Delay. Für Voice/Video ist das bereits kritisch, auch wenn „der Core sonst frei“ ist. Der Umgang damit ist weniger „mehr Bandbreite“, sondern kontrollierte Queueing-Strategien, sinnvolle Buffer-Policies, Shaping an Übergängen und eine Telemetrie, die solche Peaks sichtbar macht.
- Fan-in Effekte: mehrere Eingänge auf einen Ausgang erzeugen kurzfristige Überschwinger.
- Queue-Delay Peaks: Jitter steigt, bevor Drops sichtbar werden.
- Short-interval Monitoring: Perzentile und kurze Fenster sind entscheidend, Mittelwerte verschleiern das Problem.
Interconnects und Service-Edges: „Core-Probleme“ sind oft Übergangsprobleme
Viele wahrgenommene „Core-Congestion“-Probleme entstehen an Übergängen, die logisch zum Core zählen, operativ aber Edge-Eigenschaften haben: Peering-Ports, Transit-Uplinks, Cloud-Interconnects, DC-Gateways. Diese Links sind häufig bewusst enger dimensioniert oder wachsen langsamer als reine Backbone-Trunks. Wenn dort Congestion entsteht und QoS-Klassen nicht konsistent umgesetzt werden, wirkt es wie ein Core-Problem – tatsächlich ist es ein Domain-Übergangsproblem. Für QoS bedeutet das: Shaping und klare Queue-Profile an diesen Übergängen sind oft wirksamer als komplexe Policies auf jedem Transit-Hop.
- Peering/Transit: begrenzte Kapazität und externe Einflussfaktoren, Congestion möglich.
- Cloud-Edges: hohe Nachfrage, Traffic-Synchronisation durch Workloads und Updates.
- BNG/Service-Edges: viele Sessions, starke Aggregation, Engpässe bei Wachstum oder Failover.
- Shaping Points: Queue in den eigenen Einflussbereich holen, statt Drops „irgendwo“ zu haben.
Routing, TE und Failover: Wenn Pfadwahl Congestion erzeugt
Selbst bei ausreichend Gesamtbandbreite kann Pfadwahl Congestion erzeugen. IGP-ECMP verteilt nicht immer so gleichmäßig, wie man hofft – insbesondere bei großen „Elephant Flows“ oder wenn Hashing ungünstig ist. Segment Routing oder MPLS-TE kann Traffic bewusst lenken, aber Fehlkonfigurationen oder unpassende Constraints können Hotspots erzeugen. Nach Failover verschärft sich das: Traffic, der vorher über mehrere Pfade ging, konzentriert sich. Core-QoS muss deshalb auch „Failure-aware“ sein: gleiche Klassenbehandlung auf Backup-Pfaden, Headroom-Planung und Tests unter Last.
- ECMP-Hashing: ungleichmäßige Verteilung kann einzelne Links überlasten.
- TE-Policies: bündeln Traffic, wenn Constraints/Weights nicht sauber sind.
- Fast Reroute: Backup-Pfade sind nicht immer gleich kapazitiv, QoS muss trotzdem funktionieren.
- Testen: Failover unter Mischlast ist Pflicht, sonst bleiben Probleme verborgen.
Was QoS im Core wirklich leisten sollte
Core-QoS ist selten dafür da, einen dauerhaft überlasteten Backbone zu „retten“. Es ist dafür da, in den unvermeidbaren Congestion-Szenarien Prioritäten stabil zu halten und Jitter/Loss in Echtzeitklassen zu minimieren. Gleichzeitig muss Core-QoS operativ beherrschbar bleiben: wenige Klassen, konsistente Mappings, klare Queue-Profile, robuste Default-Policies und Telemetrie-first. Ein überkomplexes Core-QoS ist ein Betriebsrisiko.
- Konsistenz: DSCP↔MPLS-TC (und ggf. PCP) netzweit identisch.
- Schutz: Network Control und OAM dürfen nie verhungern.
- Echtzeit stabil: Voice-LLQ strikt begrenzt, Video gewichtete Echtzeitklasse.
- Best Effort optimieren: AQM/ECN kann Bufferbloat reduzieren und Latenz stabilisieren.
- Übergänge kontrollieren: Shaping an Core-to-Edge/Interconnects bringt Reproduzierbarkeit.
Klassenmodell und Queueing im Core: Schlank, aber eindeutig
Ein bewährtes Modell nutzt wenige Klassen, die in jeder Domäne gleich verstanden werden. Für Voice ist eine strikt priorisierte Queue sinnvoll, aber strikt limitiert, damit sie nicht zum „Staubsauger“ wird. Interaktives Video gehört in eine gewichtete Echtzeitklasse mit Mindestbandbreite. Business Critical bekommt eine bevorzugte Datenklasse. Best Effort bleibt Best Effort, idealerweise mit AQM/ECN. Bulk/Scavenger wird bewusst nachrangig, um Burst-Traffic (Backups, Updates) im Congestion-Fall zu dämpfen.
- Network Control: höchste Schutzpriorität, kleine, verlässliche Ressourcen.
- Voice: LLQ, geringe Queue-Limits, striktes Rate-Limit.
- Video: gewichtete Echtzeitklasse, stabiler Anteil, kein unlimitierter Priority.
- Business: bevorzugte Datenklasse für interaktive Anwendungen.
- Best Effort: AQM/ECN gegen Bufferbloat, stabile RTT-Perzentile.
- Bulk: nachrangig, um Congestion-Spitzen abzufedern.
Messbarkeit: Wie Sie Core-Congestion überhaupt sicher erkennen
Wenn man Core-Congestion nur über Durchschnittsauslastung bewertet, übersieht man das Problem. Entscheidend sind queuebezogene KPIs: Queue-Delay, Queue-Depth, Drops pro Klasse, ECN-Markierungen (falls genutzt) sowie Event-Korrelation mit Routing/TE/Failover. Für Echtzeit ist Queue-Delay oft der Frühindikator, bevor Drops auftreten. Ein gutes Monitoring betrachtet Perzentile (p95/p99) in kurzen Zeitfenstern, weil genau dort Mikrobursts sichtbar werden.
- Queue-Delay: p95/p99 pro Klasse an kritischen Core-Links und Übergängen.
- Class Drops: Drops in Echtzeitklassen sind immer kritisch, Best Effort Drops anders interpretieren.
- ECN/WRED: Mark-/Drop-Raten zeigen AQM-Wirkung und Congestion-Niveau.
- Event-Korrelation: Link-Flaps, Maintenance, TE-Reoptimierung mit QoS-KPIs verbinden.
Typische Failure Patterns: Wenn der Core „plötzlich“ doch congested ist
Bestimmte Muster tauchen in realen Netzen immer wieder auf. Sie sind meist nicht „mysteriös“, sondern die Folge von Domain-Übergängen, Failover oder ungünstiger Traffic-Konzentration. Core-QoS hilft in diesen Fällen, dass Echtzeit nicht als erstes leidet, aber die eigentliche Lösung liegt oft in Kapazität, Pfadsteuerung oder besser platzierten Shaping Points.
- Massive RTT-Spikes ohne Drops: Bufferbloat in Core-to-Edge Übergängen; AQM/Shaping prüfen.
- Kurze Drop-Bursts: Mikrobursts an Fan-in Links; Queue-Limits und Shaping-Placement prüfen.
- Probleme nur nach Failover: Backup-Pfad ohne Headroom oder ohne identische QoS-Policies.
- Hotspot an einem Hub: BGP/Anycast/TE bündelt Traffic; Pfadsteuerung und Kapazität prüfen.
- Interconnect „zieht“ den Core runter: Engpass am Peering wirkt wie Core-Problematik; Übergangs-QoS und Shaping nötig.
Blueprint: QoS im Core so designen, dass es im Ernstfall trägt
Ein praxiserprobtes Vorgehen beginnt mit der Definition der Congestion Domains im Core: Transit-Links, Hub-Links, Core-to-Edge Übergänge, Interconnects. Für jede Domain wird ein Normal- und Failover-Kapazitätsmodell erstellt. Danach werden wenige Klassen definiert und Mappings (DSCP↔MPLS-TC) konsistent umgesetzt. Shaping Points werden gezielt an Übergängen platziert, an denen Congestion wahrscheinlich ist, damit die Queue kontrolliert bleibt. Best Effort erhält AQM/ECN, um Bufferbloat zu reduzieren, während Echtzeitklassen über limitierte LLQ und gewichtete Klassen geschützt werden. Abschließend wird Telemetrie aufgebaut, die Queue-Delay und Drops in kurzen Zeitfenstern sichtbar macht und mit Routing-/TE-Events korreliert. So wird die Aussage „Core is uncongested“ zu einer realistischen Erwartung – und nicht zu einer gefährlichen Annahme, die in den Momenten versagt, in denen Servicequalität am meisten zählt.
