CRS328 met een Alcatel-Lucent G-010S-P GPON-stick: alleen TX, geen RX, golflengte leest 33685 nm
Ik verhuis mijn thuis-FTTH-lijn van de ONT van de provider naar een GPON-stick in mijn eigen router, zodat de vezel rechtstreeks in het rack landt en ik één doos overhoud in plaats van twee. De stick wordt herkend, de poort komt op, en dan komt er niets terug.
- MikroTik CRS328-24P-4S+, stick in sfp-sfpplus1
- Alcatel-Lucent G-010S-P GPON-ONU
- Bell Canada FTTH, vezel rechtstreeks van de wandaansluiting in de module
- poort vastgezet, autoneg uit:
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXTX-counters lopen op, RX-counters blijven op nul staan, en de modulepagina leest zo:
wavelength: 33685.00nmWat ik al gedaan heb:
- connector opnieuw gezet en schoongemaakt, een tweede SFP+-cage geprobeerd
- de vezel helemaal eruit getrokken: de golflengtewaarde verandert niet, met of zonder
- de poort een uur lang vastgezet op 1G voor het geval het een traag ranging-dingetje was
Dus: is 33685.00nm bewijs dat de optiek in deze stick dood is, of decodeert de switch dat EEPROM-veld gewoon verkeerd voor een GPON-module? En moet er aan de kant van de provider iets gebeuren voordat een SFP-ONU überhaupt mag rangen?
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 6
Er zitten twee losse dingen in je post en maar één ervan is een storing.
De 33685.00nm is een decodeerartefact, geen meting. Deze sticks zijn dual-wavelength: 1310 upstream, 1490 downstream, en de switch leest één golflengteveld uit de EEPROM alsof het een gewone transceiver met één laser is. Je ziet hetzelfde getal op een stick die vrolijk verkeer doorgeeft, dus als diagnose is het waardeloos. Laat het terzijde.
Het eenrichtingsverkeer is de unit zelf. Ik heb dit doorgemaakt op dezelfde switch, een CRS328-24P-4S+: de G-010S-P zond en ontving nooit iets, en de lijn kwam op zodra ik een andere module uit dezelfde familie erin zette: een O-010S-P, de variant voor extended temperature. Zelfde account, zelfde vezel, geen configuratiewijziging. Dus de eerste stick was ofwel defect, ofwel de verkeerde variant voor die lijn.
Houd de poort vastgezet terwijl je test, anders voeg je een tweede variabele toe:
Met ALCLFAB in het serienummer en het account al omgezet naar een SFP-ONU is jouw providerhelft klaar. Zorg dat je een tweede stick in huis hebt voordat je hier nog een avond aan verliest.
Voordat je de optiek afschrijft, check eerst het saaie deel. Bij veel FTTH-accounts is een SFP-ONU geen drop-in vervanging voor de doos van de provider: het account moet er handmatig voor opnieuw geprovisioneerd worden, en sommige providers accepteren alleen een module waarvan het serienummer hun eigen vendorprefix draagt. TX zonder dat er iets terugkomt is precies hoe een niet-geautoriseerde ONU er vanaf de abonneekant uitziet.
Post wat de stick als vendor en serienummer opgeeft, en zeg wat je aan de WAN-kant hebt geconfigureerd: VLAN-tag, PPPoE of DHCP.
Serienummer begint met ALCLFAB, en dat is hier het prefix dat ze willen op een zakelijk FTTH-account. Het account is ook handmatig herconfigureerd voor een SFP-ONU: dat kostte een telefoontje, de eerste lijn had geen idee waar ik het over had.
Aan de routerkant is het VLAN 35 op de SFP-poort met een PPPoE-client erbovenop. De client komt nooit voorbij discovery. RX-counters staan nog steeds plat, en de uitlezing blijft onveranderd op 33685.00nm, met of zonder vezel erin.
Om het golflengtepunt uit te breiden: het veld dat de switch leest zit in het SFF-8472-gebied en is gedefinieerd voor een module met één laser. Een GPON-ONU heeft een burst-mode-zender en een ontvanger op verschillende golflengtes, dus er is geen enkele juiste waarde om daar in te zetten, en vendors schrijven er wat hen uitkomt. Niets in de standaard verplicht de host om die byte te controleren voordat hij hem print, en zo kom je aan vijfcijferige nanometers.
Dezelfde logica geldt voor de vermogensregels op deze sticks. Als je moet weten hoe de PON-kant ervoor staat, haal dat dan uit de eigen status van de ONU, niet uit de diagnostiekpagina van de switch.
Het is de moeite waard om te zeggen dat het hostgedeelte hiervan geen MikroTik-eigenaardigheid is. Bij de 7210 SAS-familie is de documentatie van de vendor daar botweg over: de vroege releases implementeerden DDM helemaal niet, dus poorten tonen geen optisch vermogen of temperatuur, zelfs met modules die het ondersteunen, en je wordt verwezen naar welke release de functie voor jouw variant toevoegt. Voor modules die de vendor niet zelf heeft geleverd zegt diezelfde handleiding dat diagnostiek getoond kan worden, maar zonder verantwoordelijkheid voor opmaak of nauwkeurigheid.
Er is ook een capability-vlag in de module-EEPROM die bepaalt of het platform een SFP als DDM-capable behandelt, en modules die deze niet zetten kunnen nog steeds plausibel ogende getallen printen die niemand gevalideerd heeft.
show port <port> detailis waar je het daar leest. Ik behandel een waarde van derden op die doos als aanwijzing, nooit als meting: ongeveer de houding die jouw 33685 verdient.Ter afsluiting: een tweede stick heeft het opgelost. Ik heb een O-010S-P erin gezet, de PPPoE-client kwam binnen een minuut op op VLAN 35, geen wijzigingen aan de providerkant en niets aangeraakt in de poortconfig. De oude G-010S-P doet hetzelfde TX-only-gedrag in een andere cage, dus voor mij is hij dood.
En ja: de werkende module rapporteert ook 33685.00nm. Blij dat ik niet de hele week achter dat getal aan heb gezeten.