Site icon bintorosoft.com

Telco Blueprint “Core Backbone”: Referenztopologie für SR/IGP/BGP

Red Snapper

A female IT engineer works in the gloomy server space aiding laptop, network and data center services.

Ein Telco Blueprint „Core Backbone“ beschreibt die Referenztopologie und die verbindlichen Designregeln für das Herz eines Carrier-Netzes: den IP/MPLS- bzw. SR-Transport, auf dem Metro, Access, Interconnect und Services aufbauen. Ziel eines Core-Backbone-Blueprints ist nicht, jede Spezialanforderung abzudecken, sondern eine robuste, wiederverwendbare Basis zu liefern, die in mehreren Regionen skaliert, schnell konvergiert, Betriebsaufwand reduziert und Interoperabilität über Plattformen hinweg ermöglicht. Im modernen Telco-Core stehen dabei drei Themen im Mittelpunkt: ein stabiles IGP-Design (OSPF oder IS-IS), eine konsistente Segment-Routing-Architektur (meist SR-MPLS, optional SRv6) und ein sauberes BGP-Design (iBGP mit Route Reflectors, klare Hierarchien und Guardrails). In der Praxis scheitert ein Core selten an „zu wenig Features“, sondern an fehlender Disziplin: inkonsistente SRGB/SID-Pläne, übermäßig komplexe BGP-Policy-Distribution, fehlende Control-Plane-Protection, unklare Failure Domains oder eine Observability, die Ereignisse nicht topologisch korreliert. Ein guter Blueprint integriert deshalb nicht nur Topologie und Protokolle, sondern auch Betrieb (Ops): Standard-Templates, Validierungsregeln, Canary- und Rolling-Upgrade-Methodik, sowie messbare Erfolgsmetriken. Dieser Artikel liefert ein praxistaugliches Referenzdesign für einen Telco Core Backbone für SR/IGP/BGP – inklusive Rollenmodell, Domänenschnitt, Protection-Strategien, Policy-Guardrails und Operations-Bausteinen, damit der Core „boring, fast and safe“ bleibt.

Zielsetzung des Core-Backbone-Blueprints

Der Core ist Transport. Er sollte möglichst wenige kundenspezifische Sonderfälle tragen und stattdessen stabile, standardisierte Dienste ermöglichen: deterministische Pfadwahl, schnelle Wiederherstellung im Fehlerfall, klare Kapazitätsplanung und konsistente Telemetry. Der Blueprint definiert deshalb explizit, was der Core tut – und was er nicht tut.

Leitprinzip: Core ist „boring“ – Policy gehört an die Kante

Je mehr kundenspezifische Policy im Core liegt, desto größer wird der Blast Radius bei Fehlern und Migrationen. Der Core sollte sich auf Routing, SR-Transport und Schutzmechanismen konzentrieren.

Referenztopologie: Dual-Core, Multi-Core und regionale Hierarchie

Ein Core-Backbone-Blueprint definiert zuerst die Topologiepattern. In Telco-Netzen ist häufig eine hierarchische Struktur sinnvoll: regionale Core-Knoten, gekoppelt über ein nationales/überregionales Backbone, mit klaren Übergaben zu Metro/Hubs und zu Interconnect-/Service-Edges. Wichtig ist, dass die Topologie ECMP-fähig ist und Failure Domains klar begrenzt.

Designregel: Topologie definiert Resilienz, nicht Timer

Konvergenz und Stabilität gewinnen Sie primär durch alternative Pfade (ECMP), diverse SRLGs und FRR-Mechaniken – nicht durch aggressives Timer-Tuning, das Flapping fördern kann.

Rollenmodell im Core: P-Router, RR, Edge und Controller-Domänen

Der Blueprint wird operativ erst handhabbar, wenn Rollen klar sind. Im klassischen Carrier-Design trennt man P-Router (Transit/Label Switching) von PE- und Servicefunktionen. Route Reflectors (RR) sind eine eigene Control-Plane-Rolle. Optional existiert eine Controller-/Automation-Domäne für SR-Policies und Telemetry.

Anti-Pattern: RR-Funktionen „nebenbei“ auf P-Routern

Das erhöht die Komplexität und den Blast Radius. Ein Blueprint sollte RR als eigene Rolle definieren, damit Control Plane und Forwarding sauber getrennt bleiben.

IGP-Blueprint: OSPF vs. IS-IS, Hierarchie und Metrikmodell

Das IGP ist die „Wahrheitsmaschine“ für den Underlay-Graphen. Für Telco-Core-Backbones hat sich IS-IS häufig bewährt, weil es gut in große, hierarchische Umgebungen passt. OSPF ist ebenfalls möglich, wenn Area-Design und Summarization diszipliniert umgesetzt werden. Entscheidend sind Konsistenz, klare Flooding-Scopes und ein Metrikmodell, das Kapazität und Linkklasse abbildet.

Designregel: IGP ist für Reachability, nicht für Policy

Vermeiden Sie IGP als Policy-Werkzeug. Präferenzen für Transit/Peering gehören in BGP; IGP sollte den Transportgraphen stabil abbilden.

Segment-Routing-Blueprint: SR-MPLS als Standard, SRGB und SID-Strategie

Segment Routing im Core wird in vielen Telcos als SR-MPLS eingeführt, weil es LDP ersetzen kann und gleichzeitig MPLS-Service-Modelle unterstützt. Der Blueprint muss dabei drei Dinge fest definieren: SRGB (Segment Routing Global Block), die SID-Zuweisung (Node-SIDs, ggf. Anycast-SIDs) und die Betriebsstrategie (Underlay first, Policies später).

Anti-Pattern: SRGB per Vendor-Default

In Multi-Vendor-Backbones führen Default-SRGBs schnell zu Inkonsistenzen. Der SRGB ist ein zentraler Vertragsparameter und muss im Blueprint festgeschrieben werden.

FRR-Blueprint: TI-LFA, Coverage und Failure Domains

Carrier-Grade bedeutet schnelle Wiederherstellung. TI-LFA ist in SR-MPLS-Backbones ein starkes Werkzeug, aber nur so gut wie die Topologie. Der Blueprint muss deshalb definieren, welche Failure Cases abgedeckt werden müssen (Link/Node), welche Coverage erwartet wird und wie diese Coverage nachgewiesen wird.

Ein Coverage-Intent als einfache Logik

Coverage= Protected_Links Total_Links ≥0.95

Der konkrete Zielwert hängt von Ihren SLOs ab, aber der Blueprint sollte ein messbares Ziel definieren und Lücken als Engineering-Backlog behandeln.

BGP-Blueprint: iBGP, Route Reflectors und Hierarchie-Patterns

BGP im Core ist die Policy- und Skalierungsplattform für Services und Interconnects. Der Core-Blueprint sollte iBGP über Route Reflectors nutzen, nicht Full Mesh. Entscheidend ist dabei RR-Placement: getrennte Failure Domains, klare Cluster-IDs, und ein Design, das Partitionen überlebt. Zudem braucht BGP Guardrails: Max-Prefix, Policy-Whitelists, Leak-Prevention.

Designregel: RR sind Control Plane – behandeln Sie sie wie kritische Infrastruktur

RR-Ausfälle können große Teile des Netzes destabilisieren. Der Blueprint muss RR als eigene Maintenance Domain mit eigenem Monitoring und Upgrade-Plan definieren.

Interconnect-Schnittstellen: Edge-Policy sauber vom Core trennen

Der Core Backbone sollte Interconnect- und Kundenpolicies nicht „mitziehen“. Stattdessen definiert der Blueprint klare Edge-Kanten: Internet Edge, Peering, Transit, PNIs, DDoS-Steering. Der Core transportiert, die Edge entscheidet. Diese Trennung ist entscheidend für Interop, Sicherheit und Betrieb.

Anti-Pattern: „Quick fix“ Policies im Core

Ad-hoc Policies im Core wirken kurzfristig, erzeugen aber langfristig Drift und erhöhten Change Risk. Der Blueprint sollte klare Kanten und einen Ausnahmeprozess mit Ablaufdatum vorsehen.

QoS- und MTU-Blueprint: Transportqualität als Vertrag

Core-Backbones tragen alle Traffic-Klassen. Deshalb braucht es ein transportweites QoS-Klassenmodell und eine MTU-Strategie, die Overhead durch MPLS/SR berücksichtigt. Ohne diese Standards entstehen „seltsame“ Incidents: nur große Pakete brechen, nur bestimmte Services degradieren im Failover, oder Queue-Drops treffen ausgerechnet die kritischen Klassen.

Designregel: Core-Standards müssen messbar sein

QoS und MTU sind nur dann „Standard“, wenn Sie sie per Telemetry und Tests nachweisen können. Der Blueprint sollte Pflicht-KPIs und Validierungschecks definieren.

Observability-by-Design: Telemetry, Flow-Visibility und High-Signal Alerts

Ein Core Backbone muss beobachtbar sein, sonst werden Upgrades und Störungen zu „Black Box“-Situationen. Der Blueprint legt fest, welche Metriken Pflicht sind, wie Telemetry-Pfade topologisch korreliert werden (Region/PoP/Rolle/Linkklasse) und wie Alarmierung ohne Noise funktioniert. Wichtig ist auch die Trennung von Control-Plane-Signalen (BGP/IGP/CPU) und Data-Plane-Signalen (Queue-Drops, Loss/RTT).

Designregel: Observability ist Teil des Designs, nicht nachträgliches Monitoring

Wenn Telemetry-Labels und Pflichtmetriken nicht im Blueprint stehen, entsteht pro Region ein anderes Monitoring – und damit ein hoher OPEX.

Ops-Blueprint: Change-Methodik, Canary, Wellen und Rollback

Carrier-Grade bedeutet, dass der Core auch während Wartung stabil bleibt. Der Blueprint definiert deshalb Maintenance Domains, progressive Rollouts und objektive Stop/Go-Gates. Rollback muss geplant und getestet sein, inklusive Traffic-Steering zurück und Wiederherstellen von Schutzprofilen.

Anti-Pattern: „Upgrade nachts, hoffen und fertig“

Ohne Canary und Gates werden Upgrades zu Risiko. Der Blueprint sollte Upgrades wie Releases behandeln: messen, schrittweise ausrollen, bei Signal stoppen.

Interoperabilität und Governance: Vendor-übergreifend ohne Drift

Viele Telco-Backbones sind Multi-Vendor. Der Blueprint muss deshalb Interop als Vertragswerk definieren: erlaubte Feature-Sets, Timerprofile, SRGB/SID-Plan, QoS-Klassenmodell, Telemetry-Contract und eine unterstützte Version-Matrix. Zusätzlich braucht es Ausnahmeprozesse mit Ablaufdatum, damit Sonderfälle nicht dauerhaft werden.

Designregel: „Eine Wahrheit“ für Policies und Parameter

Wenn SRGB, Communities oder Timer pro Region abweichen, steigt OPEX massiv. Der Blueprint sollte zentrale Parameter als unverhandelbaren Vertrag definieren.

Erfolgsmetriken für den Core Backbone Blueprint

Ein Referenzdesign ist erst erfolgreich, wenn es messbar stabiler und einfacher zu betreiben ist. Definieren Sie KPI-Gruppen für Resilienz, Performance/Capacity und Operability – und messen Sie sowohl Normalbetrieb als auch N-1 Wartungssituationen.

Praktische Leitlinien: Telco Blueprint „Core Backbone“ für SR/IGP/BGP

Exit mobile version