Realistische DOM/DDM-Thresholds: Damit Alarme nicht „schreien“

Realistische DOM/DDM-Thresholds sind eine der wichtigsten Stellschrauben, um Alarmrauschen im optischen Betrieb zu reduzieren, ohne Frühwarnsignale zu verlieren. DOM (Digital Optical Monitoring) bzw. DDM (Digital Diagnostic Monitoring) liefert Telemetrie direkt aus Transceivern und Optikmodulen: Rx/Tx-Power (dBm), Temperatur, Versorgungsspannung, Laser-Bias-Strom und je nach Plattform zusätzliche optische Qualitätswerte. In ISP-, Telco- und Backbone-Umgebungen ist DOM oft die erste Datenquelle, die eine schleichende Degradation sichtbar macht – noch bevor ein Link flappt oder FEC/BER/CRC-Effekte eskalieren. Gleichzeitig ist DOM berüchtigt dafür, „zu schreien“: Default-Grenzwerte aus Datenblättern sind konservativ, Messungen sind nicht bei allen Optiken gleich genau, und Umgebungsbedingungen (Temperatur, Patchfeldbewegung, Dämpfungsdrift) führen zu Schwankungen, die im Betrieb normal sind. Wenn Sie diese Realität ignorieren, paged der NOC ständig „Low Rx Power“ oder „High Temp“, ohne dass ein Incident entsteht. Die Folge ist Alarmmüdigkeit, langsame Reaktion auf echte Ausfälle und eine Kultur, in der optische Signale nicht mehr ernst genommen werden. Dieser Leitfaden zeigt praxisnah, wie Sie DOM/DDM-Thresholds so festlegen, dass sie zu Ihrem Netz passen: basierend auf Baselines statt starrer Zahlen, differenziert nach Optikklasse und Fault Domains, mit Hysterese, Dauerbedingungen, Korrelation zu FEC/CRC und einer Governance, die Thresholds kontinuierlich verbessert.

DOM/DDM kurz erklärt: Was gemessen wird und warum es variiert

DOM/DDM ist keine „perfekte Messstation“, sondern ein integrierter Diagnosekanal des Transceivers. Typischerweise sind diese Werte verfügbar:

• Rx Optical Power (dBm): empfangene optische Leistung, häufig der wichtigste Frühindikator für Loss/Drift.
• Tx Optical Power (dBm): gesendete optische Leistung, nützlich für Laser-Drift und Modulgesundheit.
• Temperature (°C): Modultemperatur; relevant für Alterung, Laser-Drift und Umgebungseinflüsse.
• Voltage (V): Versorgung; kann auf Hardware-/PSU-Probleme hinweisen.
• Laser Bias Current (mA): Treiberstrom; steigt oft bei alternden Lasern, aber herstellerabhängig.

Wichtig für Threshold-Design: DOM-Messgenauigkeit und Normalbereiche unterscheiden sich je nach Optiktyp (z. B. SR/LR/ER/ZR), je nach Wellenlänge und je nach Plattform. Zudem ist Rx-Power nicht nur eine Funktion der Trasse, sondern auch von Patchfeldern, Steckern, Biegeradien und Temperatur. Deshalb sind „Datenblattgrenzen“ allein selten die besten Alarmgrenzen im Betrieb. Für grundlegende optische PHY-Kontexte und Terminologie kann IEEE 802.3 als Ausgangspunkt dienen.

Warum Default-Thresholds Alarmrauschen erzeugen

Viele Teams übernehmen die „High Alarm/Low Alarm“-Grenzen aus Modulspezifikationen oder aus Geräte-Defaults. Das ist nachvollziehbar, aber im Betrieb meist zu grob. Typische Gründe, warum Default-Thresholds zu viel Alarm erzeugen:

• Konservative Datenblattwerte: Hersteller geben Grenzen an, die für viele Umgebungen passen sollen, aber nicht Ihre reale Linkmarge abbilden.
• Keine Berücksichtigung der Linkmarge: Ein Rx-Power-Wert nahe „Low Alarm“ kann trotzdem stabil sein, wenn FEC/BER/CRC perfekt sind und die Margin konstant bleibt.
• Keine Hysterese: Werte schwanken um die Grenze, Alarme flappen.
• Keine Dauerbedingung: kurze Spikes lösen Pager aus, obwohl sie keine Relevanz haben.
• Keine Segmentierung: ein globaler Threshold ignoriert, dass kurze Links Overpower-riskant sind und lange Links Underpower-nah arbeiten.

Grundprinzip: Betriebs-Thresholds sind nicht Datenblatt-Thresholds

Ein realistischer Ansatz trennt zwei Ebenen:

• Hardware-Grenzen (Data Sheet Limits): harte Grenzen, bei denen das Modul außerhalb Spezifikation arbeitet (z. B. Rx < Rx_min, Temp > Temp_max).
• Betriebsgrenzen (Operational Thresholds): Grenzen, die früher warnen sollen, aber nur dann alarmieren, wenn ein Trend oder eine Korrelation auf ein echtes Risiko hinweist.

In der Praxis sollte die Pager-Alarmierung primär auf Betriebsgrenzen liegen, die aus Baselines und Trends abgeleitet sind. Hardware-Grenzen eignen sich eher als „kritische“ Alarme (z. B. SEV1), weil sie oft bereits nahe am Ausfall sind.

Schritt 1: DOM-Thresholds nach Optikklassen und Linktypen gruppieren

Der größte Hebel gegen Alarmrauschen ist, nicht alle Optiken gleich zu behandeln. Ein LR-Modul auf 10 km verhält sich anders als ein ER/ZR-Modul auf langen Strecken, und ein kurzer Data-Center-Link hat andere Risiken als eine Metro-Spur. Sinnvolle Gruppen:

• Optikklasse: SR, LR, ER, ZR/Coherent (oder vendor-spezifische Klassen)
• Linklänge-Kategorie: kurz (Overpower-Risiko), mittel, lang (Underpower-Risiko)
• Umgebung: PoP/ODF-lastig, Outdoor/Street Cabinet, Datacenter
• Fault Domain: ring_id/srlg_id/pop_id, wenn Sie drift-Cluster erkennen wollen

Damit reduzieren Sie die Varianz innerhalb einer Gruppe und können realistische Schwellen definieren, ohne zu stark zu generalisieren.

Schritt 2: Baseline statt Fixwert: Normalband pro Link bestimmen

Für Rx-Power, Temperatur und Bias ist ein Normalband pro Link oft wirkungsvoller als ein globaler Fixwert. Das Normalband basiert auf historischen Messungen eines stabilen Zeitraums (z. B. 7–30 Tage). Aus diesem Band leiten Sie operative Warnschwellen als Abweichung ab.

Baseline-Band als robustes Konzept

• BaselineMedian: typischer Normalwert
• BaselineSpread: typische Schwankung (z. B. Perzentilband P10–P90)
• Delta-Threshold: Alarm, wenn aktuelle Werte dauerhaft außerhalb des Bands liegen

Delta-Rx als Frühindikator (MathML)

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

Ein DeltaRx von −1 dB kann in manchen Netzen schon relevant sein (z. B. bei knapper Linkmarge), in anderen ist es normal (z. B. bei Temperaturdrift). Genau deshalb ist der baselinebezogene Ansatz so stark: Er passt sich pro Link an.

Schritt 3: Alarmieren auf „Margin“, nicht nur auf absolute Rx-Power

Ein Rx-Power-Wert ist erst dann wirklich aussagekräftig, wenn Sie ihn in Relation zur minimal zulässigen Empfangsleistung setzen. Die daraus abgeleitete Margin ist eine intuitive Betriebskennzahl: Wie viel Reserve bleibt bis zur Sensitivität?

PowerMargin (MathML)

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

• Warnung: PowerMargin sinkt unter ein betrieblich definiertes Minimum (z. B. „nur noch 2 dB Reserve“).
• Kritisch: Rx nähert sich Rx_min oder unterschreitet sie.
• Vorteil: Links mit unterschiedlicher Optikklasse werden vergleichbarer.

Wenn Sie Rx_min nicht sauber inventoryseitig haben, können Sie ersatzweise mit einem internen „Target-Minimum“ arbeiten, der aus Erfahrung pro Optikgruppe abgeleitet ist. Für faser- und linkbezogene Grundlagen kann ITU-T G.652 als Referenz dienen.

Schritt 4: Hysterese und Dauerbedingungen einführen, um Flapping zu vermeiden

DOM-Werte schwanken. Ohne Hysterese und Dauerbedingungen erzeugen Sie Alarmflapping. Zwei Mechanismen sind besonders effektiv:

• Hysterese: Alarm schaltet erst wieder aus, wenn der Wert deutlich zurück im Normalbereich ist.
• Dauerbedingung: Alarm nur, wenn die Bedingung über einen Zeitraum erfüllt ist (z. B. 10 Minuten).

Beispiel: „Low Rx“ mit Dauer + Hysterese

• Trigger: PowerMargin < 2 dB für ≥ 10 Minuten
• Clear: PowerMargin > 3 dB für ≥ 10 Minuten

Dieses Prinzip reduziert „kurze Dips“ (z. B. beim Rebalancing) und fokussiert auf echte Drift.

Schritt 5: DOM mit FEC/Errors korrelieren, bevor Sie pagern

Rx-Power alleine ist ein Frühindikator, aber nicht immer ein Incident. Die beste Praxis ist, DOM-Alarme mit mindestens einem Qualitätsindikator zu korrelieren, bevor der Pager losgeht. In Transport- und IP-Backbones eignen sich dafür:

• FEC CorrectedRate: steigt die Korrektur deutlich über Baseline?
• Uncorrectables: treten unkorrektierbare Fehler auf?
• CRC/PCS Errors: steigen Ethernet-Fehlerzähler an?
• Service-Lens: steigen Loss/Latenz/Timeouts in der betroffenen Fault Domain?

Composite-Alert-Logik (MathML)

$\mathrm{Page}\Leftarrow \mathrm{PowerMarginLow}\wedge \mathrm{FEC}\_\mathrm{CorrectedRateHigh}$

So verhindern Sie, dass ein knappes, aber stabiles Linkbudget ständig alarmiert, während Sie gleichzeitig echte Degradation früh erkennen.

Realistische Thresholds pro Messgröße

DOM umfasst mehrere Messgrößen. Nicht jede ist gleich gut alarmierbar. Die folgenden Abschnitte zeigen, wie Sie pro Messgröße realistische Schwellenlogik definieren.

Rx Optical Power: Drift und Margin als Standard

• Warnung (trendbasiert): DeltaRx < −X dB über Y Stunden oder PowerMargin sinkt unter betriebliches Minimum.
• Kritisch (hard): Rx < Rx_min oder dauerhaft nahe Rx_min, besonders wenn FEC/Errors steigen.
• Overpower (kurze Links): Rx nahe oder über Rx_max; eher selten, aber gefährlich, weil Sättigung sporadische Fehler erzeugen kann.

Overpower wird häufig vergessen. Gerade bei sehr kurzen Strecken kann ein „zu starker“ Sender zu instabiler Qualität führen. Deshalb gehört Rx_max (falls bekannt) in Ihre Prüfung, auch wenn es selten alarmiert.

Tx Optical Power: eher Diagnose als Pager

• Warnung: Tx driftet deutlich gegenüber Baseline (z. B. Laser altert, Temperaturproblem).
• Kritisch: Tx fällt plötzlich stark ab oder fluktuiert (kann auf Moduldefekt hindeuten).

Tx-Power eignet sich oft besser als Diagnose- und Korrelationssignal, weil der End-to-End-Effekt auf Rx und FEC stärker sichtbar ist. Tx-Alarme allein erzeugen häufig Noise, wenn sie nicht trendbasiert sind.

Temperatur: Umgebungskontext und Zeitfenster sind Pflicht

• Warnung: Temperatur steigt über typisches Normalband und bleibt dort (z. B. 30–60 Minuten).
• Kritisch: Annäherung an Modul-Maximum oder plötzliche Temperaturspitzen (PoP-Klimaproblem).
• Korrelation: Temperaturspike plus Rx/BER/FEC-Verschlechterung ist deutlich aussagekräftiger als Temperatur allein.

Temperaturalarme „schreien“ oft in Outdoor- oder dicht bestückten PoPs. Der Schlüssel ist Baseline + Dauerbedingung. Wenn Sie die PoP-Umgebung (Rack-Sensoren) ebenfalls haben, lohnt sich die Korrelation, um echte Klimaprobleme von normalen Tageszyklen zu trennen.

Laser Bias Current: nur sinnvoll mit Baseline und Optikklasse

• Warnung: Bias steigt langfristig gegenüber Baseline (Alterung) oder springt nach Wartung.
• Kritisch: Bias nahe Modulgrenze oder kombiniert mit Tx-Drift/Unstable Tx.

Bias ist hersteller- und plattformabhängig. Als Pager-Alarm ist er oft zu „noisy“, aber als langfristiger Health-Indikator (Predictive Maintenance) sehr wertvoll, wenn sauber baselinebasiert.

Spannung: selten, aber wichtig bei Hardwareproblemen

• Warnung: Spannung driftet außerhalb Normalband (kann auf PSU/Rack-Strom hinweisen).
• Kritisch: Spannung nahe Modul-Min/Max und gleichzeitig mehrere Module betroffen (Hinweis auf Chassis/Linecard/PSU).

DOM-Alarmstufen: Info, Warnung, Kritisch – mit klarer Aktion

Damit Alarme nicht „schreien“, braucht jede Stufe eine klare Bedeutung und eine klare Aktion. Ein bewährtes Modell:

• Info (Dashboard/Event): Abweichung klein, keine Korrelation zu Qualitätsproblemen; dient Beobachtung.
• Warnung (Ticket/Notify): Drift signifikant oder Margin sinkt; es gibt ein klares Follow-up (Reinigung, OTDR, Maintenance-Plan).
• Kritisch (Page): Hard-Limits oder Korrelation zu FEC/CRC/Service-Impact; sofortige Mitigation/Dispatch erforderlich.

Wichtig: Ohne Aktion ist ein Alarm nicht reif. DOM-Warnungen sollten fast immer mit einer konkreten Checkliste verknüpft sein (Inspect/Clean, Patch prüfen, OTDR, Carrier-Ticket).

Runbook-Snippets: Was beim DOM-Alarm geprüft werden sollte

Damit DOM-Thresholds zu besseren Outcomes führen, sollten Sie kurze Runbook-Schritte definieren, die in Minuten ausführbar sind.

Wenn „Rx-Power Drift“ feuert

• Trend prüfen: DeltaRx über 24h/7d, nicht nur aktuellen Wert.
• FEC/BER/CRC-Korrelation prüfen (steigt CorrectedRate oder Errors?).
• Scope prüfen: Einzelport oder Cluster in gleicher ring_id/srlg_id/pop_id?
• Letzte Changes/Maintenance prüfen: Patcharbeiten, ODF, Transceiverwechsel.
• Wenn PoP-nah: Inspect-Before-Connect, Reinigung/Neu-Patch planen.

Wenn „Uncorrectables“ oder „CRC-Spikes“ auftreten

• Sofort-Kritikalität: Uncorrectables > 0 als red flag behandeln.
• Traffic stabilisieren: Schutzpfad/Traffic Shift, falls Kundenimpact droht.
• Physische Checks priorisieren: Stecker, Patch, ODF, ggf. OTDR.

Anti-Patterns: Warum DOM-Alarmierung häufig scheitert

• Ein Threshold für alles: ignoriert Optikklassen, Linklängen und Umgebung.
• Nur Hard-Limits: erzeugt entweder späte Alarme oder dauerhaftes „knapp aber stabil“ Geschrei.
• Keine Hysterese: Alarmflapping frisst Aufmerksamkeit.
• Keine Korrelation: Rx-Alarm paged, obwohl FEC/CRC/Service stabil sind.
• Keine Governance: niemand besitzt Thresholds; Noise bleibt dauerhaft.

Governance: Thresholds als lebendes System, nicht als einmalige Einstellung

Realistische DOM/DDM-Thresholds entstehen selten „in einem Projekt“, sondern durch einen kontinuierlichen Verbesserungsprozess. Ein praxistauglicher Ansatz ist ein monatlicher Review-Zyklus:

• Top-N noisy DOM Alerts: welche Alarmtypen erzeugen die meisten Events ohne Incident?
• False-Positive Review: welche Alarme hatten keine Korrelation zu FEC/CRC/Impact?
• Missed Signals: gab es Incidents, bei denen DOM früh hätte warnen können?
• Threshold Update: Anpassungen pro Optikgruppe/Fault Domain, dokumentiert und versioniert.
• Runbook Update: wenn der Alarm bleibt, muss die Aktion besser werden.

Wenn Sie Incident-Response-Prozesse und Kommunikationsdisziplin als Rahmen nutzen wollen, sind Ressourcen wie PagerDuty Incident Response und das Google SRE Workbook: Incident Response hilfreich, um Verantwortlichkeiten und Review-Routinen zu strukturieren.

Outbound-Ressourcen

• IEEE 802.3 (Ethernet-Standards, optische PHY-Kontexte)
• ITU-T G.652 (Singlemode-Fasergrundlagen)
• The Fiber Optic Association (FOA): Best Practices, Handling und Safety
• Fluke Networks: Fiber Optics Knowledge Base (Inspection/Cleaning/Testing)
• Google SRE Workbook: Incident Response

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.