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.
- Transportstabilität: IP/MPLS/SR als verlässliche Basis für Metro, Access, DC und Service-Edges.
- Skalierung: Wachstum in Links, Knoten und Regionen, ohne Control-Plane-Explosion.
- Resilienz: Link-/Node-Ausfälle abfangen, schnelle Recovery, planbare Wartung (N-1/N-2 je nach SLO).
- Interoperabilität: Vendor-übergreifend über klaren Feature- und Parametervertrag.
- Operability: Standardisierte Rollouts, klare Failure Domains, schnelle Fehlereingrenzung.
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.
- Dual-Core pro Region: Zwei Core-Knoten je Region/PoP-Cluster, diverse Uplinks, keine gemeinsamen SRLGs.
- Backbone-Mesh zwischen Regionen: Selektives Mesh (partial mesh) mit ECMP, nicht zwingend Full Mesh.
- Hub-Übergaben: Metro-/Aggregation-Hubs dual-homed an Core-Paare; klare Maintenance Domains.
- DCI/Cloud-Anbindung: Separate Linkklasse mit QoS/MTU-Standards, ggf. eigener TE-Fokus.
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.
- P-Router: Reiner Transportknoten, IGP + SR, keine Kunden-VRFs, minimale Policy.
- RR-Cluster: BGP Control-Plane, hierarchisch, redundant, getrennte Failure Domains.
- Service/Interconnect Edge: eBGP/Policies, DDoS/RTBH/FlowSpec, Internet Edge – bewusst außerhalb des reinen Core.
- Controller/Automation (optional): SR-TE Policy Management, Intent Validation, zentrale Telemetry Pipelines.
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.
- Hierarchie: Regionale Domänen als Level/Area; Backbone als übergeordnete Ebene mit definierten Summaries.
- Metriklogik: Linkklasse und Kapazität berücksichtigen (z. B. 100G vs. 400G, DCI vs. Core).
- Adjacency-Disziplin: Nur notwendige Nachbarschaften, keine unkontrollierten Mesh-Adjazenzen.
- Stabilität: SPF/LSA/LSP-Throttling Profile bewusst setzen, nicht Defaults mischen.
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).
- SRGB Plan: Einheitlicher Bereich für das gesamte Backbone oder pro Domäne – aber explizit und dokumentiert.
- Node-SIDs: Eindeutige Node-SIDs je Router, idealerweise abgeleitet aus stabilen Pools (z. B. pro Region).
- Anycast-SIDs (optional): Für bestimmte Backbone-Services (z. B. RR-Services, Telemetry Gateways), nur mit klaren Health-Gates.
- SR Capability Rollout: Canary-Domäne, dann Wellen; Koexistenzregeln, falls LDP parallel läuft.
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.
- Protection Scope: Link Protection und Node Protection als Mindeststandard für Core-Links.
- Coverage-Nachweis: Messbar machen, welche Links/Nodes geschützt sind und wo Lücken existieren.
- BFD-Profile: Stabil, konsistent, und abgestimmt auf Plattform und Linkqualität; keine aggressiven Profile ohne Tests.
- Planned Maintenance: „Degraded Mode“ definieren: Drain/Cost-Increase statt Hard-Down, um kontrollierte Pfade zu erhalten.
Ein Coverage-Intent als einfache Logik
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.
- RR-Hierarchie: Regionale RRs mit übergeordneten Super-RRs oder klaren Domänengrenzen.
- Redundanz: Jeder Client mindestens zwei RRs in getrennten Failure Domains (PoP/Region/Facility).
- Policy Distribution: Communities und LocalPref-Modelle standardisiert, versioniert und getestet.
- Guardrails: Max-Prefix pro Neighbor-Typ, Exportfilter, Default-deny, Route 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.
- Edge-Knotenrollen: Interconnect Router/Service Edge außerhalb der P-Router-Rolle.
- Community Contract: Einheitliche Communities für no-export, blackhole, prepend, region-tag.
- Max-Prefix und Filters: Pflicht für alle externen Sessions, inklusive Warnschwellen und Runbooks.
- DDoS-Bausteine: RTBH/FlowSpec/Steering nur aus autorisierten Quellen, mit Containment.
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.
- QoS Klassenmodell: Wenige, robuste Klassen, konsistentes Marking, Queueing an Engpässen.
- Degraded Mode: QoS-Failover-Profil für N-1 Situationen, Bulk wird gedrosselt, kritische Klassen geschützt.
- MTU Mindeststandards: End-to-End MTU inkl. Label-Stack, PMTUD-Policy, MSS-Clamping wo nötig.
- Tests: MTU und QoS nicht nur im Normalpfad, sondern auch im Schutzpfad validieren.
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).
- Pflichtmetriken: Portauslastung, Queue-Drops, Loss/RTT, CPU/Memory, IGP/BGP Health, FRR/TI-LFA Events.
- Flow-Visibility: IPFIX/NetFlow Placement für Traffic Engineering und Hotspot-Analyse, mit Sampling-Strategien.
- High-Signal Alerts: „Link down + FRR event + Queue-Drops“ statt isolierte Einzelalarme.
- Telemetry Guardrails: Sampling, Batching, Backpressure, damit Telemetry nicht selbst zur Last wird.
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.
- Maintenance Domains: Core-Paare, Regionpaare, DCI-Klassen; nie beide Redundanzseiten gleichzeitig.
- Canary-Strategie: Repräsentative PoPs/Links als Canary, mit realer Last, aber begrenztem Blast Radius.
- Stop/Go Gates: SLOs (Loss/RTT), Queue-Drops, Prefix-Counts, Routing-Churn, FRR-Events.
- Rollback: Versionierte Templates, reversible Policies, getestete Prozeduren, Evidence-by-Design Archivierung.
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.
- Interop Blueprint: Minimal getestetes Feature-Set für IGP/SR/BGP, explizite Defaults, keine vendor-spezifischen Überraschungen.
- Version-Matrix: Unterstützte Kombinationen, Canary-Upgrades vor breiten Wellen.
- Intent Validation: Guardrails (Leaks, Max-Prefix, MTU, CoPP) vor Changes automatisch prüfen.
- Exception Management: Review, Audit, Ablaufdatum, Rückführung in Standard.
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.
- Resilienz: Konvergenzzeit (Link/Node), FRR/TI-LFA Activation, Coverage, Blast Radius pro Failure Domain.
- Performance: p95/p99 RTT, Loss, Queue-Drops pro Klasse, Headroom an Engpässen, ECMP-Imbalance.
- Operability: MTTR, Change-Failure-Rate, Anzahl manueller Hotfixes, Drift-Events zwischen SoT und Netz.
- Upgrade-Qualität: Erfolgsquote Canary/Wellen, Rollback-Rate, Zeit bis Stabilität nach Changes.
Praktische Leitlinien: Telco Blueprint „Core Backbone“ für SR/IGP/BGP
- Topologiepattern festlegen: Dual-Core pro Region, partial mesh zwischen Regionen, klare Übergaben zu Metro/Edge, diverse SRLGs.
- Rollen strikt trennen: P-Router als Transport, RR als Control Plane, Policies an Edge-Kanten, Controller optional als eigene Domäne.
- IGP konservativ standardisieren: Hierarchie, Metrikmodell, Timerprofile und Flooding-Scopes explizit konfigurieren.
- SR sauber planen: SRGB und SID-Strategie als Vertrag, Canary-Rollout, Koexistenzregeln bei Übergang.
- FRR/TI-LFA messbar machen: Coverage-Ziele definieren, Failure Scenarios testen, BFD stabil und konsistent.
- BGP/RR robust designen: Hierarchische RRs, Redundanz über Failure Domains, Max-Prefix und Leak-Guardrails verpflichtend.
- QoS und MTU als Transportvertrag: Klassenmodell, Engpasspunkte, Degraded Mode, End-to-End MTU inkl. Label-Overhead.
- Observability-by-Design: Pflichtmetriken, Flow-Visibility, High-Signal Alerts, Topologie-Labels für Korrelation.
- Ops-Methodik standardisieren: Canary, progressive Wellen, Stop/Go Gates, getesteter Rollback, Evidence-by-Design.
- Interop & Governance erzwingen: Version-Matrix, Intent Validation, Ausnahmeprozesse mit Ablaufdatum, damit der Core langfristig „boring and safe“ bleibt.
