CRS328 with an Alcatel-Lucent G-010S-P GPON stick: TX only, no RX, wavelength reads 33685 nm
Moving my home FTTH line off the operator's ONT and onto a GPON stick in my own router, so that the fibre lands straight in the rack and I keep one box instead of two. The stick is recognised, the port comes up, and then nothing comes back.
- MikroTik CRS328-24P-4S+, stick in sfp-sfpplus1
- Alcatel-Lucent G-010S-P GPON ONU
- Bell Canada FTTH, fibre from the wall box straight into the module
- port pinned, autoneg off:
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXTX counters climb, RX counters stay at zero, and the module page reads like this:
wavelength: 33685.00nmWhat I have already done:
- reseated and cleaned the connector, tried a second SFP+ cage
- pulled the fibre out completely - the wavelength value does not change, with or without it
- left the port pinned at 1G for an hour in case it was a slow ranging thing
So: is 33685.00nm evidence that the optics in this stick are dead, or is the switch simply decoding that EEPROM field wrong for a GPON module? And is there something on the operator side that has to happen before an SFP ONU is allowed to range at all?
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
There are two separate things in your post and only one of them is a fault.
The 33685.00nm is a decoding artefact, not a measurement. These sticks are dual-wavelength - 1310 upstream, 1490 downstream - and the switch reads a single wavelength field out of the EEPROM as if it were an ordinary transceiver with one laser. You will see the same number on a stick that is happily passing traffic, so it is useless as a diagnostic. Put it aside.
The one-way traffic is the unit itself. I went through this on the same switch, a CRS328-24P-4S+: the G-010S-P transmitted and never received a thing, and the line came up the moment I swapped in another module from the same family - an O-010S-P, the extended-temperature variant. Same account, same fibre, no config change. So the first stick was either defective or the wrong variant for that line.
Keep the port pinned while you test, otherwise you add a second variable:
With ALCLFAB in the serial and the account already switched over to an SFP ONU, your operator half is done. Get a second stick in hand before you spend another evening on this one.
Before you write off the optics, check the boring half. On a lot of FTTH accounts an SFP ONU is not a drop-in for the operator's box: the account has to be re-provisioned by hand for it, and some operators only accept a module whose serial carries their own vendor prefix. TX with nothing coming back is exactly what an ONU that has not been authorised looks like from the subscriber side.
Post what the stick reports for vendor and serial, and say what you have configured on the WAN side - VLAN tag, PPPoE or DHCP.
Serial starts with ALCLFAB, which is the prefix they want on a business FTTH account here. The account was reconfigured manually for an SFP ONU as well - that took a phone call, the first line had no idea what I was asking for.
Router side is VLAN 35 on the SFP port with a PPPoE client on top of it. The client never gets past discovery. RX counters are still flat, and the readout is unchanged at 33685.00nm whether the fibre is plugged in or not.
To extend the wavelength point: the field the switch is reading lives in the SFF-8472 area and was defined for a module with one laser. A GPON ONU has a burst-mode transmitter and a receiver on different wavelengths, so there is no single correct value to put there, and vendors write whatever suits them. Nothing in the standard obliges the host to sanity-check that byte before printing it, which is how you end up with five-digit nanometres.
The same logic applies to the optical power lines on these sticks. If you need to know how the PON side is doing, get it from the ONU's own state, not from the switch's diagnostics page.
Worth saying that the host end of this is not a MikroTik quirk. On the 7210 SAS family the vendor documentation is blunt about it: the early releases did not implement DDM at all, so ports show no optical power or temperature even with modules that support it, and you are told to check which release adds the function for your variant. For modules the vendor did not supply, the same guide says diagnostics may be displayed but it takes no responsibility for their formatting or accuracy.
There is also a capability flag in the module EEPROM that decides whether the platform treats an SFP as DDM-capable, and modules that do not set it can still print plausible-looking numbers that nobody validated.
show port <port> detailis where you read it there. I treat a third-party value on that box as a hint, never as a measurement - which is roughly the attitude your 33685 deserves.Closing this out: a second stick fixed it. I put in an O-010S-P, the PPPoE client came up on VLAN 35 within a minute, no changes on the operator side and nothing touched in the port config. The old G-010S-P does the same TX-only thing in another cage, so it is dead as far as I am concerned.
And yes - the working module also reports 33685.00nm. Glad I did not spend the week chasing that number.