MRV OptiSwitch OS906: which CLI command shows the SFP part number and RX power at a demarcation site
We hand customer circuits off on MRV OptiSwitch demarcation boxes - mostly OS906, with a few OS904 and OS912 left on older builds. When a ticket comes in about a circuit that is down or flapping, I want two things over SSH before anyone drives out: what module is actually sitting in the port (nobody logs what the installer fitted), and the receive power, so I can say whether the light stops on our side or theirs.
- MRV OptiSwitch OS906 at the customer demarcation point, OS904 and OS912 on a few older sites
- Generic 1G SFPs, mixed vendors, whatever the field crew had in the van
- Single-mode span back to our POP
The one thing I have worked out so far is that an empty cage answers plainly:
Failed to get EEPROM Data, SFP is not insertedso at least a missing module is distinguishable from one that is present but silent. What I still cannot do is print the vendor, part number and wavelength of a module that is in place, or read TX/RX power.
Tried so far:
- Walked the CLI help under
show portand clearly missed the right sub-command - Put a known-good module into a lab OS904 to see whether the output differs - sme nothing
Which commands on OptiSwitch give me the EEPROM contents and the live optical levels? I would rather not send someone with a power meter to a site where the CLI already has the answer.
Comments 5
Two commands cover it, and they are split the way you would hope: what the module claims about itself in one, live readings in the other.
show port sfp-paramsdumps the EEPROM fields - vendor, part number, serial, wavelength, the nominal rate the module declares, the reach figures it carries for each fibre type, plus the identifier and connector bytes. That answers what the installer actually fitted, and whether its reach suits the span at all.show port sfp-diag <portnumber>is the live half: module temperature in both scales, supply voltage, bias current on the transmit side in mA, and the two optical powers, each given twice, in dBm and in mW. The RX value in dBm is the number you quote at the far-end operator.Do sfp-params first - a dBm reading means little until you know whether you are looking at a short-reach or a long-haul part.
The string you already found is worth keeping.
Failed to get EEPROM Data, SFP is not insertedmeans the cage is empty, which is a different fault from a module that is seated but unreadable. If you ever script this across a pile of demarcation boxes, that is the line you match on.Rest of the set on these boxes:
detail gives configuration and port state, the two statistics commands give packet, byte and error counters with monitor as the running view, and rate with a time in seconds gives throughput over that window.
Which end are you actually trying to prove, and what is on the far side of the span? If both ens are OptiSwitch you can pull sfp-params on each and compare vendor, part number and wavelength directly, and that comparison catches the classic case where somebody put a long-reach module on one end and a short-reach one on the other.
If the far end belongs to the customer or another operator, get their module details into the ticket before you quote any dBm number, otherwise you spend a week arguing about a link that was never going to work optically. And once you do have output: is it one port that comes back blank, or every port on the box? Those are two different problems.
Same class of problem on Cisco routers, in case anyone lands here from that direction. On an ISR 4451 the Catalyst habit of typing
show interface transceivergets you nowhere, the router will not take the syntax, so people conclude the platform has no DOM at all. It has one; you get at it through the hardware module tree instead:What comes back is module thermals, the transmit-side supply voltage and bias current, then both power figures. On a dead link here a GLC-LH-SMD read roughly -7.1 dBm going out and -32.2 dBm coming back, which is not a marginal span, it is darkness - far end or fibre path, nothing to do with the router.
Rough scale I work to: a short in-building hop sits around -3 to -8 dBm, long reach moves with distance, below about -30 dBm there is nothing arriving. And before the fibre gets blamed: %TRANSCEIVER-3-NOT_SUPPORTED in
show logging, or a media type printed as unknown inshow interface, either one means the router has refused the module.One more platform for the collection. On the Avaya VSP 7000 it is a single command:
It prints what the switch raed out of the module in the cage, and the troubleshooting chapter uses that output to decide whether the device counts as supported.
Annoying part: the qualified module list is not in that chapter. It sits in the separate transceiver installation document, NN47202-302, alongside the physical install and removal steps. Module comes back failed or unsupported, the documented answer is to swap it for something off that list.