Telco Blueprint “Metro Ring”: Referenzdesign inkl. Protection und Ops

Ein Telco Blueprint „Metro Ring“ ist ein wiederverwendbares Referenzdesign für Aggregationsnetze in Städten und Ballungsräumen – dort, wo Access-Standorte, Mobile Backhaul, Business-Services und regionale PoPs aufeinandertreffen. Ringe sind in Metro-Netzen so beliebt, weil sie eine klare Struktur liefern: definierte Knotenrollen, überschaubare Failure Domains, planbare Kapazität und robuste Schutzmechanismen. Gleichzeitig scheitern Metro-Ringe in der Praxis selten an der Grundtopologie, sondern an den Details: falsche Platzierung von Protection (Schutzpfaden), inkonsistente L2/L3-Grenzen, unklare Wartungsdomänen, fehlendes QoS- und MTU-Engineering oder eine Observability, die im Fehlerfall nicht genug Signal liefert. Ein professioneller Blueprint ist deshalb mehr als ein Diagramm. Er definiert auch den Betrieb (Ops): Standard-Templates, Monitoring- und Alarmierungsregeln, Change- und Rollback-Methodik, Failure-Scenario-Tests und eine klare Dokumentationsstruktur (L1/L2/L3/Services). In diesem Artikel erhalten Sie ein praxisnahes Referenzdesign für einen Metro Ring inkl. Protection und Operations: Welche Varianten sich bewährt haben (L2-Ring, L3-Ring, EVPN/Segment-Routing-Optionen), wie Schutzmechanismen geplant werden, wie Sie Kapazität und QoS korrekt dimensionieren und wie Sie den Ring so betreiben, dass Rolling Upgrades und Störungsanalyse ohne Überraschungen möglich sind.

Zielsetzung und Einsatzbereich eines Metro-Ring-Blueprints

Ein Metro-Ring bündelt typischerweise viele heterogene Anforderungen: hohe Verfügbarkeit, kurze Konvergenzzeiten, klare SLA-Profile, skalierbare Servicebereitstellung und einfache Betriebsprozesse. Das Blueprint-Ziel ist nicht „maximale Technologie“, sondern ein stabiler Standard, der in mehreren Städten/Regionen wiederverwendbar ist, inklusive definierter Grenzen, ab wann ein Ring erweitert, gesplittet oder in ein Mesh überführt werden sollte.

• Aggregation: Sammeln von Access/Backhaul-Traffic und Übergabe an Core/Regional PoP.
• Servicefähigkeit: L2VPN/L3VPN, Wholesale, Enterprise Access, Mobile Backhaul, Anycast-nahe Services.
• Resilienz: Schutz gegen Link- und Node-Ausfälle, möglichst ohne große Serviceunterbrechungen.
• Operability: Standardisierte Rollouts, klare Wartungsdomänen, schnelle Fehlereingrenzung.

Leitprinzip: Metro Ring als definierte Failure Domain

Ein Ring ist ein bewusst begrenzter Auswirkungsbereich. Je klarer Sie diese Grenze definieren, desto besser lassen sich Schutz, Kapazität und Betrieb standardisieren.

Referenz-Topologie: Knotenrollen und Ringvarianten

Ein Metro-Ring-Blueprint beginnt mit Rollen. Rollen ermöglichen Templates, Policies und Messkonzepte. In der Praxis haben sich drei Ringvarianten etabliert: L2-Ring (Bridging-dominiert), L3-Ring (Routing-dominiert) und hybride Designs (z. B. L2 im Access, L3 in der Aggregation). Für Carrier-Grade Betrieb ist L3 häufig bevorzugt, weil Failure Domains klarer sind und Broadcast-Risiken sinken.

• Aggregation Nodes (AGG): Ringknoten, an denen Access- und Backhaul-Standorte angebunden werden.
• Hub Nodes (HUB): Übergabe in Richtung Core/Regional DC, oft als zwei diverse Hubs (Dual-Hub) ausgeführt.
• Access Spokes (ACC): Kleine Sites/Cell Sites/FTTH-OLT-Aggregation, oft als Dual-Homing auf zwei AGGs.
• Service Edge (optional): PE-Funktionalität für VPNs/EVPN, ggf. BNG-nahe Funktionen in Metro-Hubs.

Entscheidungslogik: L2-Ring vs. L3-Ring

• L2-Ring: Sinnvoll, wenn Access/Transport stark L2-getrieben ist (z. B. QinQ), aber erfordert striktes Loop- und Flooding-Management.
• L3-Ring: Sinnvoll, wenn IP/MPLS/SR als Transport genutzt wird; klarere Isolation, bessere Skalierung, einfachere Konvergenzsteuerung.
• Hybrid: L2 im letzten Stück (Access), L3 im Metro-Ring; reduziert L2-Blast-Radius.

L1-Blueprint: Physik, SRLG und „echte“ Diversität

Carrier-Grade beginnt bei L1. Zwei Links auf dem Papier sind keine Redundanz, wenn sie dieselbe Trasse teilen. Ein Metro-Ring-Blueprint enthält deshalb L1-Regeln: SRLG-Zuordnung, diverse Wege, getrennte Gebäudeeinführungen, sowie klare Dokumentation von Patchfeldern und Cross-Connects. Diese Informationen sind entscheidend für Schutzmechanismen und Wartungsplanung.

• SRLG-Regeln: Ringsegmente nach Trasse/Fiber-Bundle klassifizieren; Hubs in getrennte Facility-Risiken.
• Dual-Hub Diversität: HUB-A und HUB-B dürfen keine gemeinsamen kritischen Abhängigkeiten haben (Facility/Power/MMR).
• Port-to-Port Nachweis: Circuit-ID, Endpunkte, Optiktyp, Wavelength, Speed, MTU/Overhead-Anforderungen.
• Maintenance Domains: L1-Segmente so schneiden, dass Wartungen planbar sind (kein gleichzeitiger Verlust beider Redundanzseiten).

Anti-Pattern: „Ring geschlossen“ ohne SRLG-Disziplin

Ein geschlossener Ring ohne SRLG-Disziplin kann im Trassenereignis wie ein Single Link wirken. Der Blueprint sollte „diverse Pfade“ als Pflichtkriterium definieren.

L2-Blueprint: VLAN/QinQ, LAG und Ring-Protection

Wenn L2 im Metro-Ring genutzt wird, muss der Blueprint strikte Regeln enthalten, um Loops und Flooding zu kontrollieren. Typische Bausteine sind QinQ für Wholesale/Access, LAG/MLAG an Übergaben und ein definierter Ring-Protection-Mechanismus. Entscheidend ist die klare Grenze, wo L2 endet und L3 beginnt – und welche L2-Domäne als Failure Domain gilt.

• VLAN-Plan: S-VLAN/C-VLAN Bereiche, reservierte VLANs, Tagging-Policy, Allowed-VLAN-Sets pro Trunk.
• LAG/MLAG: Bündelung an HUBs/AGGs, Member-Monitoring, Hashing-Strategien, Failover-Verhalten.
• Ring-Protection: Definierte Blocked Links, Rollen (RPL Owner/Neighbor, je nach Mechanik), Konvergenzbudgets.
• Storm Control: Broadcast/Multicast/Unknown-Unicast Limits und klare Ausnahmeprozesse.

Designregel: L2 so klein wie möglich, so groß wie nötig

Je größer die L2-Domäne, desto größer der Blast Radius. Der Metro-Blueprint sollte L2 bewusst begrenzen und L3 als Skalierungsgrenze nutzen.

L3-Blueprint: IGP, ECMP und Metro-zu-Core Übergabe

Im L3-Metro-Ring ist das IGP der Stabilitätskern. Der Blueprint definiert ein konservatives IGP-Profil (OSPF oder IS-IS), konsistente Timer, klare Metriklogik und – wo sinnvoll – ECMP. Außerdem definiert er die Übergabe an den Core: häufig via eBGP oder iBGP mit Route Reflectors, abhängig von der Gesamtarchitektur. Für Metro-Ringe ist besonders wichtig, dass Konvergenz im Fehlerfall vorhersehbar bleibt und dass Maintenance (z. B. Rolling Upgrades) ohne große Impact möglich ist.

• IGP-Struktur: Metro als eigene Area/Level oder als definierte Subdomain, mit klaren Summarization-Grenzen.
• Loopback-Design: Stabiler Loopback pro Node, Topologie-aggregierbare Prefixe nach Region/PoP.
• ECMP-Regeln: Wo ECMP erlaubt ist und wie Hashing/Imbalance gemessen wird.
• Core-Uplink: Dual-Hub Uplinks mit klaren Präferenzen, Hold-downs und Maintenance-Mechanik.

Anti-Pattern: Aggressive Timer statt Topologie

Konvergenz gewinnt man im Metro-Design meist über alternative Pfade und saubere FRR-Strategien, nicht über extrem aggressive Timer, die Flapping fördern.

Protection-Design: Link/Node Failures, Konvergenz und Trade-offs

Protection ist der Kern des Metro-Ring-Blueprints. Es geht nicht nur um „Failover schnell“, sondern um kontrolliertes Verhalten: Wo wird geschaltet? Wie groß ist der Blast Radius? Welche Ausfälle müssen innerhalb welcher Zeit abgefangen werden? In einem Ring gibt es typische Failure Cases: Segment Cut (ein Link), Node Failure (ein AGG/HUB), Dual Failure (zwei Segmente) und Partition (Hub-A getrennt, Hub-B erreichbar). Der Blueprint sollte definieren, welche Schutzmechanismen für welche Fälle gelten.

• Link Protection: Schneller Schutz gegen einzelnen Link-Ausfall; Recovery-Budget als Zielwert definieren.
• Node Protection: Ausfall eines Ringknotens darf nicht den ganzen Ring destabilisieren; klare Nachbar- und Routingreaktionen.
• Dual-Hub Protection: Ring muss bei Hub-Ausfall weiterhin einen stabilen Pfad zum verbleibenden Hub haben.
• Maintenance Mode: „Planned Failure“ als eigenes Szenario: Drain/Cost-Increase/Block-Strategy statt Hard-Down.

Ein einfaches Schutzbudget als Denkmodell

$\mathrm{Recovery}=\mathrm{Detection}+\mathrm{Switchover}+\mathrm{Convergence}$

Der Blueprint sollte für jede Failure-Klasse festlegen, welche Recovery-Komponente dominiert und wo Tuning sinnvoll ist (z. B. Detection über BFD, Switchover über Ring-Mechanik/FRR, Convergence über IGP).

QoS-Blueprint: Marking, Queueing und Policing im Metro-Ring

Metro-Ringe transportieren häufig gemischten Traffic: Mobile Backhaul (latency-sensitiv), Business-VPNs, Wholesale, Internet-Aggregation, Synchronisation (NTP/PTP) und Management/Telemetry. Ohne QoS kann ein einzelner Peak (Backup, DDoS-Resttraffic, Event-Streaming) kritische Klassen verdrängen. Der Blueprint definiert deshalb ein konsistentes Klassenmodell und legt fest, wo Marking, Queueing und Policing stattfinden.

• Klassenmodell: Wenige, robuste Klassen (z. B. Realtime, Critical, Best Effort, Bulk) mit klaren DSCP-Regeln.
• Marking-Grenzen: Marking möglichst an der Kante (Access/Service Edge), nicht beliebig im Core.
• Queueing an Engpässen: Ringsegmente und Hub-Uplinks als primäre Engpasspunkte; dort Queueing definieren.
• Policing: Wholesale/Access-Traffic an definierten Übergaben polizen, um Fairness und Schutz zu erreichen.

Anti-Pattern: QoS überall gleich konfigurieren

Ein Metro-Ring braucht ein einheitliches Klassenmodell, aber nicht zwingend identische Hardware-Queues überall. Rollenbasierte QoS-Profile (AGG vs. HUB) sind oft stabiler.

MTU-Blueprint: Overhead, Jumbo Frames und Blackhole Prevention

Metro-Ringe tragen häufig Overlays oder Label-Stacks (MPLS/SR, EVPN, QinQ). Ohne konsistente MTU entstehen selektive Probleme: kleine Pings funktionieren, große Pakete brechen. Der Blueprint definiert deshalb Mindest-MTUs pro Linkklasse, eine End-to-End-Strategie (PMTUD, MSS-Clamping) und klare Tests für Normal- und Failoverpfade.

• Mindest-MTU: Pro Linkklasse (Ringsegment, Hub-Uplink, DCI/Backhaul) definieren, inklusive Overhead.
• PMTUD/MSS: Blackhole Prevention durch saubere ICMP-Handling-Policies und MSS-Strategien.
• Failover-Pfade: MTU muss auch im Schutzpfad stimmen, nicht nur im Normalpfad.
• Standardtests: Größentests, End-to-End Checks, Telemetry für Fragmentation/PMTUD-Probleme.

Designregel: MTU ist ein Service-Contract

MTU ist nicht nur ein Linkparameter, sondern Teil der Servicequalität. Ein Metro-Blueprint sollte MTU als festen Vertrag definieren und automatisiert prüfen.

Ops-Blueprint: Observability, Alarmierung und Runbooks

Ein Metro Ring ist nur dann carrier-grade, wenn Operations im Blueprint verankert ist. Dazu gehören: Telemetry-Pfade, Monitoring-KPIs, Alarmierungslogik mit hohem Signal, sowie Runbooks für die häufigsten Failure- und Maintenance-Szenarien. Besonders wichtig ist die Korrelation nach Topologie: Region/PoP/Ring-ID/Node-Rolle/Linkklasse.

• Telemetry Pflichtmetriken: Portauslastung, Queue-Drops, Loss/RTT, CPU/Memory, IGP/BGP Health, Protection Events.
• High-Signal Alerts: „Ringsegment down + Traffic Shift + Queue-Drops“ statt „Interface down“ allein.
• Runbooks: Link Cut, Node Failure, Hub Failure, Maintenance Drain, Rollback-Prozeduren.
• Incident Drill: Failure Scenario Workshops und regelmäßige Übungen für NOC/Engineering.

Designregel: Protection-Events müssen sichtbar und erklärbar sein

Wenn der Ring schützt, aber niemand sieht, dass er schützt (oder wie), entsteht im Incident Verwirrung. Protection-Zustände gehören als First-Class-Signal ins Monitoring.

Ops-Blueprint: Change-Strategie, Rolling Upgrades und Maintenance Domains

Metro-Ringe werden regelmäßig gewartet: Optiktausch, Softwareupdates, Kapazitätserweiterungen. Ein Blueprint muss deshalb Wartungsdomänen definieren und eine Change-Methodik liefern: Canary, progressive Rollouts, Stop/Go Gates und Rollback. Ziel ist, Upgrades möglichst hitless oder zumindest service-stabil zu machen.

• Maintenance Domains: Ringhälften, Hub-A vs. Hub-B, AGG-Paare; nie beide Redundanzseiten gleichzeitig.
• Drain-Mechanik: Cost-Increase/Policy-Steering statt Hard-Down, um Traffic kontrolliert zu verschieben.
• Stop/Go Gates: SLOs, Queue-Drops, Routing-Churn und Protection-Status entscheiden über Fortsetzung.
• Rollback: Reversibel geplante Schritte, inklusive Rücksteuern von Traffic und Wiederherstellen des Schutzmodus.

Anti-Pattern: Wartung ohne „Degraded Mode“

Während Wartung ist das Netz im N-1. Der Blueprint sollte definieren, wie QoS, Telemetry und Traffic-Steering im Degraded Mode aussehen, damit keine Überraschungen entstehen.

Standardisierte Dokumentation: Multi-Layer Docs als Teil des Blueprints

Ein Metro Ring Blueprint sollte nicht nur „wie bauen“, sondern auch „wie dokumentieren“ festlegen. Empfehlenswert ist eine klare Trennung nach L1/L2/L3/Services, verknüpft über stabile IDs (Ring-ID, Circuit-ID, Device-ID, VRF-ID). So können Betrieb und Engineering schnell drill-downen: von Service zu Pfad zu Link zu Trasse.

• L1: Circuits, SRLG, Port-to-Port, Facility-Abhängigkeiten.
• L2: VLAN/QinQ, LAG/MLAG, Ring-Protection-Parameter, Domänengrenzen.
• L3: IGP-Domäne, Adressaggregation, ECMP-Regeln, Core-Uplink-Policies.
• Services: VRFs, Servicekanten, QoS/SLOs, Anycast-Dienste, DDoS/Logging-Pfade.

Designregel: Eine Quelle der Wahrheit pro Layer

Vermeiden Sie doppelte Wahrheiten. Nutzen Sie eine Source of Truth (z. B. NetBox/CMDB) und leiten Sie Diagramme/Tabellen daraus ab oder validieren Sie sie automatisiert.

Erfolgsmetriken für den Metro-Ring-Betrieb

Ein Blueprint ist erst „fertig“, wenn Erfolg messbar ist. Metriken sollten Resilienz, Performance und Operability abdecken – und sowohl Normalbetrieb als auch N-1-Wartungssituationen berücksichtigen.

• Resilienz: Recovery-Zeit bei Link/Node/Hub-Ausfall, Anzahl betroffener Sites, Protection-Event-Rate.
• Performance: p95/p99 RTT, Loss, Queue-Drops pro Klasse, Headroom an Ringsegmenten und Hub-Uplinks.
• Operability: MTTR, Change-Failure-Rate, Anzahl manueller Hotfixes, Drift-Events zwischen Doku/SoT und Netz.
• Maintenance: Erfolgsquote hitless/low-impact Upgrades, Zeit pro Upgrade-Welle, Rollback-Rate.

Praktische Leitlinien: Telco Blueprint „Metro Ring“ als sofort nutzbares Referenzdesign

• Rollen und Grenzen definieren: AGG/HUB/ACC, Ring-ID, Servicekanten; Ring als Failure Domain festschreiben.
• L1-Diversität erzwingen: SRLG-Regeln, diverse Hub-Anbindungen, Port-to-Port Dokumentation als Pflicht.
• L2/L3 sauber trennen: L2 nur dort, wo nötig; L3 als Skalierungs- und Isolationsebene bevorzugen.
• Protection budgetieren: Detection + Switchover + Convergence als Ziel, inklusive Maintenance-Mode-Strategien.
• QoS als Vertrag: Klassenmodell, Engpasspunkte, Policing-Regeln und Failover-Profil im Blueprint festlegen.
• MTU-End-to-End planen: Overhead berücksichtigen, PMTUD/MSS-Strategie, Tests für Normal- und Schutzpfade.
• Observability-by-Design: Pflichtmetriken, Protection-Events, High-Signal Alerts, Topologie-Labels (PoP/Ring/Rolle).
• Ops-Methodik standardisieren: Canary, progressive Rollouts, Stop/Go Gates, getesteter Rollback, definierte Maintenance Domains.
• Multi-Layer Dokumentation liefern: L1/L2/L3/Services getrennt, verknüpft über stabile IDs, konsistent zur Source of Truth.
• Erfolg messen: Recovery-Zeiten, SLOs, Headroom, Change-Failure-Rate und Drift-Events als dauerhafte KPIs.