Site icon bintorosoft.com

QoS im Core: Warum “Core is uncongested” nicht immer stimmt

Red Snapper

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Exit mobile version