Post-Repair-Validation: Pflicht-Tests nach Fiber-Reparaturen

Post-Repair-Validation ist nach Fiber-Reparaturen der entscheidende Schritt, um „Second Outages“ zu vermeiden und die Entstörung wirklich abzuschließen. In der Praxis endet ein Fiber-Cut-Incident oft nicht mit „Link up“, sondern mit einer riskanten Übergangsphase: Provisorische Spleiße, zusätzliche Reserve-Loops, geänderte Trassenführung, neu gepatchte ODF-Wege oder verschmutzte Connectoren können den Link zwar wieder in Betrieb bringen, aber mit deutlich kleinerer Margin und erhöhten Fehlerkorrekturen. Das Resultat sind wiederkehrende Störungen: High BER, LOF, sporadische CRC-Fehler, Latenzspikes, oder ein erneuter Ausfall bei Temperaturwechseln und Lastspitzen. Pflicht-Tests nach Fiber-Reparaturen stellen sicher, dass nicht nur die physische Kontinuität wiederhergestellt ist, sondern auch die Qualität, Stabilität und Dokumentation stimmen. Dieses Runbook-ähnliche Vorgehen kombiniert Feldmessungen (OTDR, End-to-End Loss), NOC-Telemetrie (DOM/DDM, FEC/BER, Errors), Service-Lens-Checks (Loss/Latenz/Reachability) und einen klaren Sign-off-Mechanismus mit Stabilitätsfenster. Ziel ist ein standardisierter Post-Repair-Prozess, der für ISP/Telco einsatzbereit ist: schnell genug für den Betrieb, aber streng genug, um nachweisbare Qualität und belastbare Evidence Packs für Carrier/Vendor und spätere RCA zu liefern.

Warum „Link up“ kein ausreichender Repair-Sign-off ist

Fiber-Reparaturen verändern häufig mehr als nur „Cut geschlossen“: Es entstehen neue Spleißstellen, die Dämpfung steigt, die Trasse wird länger, und die physische Diversität von Primary/Secondary kann unbemerkt schlechter werden. Gleichzeitig kann das Repair-Team unter Zeitdruck patchen, wodurch Connector-Verschmutzung oder falsche Kabelführung Microbends auslöst. Ohne Post-Repair-Validation bleibt das Netz in einem fragilen Zustand, der bei der nächsten kleinen Zusatzbelastung kippt.

• Zusätzliche Spleiße: additiver Loss frisst PowerMargin.
• Trassenänderung: Pfadlänge/Latenz kann sich ändern, SLA-Diskussionen drohen.
• Provisorische Führung: mechanische Risiken (Biegeradien, Druckstellen) steigen.
• ODF/Panel-Arbeiten: Verschmutzung und Fehlpatches sind häufige „Second Outage“-Treiber.

Pflicht-Tests strukturieren: Vier Ebenen, die zusammen „Repair done“ bedeuten

Ein robuster Post-Repair-Standard arbeitet in Ebenen, weil keine einzelne Messung alle Risiken abdeckt. Die Ebenen sind:

• Ebene 1: Physische Kontinuität & Ortung – OTDR-Trace, Ereignisliste, Cut geschlossen, neue Events sichtbar.
• Ebene 2: End-to-End Loss – Insertion Loss (OLTS/Power Meter) oder belastbare Margin-Bewertung über DOM.
• Ebene 3: Transportqualität – FEC/BER/OSNR/SNR, Uncorrectables, Error-Trends, Stabilität.
• Ebene 4: Service-Validierung – Reachability, Loss/Latenz, Kundensicht (SLA-relevant), Failover-Rückbau mit Guardrails.

Als faserbezogene Grundlage ist ITU-T G.652 eine etablierte Referenz. Für OTDR- und Feldmesspraxis sind VIAVI OTDR Solutions und EXFO Resources hilfreiche Einstiege; für Handling/Best Practices ist die Fiber Optic Association (FOA) verbreitet.

Ebene 1: OTDR – Pflicht nach Trassenreparatur, nicht optional

OTDR ist der schnellste Weg, die Reparatur als „physisch plausibel“ zu bestätigen: Sie sehen das Reparaturereignis, neue Spleiße/Muffen und können die Distanz/Position dokumentieren. Gleichzeitig ist OTDR besonders nützlich, um später bei erneuten Störungen eine Baseline zu haben.

OTDR-Pflichtpunkte nach Repair

• Bidirektional messen: wenn organisatorisch möglich (A→Z und Z→A), um Richtungsartefakte zu reduzieren.
• Trace speichern: Screenshot plus Rohdatei (sofern möglich), mit Zeitstempel (UTC).
• Ereignisliste: neue Spleißstellen, neue Loss-Events, neue reflektive Peaks (falls vorhanden).
• Enddistanz prüfen: ist die Gesamtdistanz plausibel (Hinweis auf Umwege/Reserve-Loops)?

Bidirektionaler Mittelwert für Spleißbewertung (MathML)

$\mathrm{SpliceLoss}\_\mathrm{avg}=\frac{\mathrm{SpliceLoss}\_\mathrm{AtoZ}+\mathrm{SpliceLoss}\_\mathrm{ZtoA}}{2}$

Ebene 2: End-to-End Loss – die Budget-Wahrheit für den Betrieb

OTDR zeigt Ereignisse, aber End-to-End Loss sagt, ob der Link budgetseitig stabil ist. Für Abnahmen ist ein OLTS/Power-Meter-Test (Insertion Loss) ideal. Wenn das nicht verfügbar ist, kann DOM/DDM-Margin als pragmatischer Ersatz dienen – allerdings nur, wenn Rx_min/Rx_max sauber bekannt sind und DOM-Werte zuverlässig sind.

Insertion Loss als Abnahmekriterium

• OLTS/Power Meter: misst TotalLoss über die Strecke; ideal für Repair-Abnahme.
• Vergleich zur Baseline: TotalLoss sollte im erwarteten Band liegen (Vorher/Nachher).
• Budget-Update: neue Spleiße und geänderte Strecke müssen im Engineering-Design nachgeführt werden.

PowerMargin als NOC-Ersatzkennzahl (MathML)

$\mathrm{PowerMargin}\left(\mathrm{dB}\right)=\mathrm{Rx}\_\mathrm{current}\left(\mathrm{dBm}\right)-\mathrm{Rx}\_\min \left(\mathrm{dBm}\right)$

• Pflicht: PowerMargin nach Repair dokumentieren und gegen Baseline vergleichen.
• Warnsignal: deutlich kleinere Margin als zuvor → Risiko für Second Outage steigt.

Ebene 3: Transportqualität – FEC/BER/Errors als Stabilitätsbeweis

Nach einer Reparatur ist die wichtigste Frage: „Ist der Link nur verbunden oder auch qualitativ stabil?“ Dafür sind FEC/BER und Fehlerzähler Pflicht. Gerade nach Spleißarbeiten kann ein Link zwar „up“ sein, aber durch Mikrobiegungen, schlechte Ablage in der Muffe oder verschmutzte Connectoren eine hohe Korrekturlast erzeugen.

Pflichtmetriken im NOC nach Repair

• FEC CorrectedRate: sollte im Normalband liegen oder sich klar verbessern.
• FEC Uncorrectables: muss auf 0 fallen und dort bleiben.
• Pre-FEC BER (falls verfügbar): stabil im Baseline-Band, kein Drift nach oben.
• CRC/PCS Errors: keine neuen Fehlertrends auf Ethernet/Client-Seite.
• LOS/LOF Events: keine Flaps oder Framing-Probleme im Stabilitätsfenster.

FEC CorrectedRate als Rate (MathML)

$\mathrm{FEC}\_\mathrm{CorrectedRate}=\frac{\mathrm{corrected\_blocks}}{\mathrm{time\_window}}$

Hard-Stop-Regel: Uncorrectables

• Wenn Uncorrectables > 0: Repair gilt nicht als abgeschlossen; Field muss nacharbeiten oder Link muss mitigiert werden.
• Wenn CRC/Errors steigen: Prüfung von Connector-Cleanliness und Patchführung, bevor „Trasse wieder aufmachen“ entschieden wird.

Ebene 4: Service-Validierung – der SLA-/Kundensicht-Check

Gerade Provider-Umgebungen brauchen nach Repair einen Service-Lens-Check: Er zeigt, ob die Reparatur im Kundenverhalten angekommen ist und ob Nebenwirkungen (Congestion nach Traffic-Rückführung, Latenzänderung durch Umwege) auftreten. Für aktive Messungen sind OWAMP/TWAMP hilfreicher als Ping, weil Profile kontrollierbar sind (siehe RFC 4656 und RFC 5357).

• Reachability: Stabilität der Adjacencies, keine Routing-Flaps.
• Loss/Latenz: stabiler P50 und P99; keine Loss-Spikes, die auf Qualität hindeuten.
• Traffic-Rückführung staged: wenn während Outage umgeroutet wurde, Rückbau schrittweise mit Guardrails.
• Customer-impact KPIs: Timeouts/Session-Failures müssen zurück in Baseline.

Delta-Delay als Nachweis (MathML)

$\Delta \mathrm{Delay}=\mathrm{Delay}\_\mathrm{after}-\mathrm{Delay}\_\mathrm{before}$

Ein stabiler Sprung im Median kann auf Trassenumweg hinweisen und sollte dokumentiert werden, wenn SLA-/Latenzversprechen existieren.

Stabilitätsfenster: Der wichtigste Gate-Mechanismus nach Repair

Ein Repair wird häufig zu früh „geschlossen“. Ein Stabilitätsfenster verhindert das: Sie definieren eine Mindestzeit, in der Telemetrie stabil sein muss, bevor Cleanup und Sign-off erfolgen. Die Länge hängt von Kritikalität und Traffic ab, aber ein Mindestfenster ist Pflicht.

• Minimum: 30 Minuten stabile Optik- und Qualitätswerte (kein Error-Trend, keine Uncorrectables).
• Bei großen Traffic-Shifts: 60–120 Minuten sind sinnvoll, um Rückführungseffekte zu beobachten.
• Clear-Kriterien: definierte Guardrails (FEC/Errors/DOM) müssen im Normalband bleiben.

Stabilitätskriterium als Gate (MathML)

$\mathrm{Stable}\Leftarrow \mathrm{Uncorrectables}=0\wedge \mathrm{FEC}\_\mathrm{CorrectedRate}\le \mathrm{BaselineBand}\wedge \mathrm{DeltaRx}\approx 0$

Checklist: Pflicht-Tests nach Fiber-Reparaturen (kompakt, einsatzbereit)

• 1) OTDR-Trace(s): A→Z (und Z→A wenn möglich), neue Events markieren, Enddistanz plausibilisieren.
• 2) End-to-End Loss: OLTS/Power-Meter (wenn verfügbar) oder DOM-basierte PowerMargin dokumentieren.
• 3) DOM/DDM: Rx/Tx dBm, Temperatur; DeltaRx gegen Baseline prüfen.
• 4) Transportqualität: Pre-FEC, FEC CorrectedRate, Uncorrectables, OSNR/SNR/Q (je nach Plattform).
• 5) Client/Service: CRC/PCS Errors, LOS/LOF-Events, Reachability.
• 6) Active Tests: OWAMP/TWAMP oder definierte Probe-Transaktionen für Loss/Latenz.
• 7) Diversity-Recheck: wenn Repair an Trasse: prüfen, ob Primary/Secondary SRLG-Overlaps entstanden sind.
• 8) Stabilitätsfenster: 30–120 Minuten je nach Kritikalität, danach staged Cleanup.
• 9) Dokumentation: Evidence Pack aktualisieren (Trace, Werte, Zeitfenster, Field Notes).
• 10) Sign-off: erst nach Gate-Kriterien, nicht nach Bauchgefühl.

Evidence Pack nach Repair: Was zwingend in die Doku gehört

Ein Post-Repair-Evidence-Pack ist nicht Bürokratie, sondern ein operatives Werkzeug: Es beschleunigt spätere RCAs, SLA-Nachweise und zukünftige Dispatches.

• Identifikatoren: Trasse/Span-ID, Circuit-ID, A/Z-Ende, Muffe/Schacht (wenn bekannt).
• Zeitfenster (UTC): Outage-Beginn, Repair-Zeitpunkt, Restore, Stabilitätsfenster.
• OTDR: Parameter (Wellenlänge, Puls, IOR, Range), Trace(s), Eventliste.
• Loss/Margin: End-to-End Loss oder PowerMargin, Vorher/Nachher.
• Qualität: FEC/BER/Errors, OSNR/SNR/Q (falls vorhanden).
• Service Lens: Loss/Latenz/Reachability, Traffic-Rückführungsschritte.
• Field Notes: Art der Reparatur (Spleiß, Umverlegung, Reserve-Loop), Fotos wenn möglich.

Häufige Post-Repair-Fallen und Gegenmaßnahmen

• Nur OTDR, kein Loss-Test: Ereignisse sichtbar, aber Budget unklar → End-to-End Loss oder Margin muss geprüft werden.
• Kein Stabilitätsfenster: Second Outage nach Cleanup → Gate-Kriterien und Dauerfenster verpflichtend.
• Uncorrectables ignoriert: „wird schon“ endet als erneuter Incident → Uncorrectables als Hard Stop.
• Connector-Cleanliness vergessen: Repair löst Cut, aber Patch erzeugt Degradation → Inspect-Before-Connect als Pflicht.
• Diversity nicht revalidiert: Repair koppelt Pfade → SRLG-/Diverse-Check nach Trassenarbeiten.

Outbound-Ressourcen

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

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.