CRS328 mit einem Alcatel-Lucent G-010S-P GPON-Stick: nur TX, kein RX, Wellenlänge zeigt 33685 nm
Ich löse meine private FTTH-Leitung vom ONT des Betreibers ab und stecke sie stattdessen auf einen GPON-Stick im eigenen Router, damit die Faser direkt im Rack landet und ich statt zwei Boxen nur eine habe. Der Stick wird erkannt, der Port kommt hoch, und dann kommt nichts mehr zurück.
- MikroTik CRS328-24P-4S+, Stick in sfp-sfpplus1
- Alcatel-Lucent G-010S-P GPON-ONU
- Bell Canada FTTH, Faser von der Wanddose direkt ins Modul
- Port festgenagelt, Autoneg aus:
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXDie TX-Zähler steigen, die RX-Zähler bleiben bei null, und die Modulseite zeigt das hier:
wavelength: 33685.00nmWas ich schon gemacht habe:
- den Anschluss neu gesteckt und gereinigt, einen zweiten SFP+-Käfig probiert
- die Faser komplett herausgezogen - der Wellenlängenwert ändert sich nicht, mit oder ohne
- den Port für eine Stunde bei 1G festgenagelt gelassen, falls es ein langsames Ranging ist
Also: Ist 33685.00nm ein Beleg dafür, dass die Optik in diesem Stick tot ist, oder decodiert der Switch dieses EEPROM-Feld für ein GPON-Modul einfach falsch? Und muss auf der Betreiberseite etwas passieren, bevor ein SFP-ONU überhaupt rangen darf?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
In deinem Beitrag stecken zwei getrennte Dinge, und nur eines davon ist ein Fehler.
Das 33685.00nm ist ein Decodierungsartefakt, keine Messung. Diese Sticks arbeiten mit zwei Wellenlängen - 1310 upstream, 1490 downstream -, und der Switch liest aus dem EEPROM ein einzelnes Wellenlängenfeld aus, als wäre es ein gewöhnlicher Transceiver mit einem Laser. Denselben Wert siehst du auch bei einem Stick, der munter Traffic durchlässt, als Diagnose ist er also nutzlos. Leg das beiseite.
Der Einbahn-Traffic ist das eigentliche Problem des Geräts. Ich bin genau das am selben Switch durchgegangen, einem CRS328-24P-4S+: Der G-010S-P sendete und empfing nie etwas, und die Leitung kam in dem Moment hoch, in dem ich ein anderes Modul aus derselben Familie eingesetzt habe - ein O-010S-P, die Variante für erweiterten Temperaturbereich. Gleicher Account, gleiche Faser, keine Konfigurationsänderung. Der erste Stick war also entweder defekt oder die falsche Variante für diese Leitung.
Lass den Port beim Testen festgenagelt, sonst führst du eine zweite Variable ein:
Mit ALCLFAB in der Seriennummer und dem bereits auf ein SFP-ONU umgestellten Account ist deine Betreiberhälfte erledigt. Besorg dir einen zweiten Stick, bevor du noch einen Abend in diesen hier steckst.
Bevor du die Optik abschreibst, prüf die langweilige Hälfte. Bei vielen FTTH-Accounts ist ein SFP-ONU kein einfacher Ersatz für die Box des Betreibers: Der Account muss von Hand dafür neu provisioniert werden, und manche Betreiber akzeptieren nur ein Modul, dessen Seriennummer ihr eigenes Herstellerpräfix trägt. TX ohne jede Rückmeldung sieht von der Teilnehmerseite aus genau so aus wie ein ONU, das nicht autorisiert wurde.
Poste, was der Stick für Hersteller und Seriennummer meldet, und sag, was du auf der WAN-Seite konfiguriert hast - VLAN-Tag, PPPoE oder DHCP.
Die Seriennummer beginnt mit ALCLFAB, das ist hier bei einem Business-FTTH-Account das gewünschte Präfix. Der Account wurde auch manuell für ein SFP-ONU umkonfiguriert - dafür brauchte es einen Anruf, die erste Hotline-Ebene hatte keine Ahnung, wonach ich überhaupt fragte.
Router-seitig liegt VLAN 35 auf dem SFP-Port, darüber ein PPPoE-Client. Der Client kommt nie über Discovery hinaus. Die RX-Zähler sind weiter flach, und die Anzeige bleibt unverändert bei 33685.00nm, egal ob die Faser eingesteckt ist oder nicht.
Um den Punkt mit der Wellenlänge zu erweitern: Das Feld, das der Switch liest, liegt im SFF-8472-Bereich und wurde für ein Modul mit einem Laser definiert. Ein GPON-ONU hat einen Burst-Mode-Sender und einen Empfänger auf unterschiedlichen Wellenlängen, es gibt also keinen einzigen korrekten Wert, der dort hingehört, und die Hersteller schreiben hinein, was ihnen passt. Nichts im Standard verpflichtet den Host, dieses Byte vor der Anzeige plausibilitätszuprüfen, und so kommt man auf fünfstellige Nanometer.
Dieselbe Logik gilt für die Angaben zur optischen Leistung bei diesen Sticks. Wer wissen muss, wie es der PON-Seite geht, holt sich das aus dem eigenen Status des ONU, nicht von der Diagnoseseite des Switches.
Lohnt sich zu sagen, dass die Host-Seite davon keine MikroTik-Eigenheit ist. Bei der 7210-SAS-Familie ist die Herstellerdokumentation da unverblümt: Die frühen Releases implementierten DDM überhaupt nicht, Ports zeigen also auch bei Modulen, die es unterstützen, keine optische Leistung oder Temperatur, und man wird angewiesen zu prüfen, welches Release die Funktion für die eigene Variante hinzufügt. Für Module, die der Hersteller nicht selbst geliefert hat, sagt dieselbe Anleitung, dass Diagnosewerte angezeigt werden können, übernimmt aber keine Verantwortung für deren Formatierung oder Richtigkeit.
Es gibt auch ein Capability-Flag im Modul-EEPROM, das entscheidet, ob die Plattform ein SFP als DDM-fähig behandelt, und Module, die es nicht setzen, können trotzdem plausibel aussehende Zahlen ausgeben, die niemand validiert hat.
show port <port> detailist dort die Stelle, wo man es abliest. Einen Drittanbieterwert auf dieser Box behandle ich als Hinweis, nie als Messung - ungefähr die Haltung, die deine 33685 verdient.Zum Abschluss: Ein zweiter Stick hat es behoben. Ich habe ein O-010S-P eingesetzt, der PPPoE-Client kam innerhalb einer Minute auf VLAN 35 hoch, keine Änderungen auf der Betreiberseite und nichts an der Port-Konfiguration angefasst. Der alte G-010S-P macht in einem anderen Käfig dasselbe Nur-TX-Ding, für mich ist er also tot.
Und ja, das funktionierende Modul meldet ebenfalls 33685.00nm. Bin froh, dass ich nicht die ganze Woche dieser Zahl hinterhergejagt bin.