Core-Design ist im Provider- und Telco-Umfeld eine der wichtigsten Architekturentscheidungen, weil der Core als Rückgrat die Verfügbarkeit, Skalierbarkeit und Betriebsstabilität des gesamten Netzes maßgeblich beeinflusst. Dabei stehen Planer häufig vor der Frage, welches Strukturmodell langfristig am besten passt: ein Dual-Core mit zwei zentralen Knoten, ein Multi-Core mit mehreren gleichwertigen Core-PoPs oder eine stärker hierarchische Core-Struktur mit übergeordneten und untergeordneten Ebenen. Jede Variante hat klare Stärken, aber auch typische Nebenwirkungen – auf Redundanz, Failure Domains, Kapazitätsplanung, Latenz, Routing-Komplexität und Betriebskosten. Besonders im Carrier-Grade Betrieb ist nicht nur relevant, wie viele Core-Knoten es gibt, sondern wie die Rollen verteilt sind, wie unabhängig Pfade wirklich sind und wie wartbar das Netz bleibt, wenn es wächst. Dieser Artikel vergleicht Dual-Core, Multi-Core und hierarchische Designs praxisnah, zeigt typische Einsatzszenarien und liefert Kriterien, mit denen Sie eine fundierte Entscheidung treffen können – ohne sich in reiner Theorie zu verlieren.
Was der Core im Telco-Netz leisten muss
Bevor man Core-Varianten vergleicht, sollte klar sein, welche Aufgaben der Core typischerweise übernimmt. Im Telco-Design ist der Core nicht nur „schnelles Routing“, sondern die Ebene, die regionale Netze verbindet, strategische Übergänge bündelt und Ausfall- sowie Wartungsszenarien abfedern muss. Daraus ergeben sich Kernanforderungen, die jedes Core-Modell erfüllen sollte – unabhängig davon, ob es zwei oder zehn PoPs umfasst.
- Überregionale Konnektivität: Verbindung zwischen Metro-Regionen, Rechenzentren, Peering- und Transit-Standorten.
- Hohe Kapazität: Große Portgeschwindigkeiten, skalierbare Upgrades, planbare Erweiterungen.
- Resilienz: Mehrfachpfade und echte Diversität gegen Trassen-, Knoten- und Standortausfälle.
- Stabiler Kontrollplan: Vorhersehbare Pfadwahl, geringe Flap-Ausbreitung, gut definierte Domänen.
- Wartbarkeit: Geplante Arbeiten ohne großflächigen Impact, klar definierte Maintenance-Prozesse.
- OPEX-Optimierung: Standardisierung, einfache Fehlersuche, klare Rollen, Automatisierbarkeit.
Core-Design ist immer auch Failure-Domain-Design
Im Provider-Umfeld ist die zentrale Frage selten „Wie redundant ist das Netz?“, sondern „Wie groß ist der maximale Impact eines einzelnen Fehlers?“. Die Core-Architektur bestimmt die Größe und Form dieser Failure Domains: Ein zentraler Dual-Core kann eine sehr große Failure Domain darstellen, wenn beide Knoten gemeinsame Risiken teilen. Ein Multi-Core kann Failure Domains verkleinern, wenn er sauber regionalisiert ist. Eine Hierarchie kann Failure Domains kontrollieren, kann aber auch neue Engpass- und Abhängigkeitsrisiken erzeugen, wenn Übergänge falsch gesetzt sind.
Dual-Core: Zwei zentrale Knoten als Backbone-Anker
Beim Dual-Core besteht der Core im Wesentlichen aus zwei zentralen, leistungsstarken Knoten (oft in zwei unterschiedlichen Standorten), an die Metro- oder Aggregationsbereiche redundant angebunden werden. Dieses Modell ist in kleineren bis mittleren Provider-Netzen verbreitet oder in Umgebungen, in denen ein zentraler Service-Hub bewusst gewünscht ist. Der Vorteil liegt in der Einfachheit: wenig Core-Komplexität, klare Pfadlogik und überschaubare Betriebslast im Backbone.
- Vorteile: Einfache Architektur, wenige Core-Standorte, klare Standardisierung, leichteres Troubleshooting.
- Typische Einsatzfelder: Nationale Netze mit zentralem Knotenpaar, kleinere Carrier, Spezialnetze.
- Stärken im Betrieb: Weniger Knotenrollen im Core, weniger Policy-Varianz, schnellere Fehlerlokalisierung.
Dual-Core Risiken: Gemeinsame Abhängigkeiten und Wachstumsgrenzen
Dual-Core-Designs werden kritisch, wenn sie „zu zentral“ werden. Häufige Risiken sind gemeinsame Trassen- oder Standortabhängigkeiten (Shared Risk), übermäßige Lastkonzentration und wachsende Latenz, weil Verkehr unnötig über die zentrale Achse läuft. Außerdem steigt bei Wachstum die Port- und Linkdichte am Dual-Core stark an, was Upgrades disruptive machen kann, wenn nicht früh ein klarer Kapazitätsplan existiert.
- Shared Risk: Zwei Knoten sind nur dann wirklich redundant, wenn Standort-, Strom- und Trassenrisiken getrennt sind.
- Hotspot-Gefahr: Der Core wird zum dauerhaften Engpass, wenn regionaler Traffic zentral „durch muss“.
- Disruptive Upgrades: Kapazitätserweiterungen konzentrieren sich auf wenige Knoten und Links.
Multi-Core: Mehrere gleichwertige Core-PoPs für Skalierung und Regionalität
Beim Multi-Core gibt es mehrere Core-PoPs, die in der Regel als gleichwertige Backbone-Knoten fungieren. Diese PoPs sind meist partiell vermascht (nicht unbedingt vollvermascht), sodass zwischen wichtigen Regionen mehrere unabhängige Pfade existieren. Multi-Core ist besonders attraktiv, wenn ein Netz geografisch verteilt ist, lokale Breakouts (Peering, Transit, Services) benötigt oder wenn Wachstum die zentrale Dual-Core-Achse überlasten würde.
- Vorteile: Bessere Skalierung, regionale Pfade, weniger Zentralisierung, flexible Erweiterbarkeit.
- Typische Einsatzfelder: Größere nationale Netze, internationale Backbones, Netze mit vielen Metro-Regionen.
- Resilienz: Ausfälle können regional abgefangen werden, wenn Failure Domains sauber definiert sind.
Multi-Core Risiken: Mehr Zustände, mehr Policy-Disziplin erforderlich
Multi-Core reduziert Zentralisierungsrisiken, erhöht aber die Anzahl möglicher Zustände bei Ausfällen. Damit steigen Anforderungen an konsistente Policies, saubere Domänenbildung, standardisierte Metrikmodelle und gutes Monitoring. Ohne Standardisierung drohen Sonderfälle pro Region, die den Betrieb teuer machen. Der Schlüssel ist daher ein rollenbasiertes Core-Modell: gleiche Regeln für gleiche PoPs, klare Kriterien für Vermaschung und eine definierte Peering-/Service-Strategie.
- Komplexität: Mehr Links und Knoten erhöhen die Zahl möglicher Failure-Szenarien.
- Policy-Konsistenz: Uneinheitliche Regeln führen zu schwer erklärbarer Pfadwahl.
- Monitoring-Anspruch: Pfadtransparenz und Korrelation entlang von Failure Domains werden wichtiger.
Hierarchische Core-Designs: Super-Core, Core und regionale Ebenen
Hierarchische Designs strukturieren den Backbone in Ebenen, zum Beispiel einen übergeordneten „Super-Core“ (oder Global Core), darunter regionale Core-Knoten und darunter Metro-Edges. Ziel ist, Skalierung durch klare Verantwortlichkeiten zu erreichen: Nicht jeder Knoten muss alles wissen und alles können. Hierarchien können den Kontrollplan entlasten und die Infrastruktur wirtschaftlicher machen, wenn sie sauber geplant sind.
- Vorteile: Strukturierte Skalierung, klare Domänengrenzen, potenziell kleinere Routing-Sicht pro Ebene.
- Typische Einsatzfelder: Sehr große Netze, internationale Carrier, Netze mit vielen Regionen und unterschiedlichen Serviceanforderungen.
- Operative Logik: Wartung und Changes lassen sich pro Ebene planen und begrenzen.
Hierarchie-Risiken: Engpässe und „Zwangswege“
Hierarchien werden problematisch, wenn Übergänge zu hart sind: Wenn regionaler Verkehr unnötig über höhere Ebenen laufen muss, steigen Latenz und Last, und zentrale Knoten werden zum Engpass. Außerdem können zu viele Ebenen (zu „tiefe“ Hierarchie) das Troubleshooting erschweren, weil mehr Domänengrenzen, mehr Übergangs-Policies und mehr mögliche Fehlstellen entstehen. Ein gutes hierarchisches Design benötigt daher klare Kriterien, wann Verkehr lokal bleiben darf und wann er übergeordnete Ebenen nutzen muss.
- Aggregation-Bottlenecks: Übergänge zwischen Ebenen werden zu Hotspots, wenn Kapazität nicht mitwächst.
- Latenz: Zusätzliche Hops und Umwege durch Zwangswege können SLAs gefährden.
- Komplexere Governance: Mehr Ebenen erfordern disziplinierte Policy- und Change-Prozesse.
Vergleichskriterien: Wie Sie Dual-Core, Multi-Core und Hierarchie bewerten
Die Wahl eines Core-Designs sollte nicht ideologisch erfolgen, sondern anhand messbarer Kriterien. In der Praxis sind diese Vergleichsdimensionen besonders hilfreich, weil sie sowohl Technik als auch Betrieb und Kosten abbilden.
- Geografie und Verkehrsflüsse: Zentraler Nord-Süd-Traffic begünstigt Dual-Core, verteilte Ost-West-Flows begünstigen Multi-Core.
- Service-Placement: Zentralisierte Service-Edges passen eher zu Dual-Core/Hierarchie, verteilte Breakouts eher zu Multi-Core.
- Resilienzanforderungen: Wie viele unabhängige Pfade sind erforderlich, und wie real ist physische Diversität?
- Kapazitätswachstum: Wachstumskurven pro Region und Linkklasse, Upgrade-Pfade, Portstrategie.
- Kontrollplan-Stabilität: Domänenbildung, Aggregation, Policy-Konsistenz, erwartete Konvergenzzeiten.
- Betriebskosten: Standardisierungspotenzial, Monitoring-Aufwand, Change-Frequenz, Incident-Handling.
Ein praktisches Bewertungsmodell: Zentralität vs. Regionalität
Viele Entscheidungen lassen sich auf eine Achse reduzieren: Wie stark soll das Netz zentralisiert sein? Dual-Core ist maximal zentralisiert, Multi-Core ist stärker regionalisiert, Hierarchien sind ein strukturiertes Zwischenmodell. Zentralisierung reduziert Core-Varianten, erhöht aber Hotspot-Risiken. Regionalisierung verteilt Last und reduziert Zwangswege, erhöht aber die Anforderungen an Konsistenz und Governance.
Resilienz und Wartung: Welche Core-Variante ist am „wartungsfreundlichsten“?
Carrier-Grade Betrieb verlangt, dass Wartungen ohne großflächigen Service-Impact möglich sind. Das ist ein guter Stresstest für Core-Designs. Ein Dual-Core kann wartungsfreundlich sein, wenn echte Diversität und ausreichende Störfallkapazität vorhanden sind. Ein Multi-Core kann Wartungen leichter „wegverteilen“, erfordert aber klar definierte Pfadlogik und Telemetry. Hierarchien können Wartungen pro Ebene isolieren, riskieren jedoch Engpässe an Übergängen.
- Dual-Core: Wartung ist gut planbar, sofern beide Standorte unabhängig sind und die verbleibende Seite genügend Reserve hat.
- Multi-Core: Wartung einzelner PoPs ist oft leichter, wenn Pfade alternative regionale Routen bieten.
- Hierarchie: Wartung ist pro Ebene isolierbar, aber Übergangsknoten müssen besonders robust dimensioniert sein.
Störfallkapazität: Der unterschätzte Unterschied
Viele Designs sind redundant, aber nicht störfallfähig. Wenn beim Ausfall eines Core-Knotens die verbleibenden Links sofort überlasten, entsteht Degradation statt Verfügbarkeit. Ein solides Core-Design verankert daher Reservequoten und Upgrade-Trigger – besonders bei Dual-Core, wo Lastkonzentration am höchsten ist.
Policy-Design und Konsistenz: Multi-Core und Hierarchie brauchen klare Leitplanken
Je mehr Core-Knoten existieren, desto wichtiger werden rollenbasierte Policies. Das gilt für Peering-Richtlinien, Security-Filter, QoS-Klassen, Traffic Engineering und Managementzugriffe. Ohne standardisierte Templates steigt die Zahl der Ausnahmen, und Pfadverhalten wird unvorhersehbar. Ein auditierbares, skalierbares Core-Design behandelt Policies wie Software: versioniert, getestet, ausgerollt in Wellen, mit Rollback.
- Rollenmodell: Core-PoP, Regional Core, Metro Edge, Service Edge, Peering Edge.
- Policy-Templates: Einheitliche Standards pro Rolle, Ausnahmen streng kontrollieren.
- Pfadtransparenz: Monitoring und Telemetry müssen erklären können, warum Traffic welchen Pfad nimmt.
- Governance: Review-Prozesse, Change-Scopes und Guardrails begrenzen den Blast Radius.
Warum Dual-Core oft „einfacher“ wirkt, aber nicht automatisch besser ist
Dual-Core ist häufig leicht zu betreiben, solange das Netz klein bis mittelgroß ist und die Verkehrsflüsse gut zur Zentralisierung passen. Sobald jedoch regionale Breakouts, mehrere Rechenzentren und starke Ost-West-Flüsse hinzukommen, wird die einfache Struktur zum Nachteil: Sie zwingt Traffic in zentrale Wege und macht den Core zum Engpass. Dann ist Multi-Core oder eine kontrollierte Hierarchie oft nachhaltiger.
Kapazitäts- und Upgrade-Strategie: Wachstum ohne disruptive Umbauten
Ein guter Core skaliert in Stufen: zusätzliche Links, höhere Portgeschwindigkeiten, mehr Wellenlängen und – falls nötig – neue PoPs. Die Core-Variante beeinflusst, wie disruptiv diese Schritte sind. Dual-Core konzentriert Upgrades auf wenige Knoten, Multi-Core verteilt Upgrades, Hierarchien bündeln Upgrades an Übergängen. Entscheidend sind klare Trigger und ein standardisiertes Upgrade-Modell.
- Upgrade-Trigger: Auslastung, Störfallreserve, Traffic-Wachstum pro Region.
- Portstrategie: Einheitliche Port-/Optikklassen pro Ebene, um Betrieb und Ersatzteile zu vereinfachen.
- Linkstrategie: Kriterien für neue Links (Traffic, Risiko, Diversität, Latenzanforderungen).
- PoP-Strategie: Wann ein neuer Core-PoP sinnvoll ist (z. B. um Latenz zu senken oder Hotspots zu entlasten).
Ein einfaches Denkmodell für Core-Load-Verteilung
Die Lastverteilung wird bei Multi-Core natürlicher, bei Dual-Core muss sie bewusster geplant werden. Vereinfacht lässt sich der Skalierungsdruck als Verhältnis ausdrücken:
Skalierungsdruck∝ Traffic AnzahlCorePoPs
Je höher der Traffic bei gleicher Anzahl Core-PoPs, desto stärker wachsen Portdichte, Upgrade-Frequenz und Hotspot-Risiko. Dieses Modell ist bewusst vereinfacht, hilft aber, die Intuition zu schärfen: Mehr Core-PoPs können Last verteilen, erhöhen aber Governance- und Konsistenzanforderungen.
Praxisleitlinien: Wann welches Core-Modell typischerweise passt
In der Realität entscheiden selten einzelne Kriterien, sondern Kombinationen aus Geografie, Services, Wachstum und Betriebsreife. Dennoch lassen sich typische Muster erkennen, die bei der Vorauswahl helfen.
- Dual-Core passt oft, wenn: das Netz geografisch kompakt ist, Breakouts zentralisiert sind, die Organisation einfache Betriebsmodelle bevorzugt und echte Standortdiversität möglich ist.
- Multi-Core passt oft, wenn: Regionen stark wachsen, Ost-West-Flows zunehmen, lokale Peering-/Transitpunkte benötigt werden und Latenzanforderungen regional unterschiedlich sind.
- Hierarchie passt oft, wenn: das Netz sehr groß ist, unterschiedliche Regionen unterschiedliche Rollen haben und Kontrollplan- sowie Betriebsgrenzen durch Domänenstruktur entlastet werden müssen.
Die wichtigste Regel: Konsistenz schlägt „Perfektion“
Ein „theoretisch optimales“ Core-Design verliert, wenn es nicht konsequent standardisiert, getestet und betrieben wird. Ein etwas weniger ambitioniertes Modell mit klaren Blueprints, sauberer Adressierung, rollenbasierten Policies und guter Observability ist im Carrier-Grade Alltag häufig erfolgreicher – weil es stabil wächst und im Incident schnell beherrschbar bleibt.