CRS226 meldet no-link und sfp-rx-lose yes an einem Cisco-codierten SFP-10G-LR-Uplink
Wir haben einen kleinen Aggregationsstandort übernommen, und einer der 10G-Uplinks kommt nicht mehr hoch, seit das Modul darin getauscht wurde. Das Modul wird als inkompatibel mit dem CRS226 gelistet, dort landete der Verdacht also zuerst, aber die Werte sehen für mich nicht nach einem abgelehnten Modul aus.
- MikroTik CRS226 am Aggregationsstandort, Modul in sfp-sfpplus1
- Fiberworks SFP-10G-LR, Cisco-codiert
- Singlemode-Strecke zum entfernten Standort, unterwegs durch zwei Patchfelder geführt
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yesTemperatur und Versorgungsspannung in derselben Ausgabe lesen sich völlig normal, und das Modul wird eindeutig erkannt: Das ist kein Readout einer leeren Cage.
Auf unserer Seite schon gemacht:
- Modul neu gesetzt und beide Anschlüsse gereinigt
- auf den anderen SFP+-Port verschoben, identische Ausgabe
- die Port-Konfiguration geprüft, nichts erzwungen, nichts deaktiviert
Also was ist es: Weist der CRS226 ein Cisco-codiertes Modul still ab und meldet es als no-link, oder bedeutet sfp-rx-lose das, was ich denke, und sollte ich jemanden zum anderen Ende schicken?
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 5
Deine eigene Ausgabe hat die Kompatibilitätsfrage schon beantwortet. Ein vom Switch abgelehntes Modul würde überhaupt keine Temperatur und Spannung melden: Ein vollständiges Monitor-Readout heißt, der CRS226 hat das Modul gelesen und spricht einwandfrei mit ihm. Und
sfp-rx-lose: yesist die eigene Signalverlust-Anzeige des Moduls: Es sieht kein Licht auf der Empfangsfaser. Kein Licht rein, kein Link, egal was die Codierung sagt.Das ist also ein Problem der Strecke, kein Kompatibilitätsproblem. Die Reihenfolge, in der ich das angehen würde:
Nur damit es gesagt ist: Genau dieser Modultyp läuft hier seit Monaten in einem CRS226 bis zu einer CCR, die Paarung selbst ist also nicht das Problem.
Was steht am anderen Ende, und zeigt diese Seite ihren Port als up? Wenn der entfernte Sender an ist, würde man eher etwas Empfangsleistung erwarten als einen reinen Signalverlust.
Zwei billige Checks, bevor jemand rausfährt. Die beiden Fasern am eigenen Patchfeld tauschen und schauen, ob das Flag bleibt, wo es ist. Und die Gegenseite ihr eigenes Modul auslesen lassen: Wenn beide Enden Empfangsverlust melden, ist die Strecke irgendwo in der Mitte kaputt, oder jemand hat an einem der Patchfelder die falschen Fasern gepatcht.
Lohnt sich, unterwegs zwei Fehlerbilder auseinanderzuhalten. Gar kein Licht ist das, was du hast, und das ist der einfache Fall. Die fiesere Variante ist Licht, das gerade eben noch da ist: Einer von einem Paar Glasfaser-Uplinks hier hat einen Rx-Power-low-Alarm bei -20,2 dBm gegen eine Schwelle von -18,4 dBm geloggt und dabei 46.000 Input-Errors und 42.000 CRC-Errors angehäuft, während der Link nominell oben blieb.
show interface transceiver detailundshow interface counters errorshaben diese Geschichte erzählt.Die Arbeit vor Ort ist so oder so dieselbe: beide Endflächen inspizieren und reinigen, TX und RX messen, nach einer zu langen Strecke, einer schlechten Spleißstelle oder einem billigen Patchkabel schauen, und das Modul tauschen, wenn die Pegel unten bleiben. Ich habe den genauen Übeltäter bei unserem nie bewiesen, also eher als Richtung nehmen als als Urteil.
Noch etwas für die Checkliste am anderen Ende: Ein Empfänger kann von selbst sterben, ohne dass an der Faser irgendwas falsch ist.
Cisco hat einen Field Notice, FN-72192, der eine Charge QSFP-40G-LR4 betrifft, auch verkauft als QSFP-40G-LR4-S und WSP-Q40GLR4L, die das Werk mit einem Empfangsdetektor verlassen hat, der leicht daneben sitzt, wo er sollte. Der Hinweis greift bei Modulen, deren Seriennummer mit ACW beginnt und deren Datumscode in ACW2415xxxx-ACW2449xxxx fällt: Bei denen degradiert die Empfangsseite, und der Link geht runter. Die genannte Plattform ist die ASR-900-Serie. Der Umgang damit ist replace on failure, also eher ein Seriennummern-Check und ein Support-Case als irgendetwas zum Konfigurieren.
Der Teil, der sich auf deinen Link verallgemeinern lässt: Die Frühwarnung ist ein Empfangswert in den DOM-Daten, der stetig nach unten rutscht, statt von einer Klippe zu fallen. Gutes Argument dafür, DOM an jedem Uplink zu graphen, statt es erst zu lesen, wenn schon etwas kaputt ist.
Zum Vertrauen in die Werte: größtenteils ja, aber nicht blind. Es gab einen Fall, der die Runde machte, mit einem Huawei-GPON-ONT-Stick in einem MikroTik-SFP+-Slot, der eine sehr niedrige Empfangsleistung meldete, bei Downloads, die bei unter 20 Mbps hängen blieben auf einem deutlich schnelleren Tarif, und niemand hat je geklärt, ob der Messwert oder die Leitung schuld war. Es blieb offen.
Bei einem einfachen LR-Paar wie deinem würde ich die Monitor-Ausgabe für bare Münze nehmen. Bei ungewöhnlichen Modulen in einer SFP+-Cage lohnt sich eine zweite Messung von der Gegenseite, bevor eine Fahrt dorthin geplant wird.