MRV OptiSwitch OS906: Welcher CLI-Befehl zeigt SFP-Teilenummer und RX-Leistung am Demarkationsstandort
Wir übergeben Kundencircuits auf MRV-OptiSwitch-Demarkationsboxen - meist OS906, mit ein paar OS904 und OS912, die auf älteren Baustellen übrig geblieben sind. Wenn ein Ticket zu einem Circuit reinkommt, der down ist oder flattert, will ich vor jeder Anfahrt zwei Dinge per SSH wissen: welches Modul tatsächlich im Port steckt (niemand loggt, was der Installateur eingebaut hat), und die Empfangsleistung, damit ich sagen kann, ob das Licht auf unserer Seite oder ihrer aufhört.
- MRV OptiSwitch OS906 am Kunden-Demarkationspunkt, OS904 und OS912 an ein paar älteren Standorten
- generische 1G-SFPs, gemischte Hersteller, was die Einsatztruppe gerade im Van hatte
- Singlemode-Strecke zurück zu unserem POP
Das Einzige, was ich bisher herausgefunden habe: Ein leerer Käfig antwortet unmissverständlich:
Failed to get EEPROM Data, SFP is not insertedein fehlendes Modul lässt sich also zumindest von einem unterscheiden, das steckt, aber schweigt. Was ich immer noch nicht kann: Hersteller, Teilenummer und Wellenlänge eines eingesetzten Moduls ausgeben oder TX/RX-Leistung lesen.
Bisher versucht:
- die CLI-Hilfe unter
show portdurchgegangen und dabei eindeutig den richtigen Sub-Befehl verpasst - ein bekannt gutes Modul in ein Lab-OS904 gesteckt, um zu sehen, ob sich die Ausgabe unterscheidet - nichts gesehen
Welche Befehle auf OptiSwitch liefern mir den EEPROM-Inhalt und die aktuellen optischen Pegel? Ich würde lieber niemanden mit einem Powermeter zu einem Standort schicken, wenn die CLI die Antwort schon hat.
Comments 5
Zwei Befehle decken das ab, und sie sind genau so aufgeteilt, wie man es sich wünschen würde: was das Modul über sich selbst behauptet in dem einen, Live-Messwerte im anderen.
show port sfp-paramsgibt die EEPROM-Felder aus - Hersteller, Teilenummer, Seriennummer, Wellenlänge, die vom Modul deklarierte Nominalrate, die Reichweitenangaben für jeden Fasertyp, dazu Identifier- und Connector-Byte. Das beantwortet, was der Installateur tatsächlich eingebaut hat, und ob dessen Reichweite überhaupt zur Strecke passt.show port sfp-diag <portnumber>ist die Live-Hälfte: Modultemperatur in beiden Skalen, Versorgungsspannung, Bias-Strom sendeseitig in mA, und die beiden optischen Leistungen, jeweils doppelt angegeben, in dBm und in mW. Der RX-Wert in dBm ist die Zahl, die man dem Operator am anderen Ende nennt.Erst sfp-params machen - ein dBm-Wert sagt wenig, solange man nicht weiß, ob man auf ein Short-Reach- oder ein Long-Haul-Teil schaut.
Der String, den du schon gefunden hast, ist es wert, behalten zu werden.
Failed to get EEPROM Data, SFP is not insertedheißt, der Käfig ist leer, ein anderer Fehler als ein Modul, das steckt, aber nicht lesbar ist. Wenn du das jemals über einen Haufen Demarkationsboxen hinweg scriptest, ist das die Zeile, auf die du matchst.Rest des Sets auf diesen Boxen:
detail liefert Konfiguration und Portstatus, die beiden statistics-Befehle liefern Paket-, Byte- und Fehlerzähler, mit monitor als laufender Ansicht, und rate mit einer Zeit in Sekunden liefert den Durchsatz über dieses Fenster.
Welches Ende willst du eigentlich nachweisen, und was sitzt auf der anderen Seite der Strecke? Sind beide Enden OptiSwitch, kann man sfp-params auf jedem ziehen und Hersteller, Teilenummer und Wellenlänge direkt vergleichen, und dieser Vergleich fängt den klassischen Fall ab, dass jemand ein Long-Reach-Modul auf die eine Seite und ein Short-Reach-Modul auf die andere gesetzt hat.
Gehört das andere Ende dem Kunden oder einem anderen Betreiber, dessen Moduldetails ins Ticket holen, bevor man irgendeine dBm-Zahl nennt, sonst streitet man eine Woche über einen Link, der optisch nie funktionieren sollte. Und sobald eine Ausgabe da ist: Ist es ein Port, der leer zurückkommt, oder jeder Port auf der Box? Das sind zwei verschiedene Probleme.
Gleiche Problemklasse bei Cisco-Routern, falls hier jemand aus dieser Richtung landet. Auf einem ISR 4451 bringt die Catalyst-Angewohnheit,
show interface transceiverzu tippen, gar nichts, der Router nimmt die Syntax nicht, also schließen Leute, die Plattform hätte überhaupt kein DOM. Hat sie doch; man kommt stattdessen über den Hardware-Module-Baum ran:Was zurückkommt, sind die Modul-Thermalwerte, die sendeseitige Versorgungsspannung und der Bias-Strom, dann beide Leistungswerte. Bei einem toten Link las hier ein GLC-LH-SMD rund -7,1 dBm ausgehend und -32,2 dBm eingehend, das ist keine grenzwertige Strecke, das ist Dunkelheit - fernes Ende oder Faserstrecke, hat mit dem Router nichts zu tun.
Grobe Skala, nach der ich arbeite: Ein kurzer Hop im Gebäude liegt bei etwa -3 bis -8 dBm, Long Reach bewegt sich mit der Distanz, unter etwa -30 dBm kommt nichts mehr an. Und bevor man der Faser die Schuld gibt: %TRANSCEIVER-3-NOT_SUPPORTED in
show logging, oder ein Media Type, der inshow interfaceals unknown ausgegeben wird, beides heißt, der Router hat das Modul abgelehnt.Noch eine Plattform für die Sammlung. Beim Avaya VSP 7000 ist es ein einzelner Befehl:
Er gibt aus, was der Switch aus dem Modul im Käfig ausgelesen hat, und das Troubleshooting-Kapitel nutzt diese Ausgabe, um zu entscheiden, ob das Gerät als unterstützt gilt.
Das Ärgerliche: Die Liste der qualifizierten Module steht nicht in diesem Kapitel. Sie steht im separaten Transceiver-Installationsdokument, NN47202-302, zusammen mit den Schritten für physischen Ein- und Ausbau. Kommt das Modul als failed oder unsupported zurück, lautet die dokumentierte Antwort, es gegen etwas von dieser Liste zu tauschen.