Das Hauptkeyword „Optische Degradation diagnostizieren“ beschreibt eine der wichtigsten Fähigkeiten im Betrieb von Provider- und Data-Center-Transportnetzen: Links fallen nicht immer hart aus, sondern werden oft schleichend schlechter. Genau diese schleichenden Fehler sind gefährlich, weil sie sich in höheren OSI-Schichten als „sporadische“ Symptome zeigen – kurze Paketverluste, erhöhte Latenzen, Flaps von Routing-Sessions oder instabile Services. Auf Layer 1 und im optischen Transport liefert jedoch die Fehlerstatistik frühzeitig belastbare Hinweise: BER (Bit Error Rate), FEC (Forward Error Correction) und die richtigen Error Counter machen Degradation messbar, bevor sie zum Outage wird. Wer dabei nur auf Rx-Power oder „Link up“ schaut, übersieht häufig das eigentliche Problem: Das Signal kann ausreichend stark sein, aber qualitativ so verrauscht oder verzerrt, dass die Fehlerkorrektur an ihre Grenzen kommt. Dieser Artikel zeigt, wie Sie optische Degradation systematisch diagnostizieren, welche Counter wirklich aussagekräftig sind, wie Sie Pre-FEC und Post-FEC BER richtig interpretieren, wie Sie FEC-Statistiken in ein operatives Ampelsystem übersetzen und wie Sie aus Zählern, Trends und Baselines eine saubere RCA ableiten.
Was „optische Degradation“ im Betrieb wirklich bedeutet
Optische Degradation ist kein einzelnes Ereignis, sondern ein Zustand, in dem die Signalqualität kontinuierlich oder intermittierend abnimmt. Der Link kann dabei weiterhin „up“ sein und sogar nominale Rx-Werte liefern, während die Fehlerhäufigkeit steigt. Typische Auswirkungen sind:
- Intermittierender Paketverlust: sichtbar als Retransmits, TCP-Timeouts oder sporadische Drops in QoS-Queues.
- FEC-Last steigt: Vorwärtsfehlerkorrektur muss immer mehr Bits korrigieren, bis die Reserve aufgebraucht ist.
- Erhöhte Latenz und Jitter: durch Wiederholungen, Pufferung, oder Schutzmechanismen in Transportpfaden.
- „Phantom“-Störungen: Symptome treten nur unter Last, bei bestimmten Temperaturen oder Tageszeiten auf.
Wichtig ist die Einordnung: Degradation ist häufig ein Layer-1/Transport-Problem, das sich erst später als Layer-3/Serviceproblem manifestiert. Genau deshalb sind BER und FEC im NOC ein Frühwarnsystem.
Grundlagen: BER verständlich erklärt und operational nutzbar gemacht
Die Bit Error Rate (BER) beschreibt den Anteil falsch übertragener Bits an allen übertragenen Bits. In der Praxis wird BER oft als wissenschaftliche Zahl wahrgenommen, ist aber operativ sehr nützlich, wenn man sie korrekt interpretiert. Formal gilt:
Für den Betrieb ist weniger die exakte Zahl entscheidend als die Entwicklung über Zeit und die Relation zu Grenzwerten des jeweiligen Systems. Viele Plattformen unterscheiden dabei zwei Perspektiven:
- Pre-FEC BER: Fehler vor der Fehlerkorrektur – ein Indikator für die Rohqualität des optischen Signals.
- Post-FEC BER: Fehler nach der Fehlerkorrektur – ein Indikator, ob die Korrektur noch ausreichend wirkt.
Ein Link kann eine schlechte Pre-FEC BER haben und trotzdem eine sehr gute Post-FEC BER, solange die FEC genügend Reserve hat. Genau dort beginnt die operative Frage: Wie viel Reserve bleibt noch, bevor es kritisch wird?
FEC im Transportnetz: Warum Fehlerkorrektur nicht „magisch“ ist
Forward Error Correction (FEC) ist ein Mechanismus, der zusätzliche Redundanzdaten überträgt, damit der Empfänger Fehler erkennen und korrigieren kann, ohne eine Neuübertragung anzufordern. Das ist für optische Systeme besonders wichtig, weil Neuübertragungen auf physischer Ebene nicht praktikabel sind. FEC hat jedoch Grenzen: Wenn das Rauschen oder die Verzerrung zu groß wird, kann die Korrektur fehlschlagen und die Post-FEC Fehler steigen.
In der Praxis sehen Sie FEC als Zähler und Zustände, je nach Plattform und Modultyp (klassische Ethernet-Optiken, kohärente Transponder, DWDM-Transport). Eine hilfreiche technische Einordnung von FEC im optischen Transport liefert die OTN-Empfehlung ITU-T G.709 (OTN interfaces), die unter anderem Rahmenbedingungen für Transportstrukturen und Fehlerüberwachung beschreibt.
Die wichtigsten Counter: Welche Fehlerzähler im Incident wirklich helfen
Viele Systeme bieten Dutzende Counter. Provider-Grade Diagnosen konzentrieren sich auf wenige, aussagekräftige Kategorien. Entscheidend ist dabei: Sie brauchen Zähler, die zwischen „korrigierten“ und „unkorrigierbaren“ Fehlern unterscheiden.
- Pre-FEC BER (oder gleichwertige Qualitätsmetriken): Rohsignalqualität; besonders wertvoll als Trend (Drift) und für Vergleich gegen Baseline.
- Post-FEC BER: Signalqualität nach Korrektur; kritisch, wenn sie von „nahe null“ auf messbare Werte steigt.
- FEC corrected codewords/blocks: Anzahl korrigierter Blöcke; ein Frühindikator, der oft lange vor Ausfällen steigt.
- FEC uncorrectable codewords/blocks: unkorrigierbare Blöcke; starkes Zeichen, dass die FEC-Grenze erreicht wird.
- Errored Seconds (ES) / Severely Errored Seconds (SES): Zeitbasierte Qualitätsindikatoren, die für SLA-nahe Aussagen besonders nützlich sind.
- LOS/LOF/OOF (Loss of Signal/Frame/…): harte Layer-1/Transportereignisse, häufig bei Cuts, starken Dämpfungssprüngen oder Modulproblemen.
Wenn Sie Ethernet-Transport betrachten, sind die Grundlagen der physischen Übertragung und Fehlerüberwachung im Umfeld von Ethernet in den IEEE-Standards verankert, z. B. über den Anchor-Text IEEE 802.3 (Ethernet) als generelle Referenz.
Pre-FEC vs Post-FEC: So vermeiden Sie Fehlinterpretationen
Ein verbreiteter Fehler ist, Pre-FEC Werte als „sofort kritisch“ zu lesen, obwohl Post-FEC noch perfekt ist. Die richtige Lesart ist schicht- und risikoorientiert:
- Pre-FEC steigt langsam, Post-FEC bleibt gut: Degradation im Anmarsch. Noch kein Outage, aber die Reserve sinkt. Ursachen finden, bevor weitere Drift entsteht.
- Pre-FEC steigt sprunghaft, corrected counter explodieren: akutes Ereignis (z. B. verschmutzter Stecker, Makrobiegung, neue Patchung). Sofortige Eingrenzung sinnvoll.
- Post-FEC wird messbar oder uncorrectables treten auf: sehr kritisch. Hier ist die FEC-Wirkung nicht mehr ausreichend – Outage-Gefahr steigt stark.
Operativ bedeutet das: Pre-FEC ist Ihr Frühwarnsignal, Post-FEC Ihr Stabilitätsnachweis. Corrected/uncorrectable Zähler liefern die Beweiskette dazwischen.
Errored Seconds als Brücke zwischen Technik und SLA
Während BER-Werte oft als „zu technisch“ wirken, sind zeitbasierte Metriken wie ES und SES hervorragend, um Qualitätsprobleme in betriebliche und SLA-nahe Aussagen zu übersetzen. Die Idee: Statt einzelne Fehlerbits zu zählen, bewertet man, ob innerhalb einer Sekunde die Fehlerlage einen definierten Schwellwert überschreitet.
- ES (Errored Seconds): Sekunden, in denen Fehler auftraten (je nach Definition des Systems).
- SES (Severely Errored Seconds): Sekunden mit starkem Fehlerniveau, oft ein deutlicher Indikator für sichtbare Serviceauswirkungen.
Im War-Room sind ES/SES hilfreich, weil sie die Frage „Ist das nur ein Counter oder hat es Impact?“ schneller beantworten. In RCAs sind ES/SES wertvoll, um Zeitlinien und Impact-Fenster sauber zu belegen.
Trend statt Momentaufnahme: Warum Delta-Counter im NOC Pflicht sind
Ein Zählerstand allein sagt wenig. Entscheidend ist die Veränderung über Zeit: Steigen die corrected codewords pro Minute? Gibt es Peaks zu bestimmten Uhrzeiten? Passt das zu Temperatur, Last oder Wartungsarbeiten? Provider-Grade Diagnosen arbeiten deshalb mit Delta-Betrachtungen:
- Delta pro Zeitfenster: z. B. corrected blocks pro 5 Minuten statt absoluter Gesamtsumme.
- Baseline-Vergleich: aktuelles Verhalten gegen „Normal“ für genau diesen Link (nicht gegen generische Werte).
- Korrelation: Abgleich mit Optikwerten (Rx/Tx), OSNR/Q-Metriken, L1 Events, sowie Pfad-/Service-Symptomen.
Ein praktischer Ansatz ist ein „Drift-Indikator“, der die Abweichung zur Baseline quantifiziert:
So können Sie Alarmierung auf „Veränderung“ bauen, nicht nur auf harte Grenzwerte, die oft zu spät auslösen.
Typische Ursachen optischer Degradation und welche Counter sie verraten
Die Kunst der Diagnose liegt darin, Counter-Muster mit realen Fehlerursachen zu verbinden. Die folgenden Ursachen sind im Telco-Alltag besonders häufig:
- Verschmutzte oder beschädigte Steckverbinder: corrected counter steigen, Pre-FEC verschlechtert sich; oft nach Patch-/Change-Arbeiten. Rx-Power kann dabei leicht fallen, muss aber nicht dramatisch sein.
- Makrobiegung / zu enger Biegeradius: Pre-FEC verschlechtert sich, häufig wellenlängenabhängig; corrected counter zeigen Peaks, die bei Bewegung/Temperatur variieren.
- Spleißprobleme oder neue Muffenarbeiten: dauerhaft erhöhter Verlust führt zu sinkender Margin; corrected counter steigen langfristig, besonders wenn das Budget knapp ist.
- Alterung oder Drift von Optikmodulen: Tx/Rx driftet, Pre-FEC wird schlechter; Fehlerkorrektur kompensiert zunächst, bis Reserve sinkt.
- WDM/Amplifier/Filter-Themen: OSNR/Q verschlechtert sich bei stabiler Rx-Power; corrected counter steigen, ohne dass „zu wenig Leistung“ sichtbar ist.
- Teilweise Faserbeschädigung (Quetschung, Feuchtigkeit): schleichender Trend, zunehmend corrected und später uncorrectable; ES/SES nehmen zu.
Für Fasereigenschaften und typische Dämpfungsparameter im Singlemode-Bereich ist ITU-T G.652 eine stabile Referenz, weil sie die Rahmenbedingungen vieler Carrier-Strecken beschreibt.
OSNR, Q-Metriken und BER: Wie Sie Qualitätskennzahlen richtig kombinieren
In DWDM- und kohärenten Systemen ist BER häufig nicht allein durch Rx-Power erklärbar. OSNR (Optical Signal-to-Noise Ratio) und Q-basierte Qualitätsmetriken sind dann entscheidend, um zu verstehen, ob das Signal „sauber“ genug ist. Die operative Kombination ist:
- Rx-Power: Budget und Übersteuerung prüfen (Leistungsebene).
- OSNR/Q: Qualitätsreserve prüfen (Rauschen, Filter, Verstärker, Kanalplanung).
- Pre-FEC / corrected: zeigt, wie stark die Korrektur arbeiten muss (Arbeitslast der FEC).
- Post-FEC / uncorrectable / SES: zeigt, ob Kundenimpact wahrscheinlich ist (Stabilitätsgrenze).
Wenn Rx-Power „gut“ ist, OSNR aber fällt und corrected counter steigen, ist eine rein mechanische „Stecker putzen“-Aktion oft nicht die beste erste Maßnahme. Dann sollte die Fault Domain eher im optischen Transportpfad (Amplifier/ROADM/Kanalbelegung) gesucht werden.
Ein operatives Ampelsystem: Von Countern zur Entscheidung
Damit Counter nicht nur Daten bleiben, braucht es ein einfaches Entscheidungsmodell. Ein bewährter Ansatz ist ein Ampelsystem, das sich an Trends und an der Nähe zur FEC-Grenze orientiert:
- Grün: Post-FEC nahe null, uncorrectables = 0, ES/SES stabil, corrected niedrig und ohne Trend.
- Gelb: corrected steigt deutlich gegenüber Baseline, Pre-FEC driftet, aber Post-FEC bleibt gut; keine SES-Spikes. Aktion: Ursachenanalyse und präventive Maßnahmen planen.
- Rot: uncorrectables treten auf oder Post-FEC wird messbar; SES-Spikes oder sichtbarer Impact. Aktion: sofortige Mitigation (Traffic-Shift/Protection), schnelle physische Prüfung, ggf. Field Dispatch.
Das Ziel ist nicht, jede Abweichung zu „incidentisieren“, sondern frühzeitig die Links zu identifizieren, die in den nächsten Tagen oder Wochen ein Outage-Risiko darstellen.
Diagnose-Workflow im Incident: Schrittfolge, die reproduzierbar funktioniert
Eine gute Diagnose ist schnell, aber auch dokumentierbar. Ein praxisnaher Workflow zur optischen Degradation:
- Schritt 1: Symptomkontext: Welche Services/Links sind betroffen, seit wann, kontinuierlich oder sporadisch?
- Schritt 2: Counter-Deltas: corrected/uncorrectable, Pre-FEC/Post-FEC, ES/SES als Zeitreihe.
- Schritt 3: Power & Budget: Rx/Tx in dBm gegen Baseline und spezifizierte Bereiche prüfen; Margin-Verlust erkennen.
- Schritt 4: Qualitätsmetriken: OSNR/Q (falls verfügbar) gegen Baseline prüfen, besonders bei WDM.
- Schritt 5: Korrelation: L1 Events (Flaps, LOS), Temperatur, Change-Aktivitäten, Patch-/Field-Arbeiten.
- Schritt 6: Eingrenzung & Aktion: lokal (PoP/Panel/Stecker), Strecke (Spleiß/Muffe), Transportpfad (Amplifier/ROADM), Modul (Transceiver) – und die risikoärmste Mitigation wählen.
Diese Schrittfolge ist bewusst so aufgebaut, dass sie in NOC-Runbooks, War-Rooms und später in RCAs wiederverwendet werden kann.
RCA sauber schreiben: Welche Belege bei optischer Degradation nicht fehlen dürfen
Bei Degradation ist die Beweiskette wichtiger als bei einem klaren Cut. Eine saubere RCA sollte deshalb nicht nur „Fehler behoben“ sagen, sondern nachvollziehbar zeigen, warum die Ursache plausibel ist. Mindestbestandteile:
- Zeitlinie: erste Anomalie, Anstieg corrected, Auftreten uncorrectables/SES, Mitigation, Repair, Stabilitätsnachweis.
- Messwerte: Pre-FEC/Post-FEC, corrected/uncorrectable, ES/SES, Rx/Tx, ggf. OSNR/Q – jeweils mit Baseline-Vergleich.
- Änderungskontext: Patchungen, Module gewechselt, WDM-Umkonfiguration, Field-Arbeiten, Bauarbeiten im Trassenbereich.
- Maßnahme und Wirkung: „Nach Reinigung/Neuspleiß/Modultausch sinken corrected counter sofort, Pre-FEC verbessert sich, SES verschwinden“.
Für eine strukturierte, faktenbasierte Postmortem-Kultur eignet sich als Orientierung Google SRE: Postmortem Culture, insbesondere für die Trennung von Beobachtung, Ursache, Mitigation und Prävention.
Fehlercounter, die häufig in die Irre führen
Nicht jeder Counter ist im Incident hilfreich. Einige Werte werden oft fehlinterpretiert oder sind ohne Kontext wenig aussagekräftig:
- Nur absolute Counterstände: ohne Delta und ohne Baseline kaum interpretierbar.
- CRC auf höheren Ebenen ohne L1-Kontext: CRC kann Folge von physischer Degradation sein, nicht Ursache; ohne Pre-FEC/FEC-Daten fehlt die Beweiskette.
- „Link up“ als Gesundheitsindikator: Degradation ist häufig ein Qualitätsproblem, kein Statusproblem.
- Rx-Power allein: Leistung erklärt Budget, aber nicht zwingend OSNR/Q und damit nicht die volle Fehlerlage in WDM.
Provider-Grade Diagnosen nutzen deshalb immer eine Kombination aus Leistung, Qualitätsmetriken und Fehlerstatistiken.
Praktische Checkliste: Optische Degradation schnell verifizieren
- Pre-FEC/Post-FEC prüfen: Trend statt Momentaufnahme; insbesondere Drift gegenüber Baseline.
- Corrected vs uncorrectable: corrected als Frühwarnsignal, uncorrectable als kritischer Grenzindikator.
- ES/SES einbeziehen: für Impact-Einschätzung und RCA-Zeitlinie.
- Rx/Tx und Budget: plötzliche Drops sind verdächtig, auch wenn der Wert noch im „grünen“ Bereich liegt.
- OSNR/Q (falls vorhanden): Qualität separat bewerten, insbesondere in DWDM/kohärenten Strecken.
- Korrelation mit Changes: Patch-/Field-Arbeiten sind häufige Trigger; Beweissicherung früh starten.
Outbound-Referenzen für Standards und fachliche Einordnung
- ITU-T G.709: OTN Interfaces und Transportüberwachung
- ITU-T G.652: Eigenschaften und Dämpfung von Singlemode-Fasern
- IEEE 802.3: Ethernet (physische Übertragung und Rahmenbedingungen)
- Google SRE: Postmortem Culture
Optische Degradation zu diagnostizieren heißt, aus BER, FEC und den richtigen Error Countern eine belastbare Geschichte zu machen: Was hat sich wann verändert, wie stark musste die Fehlerkorrektur arbeiten, und ab welchem Punkt wurde die Reserve kritisch? Pre-FEC zeigt die Rohsignalqualität, corrected counter zeigen die Arbeitslast der FEC, und uncorrectables sowie Post-FEC/SES markieren die Nähe zur Ausfallgrenze. Wenn diese Signale konsequent als Trends gegen Baselines bewertet und mit Rx/Tx sowie OSNR/Q korreliert werden, entstehen schnelle Entscheidungen im Incident und saubere RCAs im Nachgang. Genau so wird aus „der Link ist irgendwie komisch“ eine provider-taugliche Diagnose, die Degradation früh erkennt, Outages verhindert und die Stabilität optischer Transportinfrastruktur messbar verbessert.
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.












