Diverse Paths: Physische Redundanz wirklich getrennt verifizieren

Diverse Paths sind im Provider- und Telco-Betrieb ein zentraler Baustein für Verfügbarkeit: Physische Redundanz soll verhindern, dass ein einzelnes Ereignis – etwa ein Fiber Cut, ein Tiefbauunfall, eine Muffenstörung oder ein PoP-Problem – beide Pfade gleichzeitig trifft. In der Praxis ist „divers“ jedoch häufig nur auf dem Papier divers. Viele Outages entstehen genau deshalb, weil vermeintlich getrennte Pfade in Wirklichkeit eine gemeinsame Ausfall-Domäne teilen: dieselbe Trasse, derselbe Schacht, dieselbe Muffe, derselbe Gebäudeeintritt, dieselbe ODF-Reihe oder dieselbe Cross-Connect-Strecke. Das Resultat ist ein überraschend großer Blast Radius: Beim ersten Cut fällt nicht nur der Primary aus, sondern auch der „Backup“, und der NOC steht plötzlich vor einem SEV1, obwohl die Architektur „redundant“ klang. Physische Redundanz wirklich getrennt verifizieren bedeutet deshalb, Diversität nicht als Marketing-Label zu behandeln, sondern als überprüfbares Engineering-Kriterium – mit eindeutigen Daten, klaren SRLG-/Fault-Domain-Tags, Mess- und Auditmethoden sowie einem regelmäßigen Re-Validation-Prozess, der Änderungen (Reparaturen, Umverlegungen, Provider-Umbauten) berücksichtigt. Dieser Leitfaden zeigt praxisnah, wie Sie Diverse Paths verifizieren: vom Inventory- und GIS-Abgleich über OTDR- und Trassenplausibilisierung bis hin zu Betriebssignalen (Latenzsprünge, Ausfallmuster), Checklisten für Carrier/Vendor und einem Evidence Pack, das im Incident sofort nutzbar ist.

Warum „divers“ so oft nicht divers ist

Physische Diversität scheitert selten an fehlendem Willen, sondern an fehlender Transparenz. Netzteams sehen häufig nur die logische Topologie (Primary/Secondary), aber nicht die physische Realität (Trassenführung, Muffen, Schächte, Gebäudeeintritte). Besonders in gewachsenen Netzen und bei Mehrlieferanten-Szenarien entstehen versteckte Gemeinsamkeiten.

• Gemeinsame Trasse: zwei Fasern laufen in derselben Rohrgruppe oder demselben Kabel, nur logisch getrennt.
• Gemeinsame Muffe oder Schacht: Trassen sind bis kurz vor dem PoP getrennt, treffen aber in einer kritischen Muffe zusammen.
• Gemeinsamer Gebäudeeintritt: unterschiedliche Außenwege, aber gleicher Eintrittspunkt, gleiche Steigzone.
• Gemeinsames ODF/Panel: beide Pfade enden im selben Rackbereich; ein Bedienfehler trifft beide.
• Reparaturen/Umverlegungen: nach Fiber Cuts werden Wege provisorisch zusammengeführt, ohne dass die Dokumentation nachzieht.

Grundbegriffe: Diverse Paths, SRLG und Fault Domains

Um physische Redundanz wirklich zu verifizieren, benötigen Sie ein gemeinsames Vokabular. Drei Begriffe sind besonders relevant:

• Diverse Paths: zwei (oder mehr) Pfade, die so wenig gemeinsame physische Infrastruktur wie möglich teilen.
• SRLG (Shared Risk Link Group): Gruppe von Links/Pfaden, die ein gemeinsames Ausfallrisiko teilen (Trasse, Kabel, Schacht, PoP, Energie).
• Fault Domain: praktische Ausfall-Domäne im Betrieb (Ring, Span, PoP, Gebäude, ODF, Provider-Segment).

Die wichtigste Konsequenz: „Diverse“ ist kein binäres Ja/Nein, sondern ein Grad von SRLG-Überlappung. Ein Pfad kann auf Trassenebene divers sein, aber am Gebäude- oder ODF-Ende nicht.

Was „wirklich getrennt“ bedeutet: Mindestkriterien für physische Diversität

Bevor Sie verifizieren, definieren Sie Mindestkriterien. Nur so vermeiden Sie, dass Diskussionen im Incident zur Glaubensfrage werden. In der Praxis haben sich diese Kriterien bewährt:

• Trassen-Diversität: Primary und Secondary laufen auf unterschiedlichen Trassenabschnitten; keine gemeinsamen kritischen Schächte/Muffen in einem definierten Radius.
• Gebäudediversität: unterschiedliche Gebäudeeintritte und getrennte Steigzonen (idealerweise unterschiedliche Gebäudeseiten).
• PoP-/Rack-Diversität: getrennte ODFs oder zumindest getrennte Panelgruppen und getrennte Patchwege.
• Provider-/Carrier-Diversität: wenn möglich unterschiedliche Carrier-Segmente oder nachweislich unterschiedliche Trassen innerhalb eines Carriers.
• Operative Diversität: getrennte Wartungsfenster/Change-Scopes, damit ein Fehler nicht beide Pfade gleichzeitig trifft.

Verifikationsstrategie: Vier Ebenen, die zusammen „Beweis“ ergeben

Eine einzelne Methode reicht selten aus. Robust wird Diversitätsverifikation durch Kombination aus (1) Dokumenten-/Inventory-Abgleich, (2) physischer Trassenplausibilisierung, (3) Mess-/Telemetry-Indizien und (4) Audit im Betrieb.

• Ebene 1: Inventory/GIS – Trassenkarten, Muffenlisten, Kabel-IDs, SRLG-Tags.
• Ebene 2: Physische Plausibilisierung – PoP/ODF/Building Entry Checks, Fotodoku, Labeling.
• Ebene 3: Messindizien – OTDR, Laufzeit/Latenz, Faserlängenvergleich.
• Ebene 4: Betriebsaudit – Failover-Tests, Incident-Muster, Maintenance-Revalidation.

Ebene 1: Inventory- und GIS-Abgleich als Ausgangspunkt

Der schnellste Weg zur Diversitätsverifikation ist ein strukturierter Abgleich aus Inventory (Link- und Circuit-Daten) und GIS/Trassenplan. Ziel ist, SRLG-Overlaps explizit zu machen. Selbst wenn GIS nicht perfekt ist, liefert es meist genug, um „gemeinsame Knoten“ (Schächte/Muffen/Eintritte) zu finden.

• Link-IDs und Kabel-IDs: beide Pfade auf Kabel- und Segmentebene auflösen (nicht nur „Port A ↔ Port B“).
• SRLG-Tags: pro Segment SRLG-ID(s) hinterlegen und auf Overlap prüfen.
• Node-Liste: Schächte/Muffen/PoP-Knoten entlang des Pfads als Sequenz exportieren.
• Overlap-Check: Schnittmenge der Node-Listen beider Pfade identifizieren.

SRLG-Overlap als einfache Kennzahl (MathML)

$\mathrm{OverlapRate}=\frac{\mathrm{|SRLG}\_A\cap \mathrm{SRLG}\_B|}{\mathrm{|SRLG}\_A\cup \mathrm{SRLG}\_B|}$

Je näher OverlapRate an 0 liegt, desto besser. Wichtig: Das ist ein Hilfswert, keine Garantie – denn SRLG-Tags können unvollständig sein. Aber er ist sehr geeignet, um Risiken zu priorisieren („welche Circuits müssen wir zuerst auditieren?“).

Ebene 2: Physische Endpunktprüfung im PoP und im Gebäude

Viele „nicht diverse“ Fälle entstehen an den Endpunkten: gleicher Gebäudeeintritt, gleiche Steigzone, gleiche ODF-Reihe. Diese Gemeinsamkeiten sind oft sichtbar, wenn Sie sie systematisch prüfen. Eine kurze, standardisierte Endpunktprüfung ist deshalb ein Muss – besonders für latenzkritische oder SLA-kritische Circuits.

• Building Entry: unterschiedliche Eintrittspunkte dokumentieren (Gebäudeseite, Raum, Zugang).
• Steigzone: getrennte vertikale Wege (nicht beide im selben Kabelschacht).
• ODF/Panel: getrennte Panelgruppen; idealerweise getrennte Racks oder Räume.
• Patchführung: getrennte Kabelwege, Zugentlastung, klare Labels, kein „gemeinsamer Kabelsalat“.

Für Handling- und Best-Practice-Grundlagen im Glasfaserbetrieb sind Ressourcen wie die Fiber Optic Association (FOA) hilfreich, insbesondere für Inspection/Cleaning und sichere Patchpraxis.

Ebene 3: Messindizien – OTDR und Latenz als Plausibilisierung

Messungen ersetzen keine Trassenkarte, aber sie sind extrem nützlich, um Widersprüche aufzudecken. Besonders zwei Methoden sind praxistauglich: OTDR für Faserlänge/Ereignisprofil und aktive Delay-Messung (OWAMP/TWAMP) für Pfad-Laufzeit. Beide liefern Indizien, ob Pfade „wirklich unterschiedlich“ sind.

OTDR: Unterschiedliche Traces als Hinweis auf physische Diversität

Wenn zwei Pfade physisch getrennt sind, zeigen OTDR-Traces häufig unterschiedliche Ereignismuster und Enddistanzen: andere Spleißanzahl, andere Eventpositionen, andere Gesamtdistanz. Das ist kein absoluter Beweis (zwei Pfade können zufällig ähnlich aussehen), aber ein starker Plausibilisierungsfaktor – vor allem, wenn Inventory-Daten unzuverlässig sind.

• Enddistanz: deutlich unterschiedliche Enddistanz spricht für unterschiedliche Trassenführung.
• Eventmuster: unterschiedliche Spleiß-/Muffenpositionen stützen Diversität.
• Bidirektional: wenn möglich von beiden Enden messen, um Messartefakte zu reduzieren.

Feldnahe OTDR-Referenzen finden sich u. a. bei VIAVI und EXFO.

Latenz/Delay: Unterschiedliche Laufzeiten als indirekter Pfadbeweis

Wenn zwei Pfade wirklich getrennt sind und unterschiedliche Faserlängen haben, unterscheiden sich oft auch die Laufzeiten. Für belastbare Messungen sind OWAMP/TWAMP hilfreicher als Ping, weil Profile und QoS kontrollierbar sind. Referenzen: RFC 4656 (OWAMP) und RFC 5357 (TWAMP).

Delta-Delay als Indiz (MathML)

$\Delta \mathrm{Delay}=\mathrm{Delay}\_\mathrm{pathB}-\mathrm{Delay}\_\mathrm{pathA}$

• Interpretation: Ein stabiler Unterschied im P50 deutet auf unterschiedliche Pfadlänge hin.
• Warnung: Gleiches Delay ist kein Beweis für Gleichheit – Pfade können unterschiedlich sein und dennoch ähnliche Länge haben.

Ebene 4: Betriebsaudit – Diversität durch Tests und Incident-Muster validieren

Physische Diversität ist nicht „einmal prüfen und fertig“. Trassen werden umgelegt, Muffen geändert, Reparaturen provisorisch umgesetzt, und Provider ändern Infrastruktur. Deshalb braucht Diversität ein Audit-Konzept im Betrieb: gezielte Failover-Tests, Maintenance-Reviews und Incident-Postmortems, die SRLG-Overlaps konsequent erfassen.

• Geplante Failover-Tests: kontrolliert einen Pfad deaktivieren (in Wartungsfenstern) und prüfen, ob der andere wirklich unabhängig bleibt.
• Post-Incident Review: bei jedem Fiber Cut prüfen, ob „Backup“ betroffen war; wenn ja, SRLG-Mapping korrigieren.
• Revalidation nach Repair: nach Trassenarbeiten/Repairs Diversität erneut prüfen, weil Umwege/Reserve-Loops entstehen können.
• Change Guardrails: parallele Changes auf Primary und Secondary in derselben Schicht vermeiden.

Carrier/Vendor-Szenario: Wie Sie „diverse“ beim Lieferanten wirklich einfordern

Bei zugekauften Circuits ist Diversität oft vertraglich „best effort“ oder nur logisch definiert. Wenn Sie physische Trennung brauchen, müssen Sie präzise Anforderungen formulieren und Nachweise verlangen. Besonders wichtig: „diverse“ ist nicht erfüllt, wenn beide Services im selben Kabel oder im selben Gebäudeentry enden.

• Anforderung: unterschiedliche Trassen (geografisch) und unterschiedliche Building Entry Points.
• Nachweis: SRLG-Statement, Trassenbeschreibung, Node-Liste oder GIS-Auszug (je nach Provider möglich).
• Auditrecht: definieren, wie bei Incidents die physische Route offengelegt wird (zumindest in Teilen).
• Operational Agreement: Maintenance-Koordination, damit nicht beide Pfade im selben Window betroffen sind.

Typische „Diverse“-Anti-Patterns und wie Sie sie erkennen

• Dual Services, same duct: zwei Services, aber gleiche Rohrgruppe/Kabel → SRLG-Overlap hoch.
• Different PoP, same entry: andere logische Endpunkte, aber gleicher Gebäudeeintritt.
• Ring-Protection als einzige Diversität: schützt gegen einzelne Cuts, nicht gegen gemeinsame Trassenknoten oder PoP-Ausfall.
• ODF Shared Risk: beide Pfade im selben Panel → ein Fehlpatch oder ein „cleaning incident“ trifft beide.
• Repair-Induced Coupling: nach Reparaturen laufen Pfade plötzlich gemeinsam, Dokumentation bleibt alt.

Checkliste: Physische Redundanz wirklich getrennt verifizieren

• 1) Daten sammeln: Circuit-IDs, A/Z-Ende, Kabel-/Segment-IDs, SRLG-Tags, Node-Listen.
• 2) Overlap prüfen: gemeinsame SRLGs, gemeinsame Schächte/Muffen, gemeinsame Gebäudeentrys.
• 3) Endpunkte auditieren: Building Entry, Steigzone, ODF/Panel, Patchwege.
• 4) Plausibilisieren: OTDR-Traces vergleichen, Delay/Latency-Profil vergleichen (OWAMP/TWAMP).
• 5) Betrieb testen: geplante Failover-Übung, Monitoring während Maintenance.
• 6) Dokumentieren: Evidence Pack erstellen, SRLG-Map aktualisieren, Revalidation-Termin setzen.

Evidence Pack: Das Minimum für „Diverse Paths“ als Nachweis

Ein Evidence Pack ist besonders hilfreich, weil Diversität oft erst im Incident politisch relevant wird. Wenn Sie dann keine Daten haben, verlieren Sie Zeit. Ein schlankes Pack enthält:

• Pfaddefinition: Primary/Secondary Circuit-IDs, A/Z-Ende, Serviceklasse.
• SRLG/Node-Listen: Overlap-Analyse, gemeinsame Knoten explizit markiert (oder bestätigt „keine“).
• Endpunktfotos/Skizzen: Building Entry und ODF-Layout (wenn organisatorisch zulässig).
• Messindizien: OTDR-Enddistanz/Events, OWAMP/TWAMP Delay-Profile (P50/P95).
• Audit-Historie: Datum der letzten Verifikation, Changes/Repairs seitdem.

Outbound-Ressourcen

• The Fiber Optic Association (FOA): Best Practices, Handling und Safety
• ITU-T G.652 (Single-mode optical fibre and cable)
• RFC 4656: OWAMP (One-Way Active Measurement Protocol)
• RFC 5357: TWAMP (Two-Way Active Measurement Protocol)
• VIAVI: OTDR Solutions (Feldmessung und Plausibilisierung)
• EXFO Resources (Optical Test & Monitoring)

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.