CRS328 avec une clé GPON Alcatel-Lucent G-010S-P : TX seul, pas de RX, longueur d'onde à 33685 nm
Je fais migrer ma ligne FTTH domestique de l'ONT de l'opérateur vers une clé GPON dans mon propre routeur, pour que la fibre arrive directement dans la baie et que je garde un seul boîtier au lieu de deux. La clé est reconnue, le port monte, et ensuite rien ne revient.
- MikroTik CRS328-24P-4S+, clé dans sfp-sfpplus1
- ONU GPON Alcatel-Lucent G-010S-P
- Bell Canada FTTH, fibre depuis la prise murale directement dans le module
- port fixé, autoneg désactivé :
/interface/ethernet set sfp-sfpplus1 auto-negotiation=no speed=1G-baseXLes compteurs TX grimpent, les compteurs RX restent à zéro, et la page du module affiche ceci :
wavelength: 33685.00nmCe qui a déjà été fait :
- réenfiché et nettoyé le connecteur, essayé une seconde cage SFP+
- retiré complètement la fibre - la valeur de longueur d'onde ne change pas, avec ou sans
- laissé le port fixé à 1G pendant une heure au cas où ce serait un ranging lent
Donc : est-ce que 33685.00nm est la preuve que l'optique de cette clé est morte, ou est-ce que le switch décode simplement mal ce champ EEPROM pour un module GPON ? Et y a-t-il quelque chose côté opérateur qui doit se passer avant qu'une ONU SFP soit autorisée à faire du ranging ?
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
Il y a deux choses séparées dans ton message et une seule est un défaut.
Le 33685.00nm est un artefact de décodage, pas une mesure. Ces clés sont à double longueur d'onde - 1310 en montant, 1490 en descendant - et le switch lit un seul champ de longueur d'onde dans l'EEPROM comme s'il s'agissait d'un transceiver ordinaire avec un seul laser. Tu verrais le même nombre sur une clé qui passe du trafic joyeusement, donc c'est inutile comme diagnostic. Mets ça de côté.
Le trafic à sens unique, c'est l'unité elle-même. Je suis passé par là sur le même switch, un CRS328-24P-4S+ : le G-010S-P émettait et ne recevait jamais rien, et la ligne est montée dès que j'ai remplacé par un autre module de la même famille - un O-010S-P, la variante étendue en température. Même compte, même fibre, aucun changement de config. Donc la première clé était soit défectueuse, soit la mauvaise variante pour cette ligne.
Garde le port fixé pendant que tu testes, sinon tu ajoutes une seconde variable :
Avec ALCLFAB dans le numéro de série et le compte déjà basculé vers une ONU SFP, ta moitié côté opérateur est faite. Procure-toi une deuxième clé avant de passer une autre soirée là-dessus.
Avant de condamner l'optique, vérifie la moitié ennuyeuse. Sur beaucoup de comptes FTTH, une ONU SFP n'est pas un remplacement direct du boîtier de l'opérateur : le compte doit être reprovisionné à la main pour ça, et certains opérateurs n'acceptent qu'un module dont le numéro de série porte leur propre préfixe vendeur. Du TX avec rien qui revient, c'est exactement à quoi ressemble une ONU non autorisée côté abonné.
Poste ce que la clé rapporte comme vendeur et numéro de série, et dis ce que tu as configuré côté WAN - tag VLAN, PPPoE ou DHCP.
Le numéro de série commence par ALCLFAB, qui est le préfixe qu'ils veulent sur un compte FTTH entreprise ici. Le compte a aussi été reconfiguré manuellement pour une ONU SFP - ça a demandé un appel téléphonique, la première ligne ne savait pas du tout ce que je demandais.
Côté routeur c'est le VLAN 35 sur le port SFP avec un client PPPoE par-dessus. Le client ne dépasse jamais la découverte. Les compteurs RX sont toujours plats, et l'affichage reste inchangé à 33685.00nm que la fibre soit branchée ou non.
Pour prolonger le point sur la longueur d'onde : le champ que le switch lit se trouve dans la zone SFF-8472 et a été défini pour un module avec un seul laser. Une ONU GPON a un émetteur en mode rafale et un récepteur sur des longueurs d'onde différentes, donc il n'y a pas de valeur unique correcte à y mettre, et les vendeurs écrivent ce qui les arrange. Rien dans la norme n'oblige l'hôte à vérifier la cohérence de cet octet avant de l'afficher, c'est comme ça qu'on se retrouve avec des nanomètres à cinq chiffres.
La même logique s'applique aux lignes de puissance optique sur ces clés. Si tu as besoin de savoir comment se porte le côté PON, prends-le depuis l'état propre de l'ONU, pas depuis la page de diagnostics du switch.
Ça vaut le coup de dire que le côté hôte de ça n'est pas une bizarrerie MikroTik. Sur la famille 7210 SAS, la documentation du vendeur est directe là-dessus : les premières releases n'implémentaient pas du tout le DDM, donc les ports n'affichent aucune puissance optique ni température même avec des modules qui le supportent, et on te dit de vérifier quelle release ajoute la fonction pour ta variante. Pour les modules que le vendeur n'a pas fournis, le même guide dit que les diagnostics peuvent être affichés mais qu'il ne prend aucune responsabilité sur leur mise en forme ou leur exactitude.
Il y a aussi un drapeau de capacité dans l'EEPROM du module qui décide si la plateforme traite un SFP comme compatible DDM, et les modules qui ne le positionnent pas peuvent quand même afficher des nombres plausibles que personne n'a validés.
show port <port> detailest là où on le lit sur ce boîtier. Je traite une valeur tierce sur ce genre de boîtier comme un indice, jamais comme une mesure - ce qui est à peu près le traitement que mérite ton 33685.Pour clore : une deuxième clé a réglé ça. J'ai mis un O-010S-P, le client PPPoE est monté sur le VLAN 35 en moins d'une minute, aucun changement côté opérateur et rien touché dans la config du port. Le vieux G-010S-P fait le même TX-seul dans une autre cage, donc il est mort en ce qui me concerne.
Et oui - le module qui fonctionne affiche aussi 33685.00nm. Content de ne pas avoir passé la semaine à chasser ce nombre.