CRS226 reports no-link and sfp-rx-lose yes on a Cisco-coded SFP-10G-LR uplink
We took over a small aggregation site and one of the 10G uplinks has not come up since the module in it was swapped. The module is listed as incompatible with the CRS226, so that is where suspicion landed first, but the readings do not look like a rejected module to me.
- MikroTik CRS226 at the aggregation site, module in sfp-sfpplus1
- Fiberworks SFP-10G-LR, Cisco-coded
- single-mode pair to the remote site, patched through two panels on the way
/interface ethernet monitor sfp-sfpplus1
status: no-link
sfp-rx-lose: yesTemperature and supply voltage in the same output read completely normal, and the module is clearly detected - this is not an empty-cage readout.
Already done on our side:
- reseated the module and cleaned both connectors
- moved it to the other SFP+ port, identical output
- checked the port config, nothing forced, nothing disabled
So which is it: is the CRS226 quietly refusing a Cisco-coded module and reporting it as no-link, or does sfp-rx-lose mean what I think it means and I should be sending someone to the far end?
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
Your own output has already answered the compatibility question. A module the switch had refused would not be reporting temperature and voltage at all - a full monitor readout means the CRS226 has read the module and is talking to it perfectly well. And
sfp-rx-lose: yesis the module's own loss-of-signal indication: it sees no light on the receive fibre. No light in, no link, whatever the coding says.So this is a plant problem, not a compatibility problem. The order I would work it:
For what it is worth, that same module type has been running in a CRS226 up to a CCR here for months, so the pairing itself is not the issue.
What is on the far end, and does that side show its port as up? If the remote transmitter is on you would expect some receive power rather than a plain loss-of-signal.
Two cheap checks before anyone drives out. Swap the two strands at your patch panel and see whether the flag stays where it is. And get the far side to read its own module: if both ends report loss of receive, the pair is broken somewhere in the middle or someone has patched the wrong strands at one of those panels.
Worth keeping two failure modes apart while you are out there. No light at all is what you have, and it is the easy one. The nastier variant is light that is only just present: one of a pair of fibre uplinks here logged an Rx power low alarm at -20.2 dBm against a -18.4 dBm threshold and piled up 46 thousand input errors and 42 thousand CRC errors while the link stayed nominally up.
show interface transceiver detailandshow interface counters errorstold that story.The field work is the same either way - clean and inspect both end faces, meter TX and RX, look for an over-long run, a bad splice or a cheap patch cord, and swap the module if the levels stay down. I never proved the exact culprit on ours, so take it as a direction rather than a verdict.
One more thing for the far-end checklist: a receiver can die on its own with nothing wrong in the fibre.
Cisco has a field notice, FN-72192, covering a batch of QSFP-40G-LR4 - also sold as QSFP-40G-LR4-S and WSP-Q40GLR4L - that left the factory with the receive detector sitting slightly off where it should be. The notice bites on modules whose serial starts ACW and whose date code lands in ACW2415xxxx-ACW2449xxxx: on those the receive side degrades and the link goes down. The platform it names is the ASR 900 series. Handling is replace on failure, so it is a serial check and a support case rather than anything you configure.
The part that generalises to your link: the early warning is a receive value in the DOM data that slides steadily downwards rather than falling off a cliff. Good argument for graphing DOM on every uplink instead of reading it once something has already broken.
On trusting the readings - mostly yes, but not blindly. There was a case doing the rounds of a Huawei GPON ONT stick sitting in a MikroTik SFP+ slot, reporting a very low receive power with downloads stuck under 20 Mbps on a much faster plan, and nobody ever established whether the reading or the line was at fault. It was left open.
On a plain LR pair like yours I would take the monitor output at face value. On odd modules in an SFP+ cage it is worth a second reading from the other end before you plan a truck roll around it.