L'EX4200 signale l'EEPROM du SFP+ comme mal programmée après une mise à niveau Junos alors qu'un MX960 affiche toujours le DOM
On fait tourner une poignée de liaisons DWDM de 80 km depuis des EX4200 avec des optiques tierces aux deux bouts, parce que les pièces DWDM de marque constructeur n'allaient jamais rentrer dans le budget. Ça allait très bien pendant des années. Après le passage des boîtiers EX à Junos 12.3, les optiques sont toujours dans les mêmes ports et les liaisons existent toujours, mais le switch a cessé d'admettre que les modules sont même des optiques.
- EX4200, Junos 12.3 (le DOM fonctionnait bien en 11.4 sur le même châssis)
- Integra SFPP-C51-80-10GD, SFP+ DWDM 80 km
- MX960 à l'autre bout de la même liaison, référence identique, DOM toujours complet
user@ex4200> show interfaces diagnostics optics xe-0/1/0
Physical interface: xe-0/1/0
Unknown cableLe journal messages affiche exactement une ligne quand le module est inséré : SFP+ of type 0 EEPROM is Mis Programmed.
Ce que j'ai déjà écarté :
- réinséré l'optique et l'ai déplacée vers un autre port du même châssis, aucun changement ;
- essayé un EX3300 de rechange et un QFX5100 en labo, les deux se comportent pareil, donc ce n'est pas un seul boîtier cassé ;
- revérifié l'autre bout, le MX960 donne des diagnostics complets pour la même référence de la même commande.
Donc est-ce que le driver EX impose quelque chose dans l'EEPROM que l'ancienne version ignorait simplement ? Et si oui, peut-on faire quelque chose sur l'optique elle-même, ou est-ce une conversation à avoir avec le fournisseur ?
Comments 6
Cette ligne de journal n'est pas une plainte générique, c'est le driver qui vous dit quelle vérification a échoué.
Les octets 3 à 10 de la page A0 contiennent les codes de conformité du transceiver décrits dans SFF-8472 - les bits qui indiquent 10GBASE-SR, LR, ER, les codes SONET, ceux de Fibre Channel, etc. Sur ce type d'optique, les huit octets sont tous à zéro, c'est pourquoi le message l'appelle type 0. La spec attend qu'au moins un bit quelque part dans ce champ soit positionné ; un champ de conformité entièrement à zéro n'est pas une description de module valide. L'ancien code EX ne regardait jamais et passait directement à l'analyse de la page de diagnostics, le nouveau driver valide d'abord le champ puis refuse de traiter le module comme une optique 10G connue. D'où le câble inconnu et le DOM manquant. La gamme MX n'exécute pas cette vérification sur le même chemin, c'est exactement pourquoi la même référence fonctionne encore là-bas.
Prouvez-le avant de discuter avec qui que ce soit : passez au shell et faites un xcvrpeek de la page A0 sur ce port, puis regardez les offsets 3 à 10. Tous à zéro clôt le dossier.
C'est en général au moment de réparer sur place que ça coince. En théorie, xcvrpoke réécrit ces mêmes octets. En pratique, beaucoup de fabricants verrouillent la page A0 et l'écriture renvoie EIO, et il n'y a rien à faire à ce sujet côté switch. Il reste le fournisseur : soit il livre des optiques programmées avec de vrais codes de conformité, soit il les livre avec A0 déverrouillée pour que vous puissiez positionner les bits vous-même. S'il ne peut faire ni l'un ni l'autre, c'est un problème de fournisseur déguisé en problème Junos.
Deux choses à préciser avant que quiconque commence à deviner.
D'abord, la version exacte sur chaque boîtier. Vous dites que l'EX est passé en 12.3, mais que fait tourner le MX960 ? S'il est encore sur une branche plus ancienne, les deux boîtiers ne sont pas vraiment comparables et la différence ne vous dit encore rien.
Ensuite, la pièce côté MX est-elle littéralement le même SFPP-C51-80-10GD du même lot, ou le même modèle issu d'une commande différente ? Les lots diffèrent plus que quiconque ne le voudrait.
Postez
show interfaces diagnostics opticsdes deux bouts, plus tout ce que le journal messages affiche quand vous retirez et réinsérez l'optique, pas seulement la ligne que vous avez déjà citée.Même référence aux deux bouts, SFPP-C51-80-10GD, même commande, numéros de série consécutifs.
Sur le MX960,
show interfaces diagnostics opticsdonne le jeu complet : température, courant de polarisation du laser, puissance TX, puissance RX. Sur l'EX4200, la même commande affiche l'en-tête d'interface puis la ligne unknown cable, rien d'autre. Réinsérer l'optique produitSFP+ of type 0 EEPROM is Mis Programmeddans le journal et rien de plus, quel que soit le port que j'utilise.Ce qui me dérange, c'est qu'avant la mise à niveau, cette exacte optique dans ce châssis et ce port exacts rapportait le DOM sans un mot de plainte.
Utile d'ajouter que la moitié lecture seule de tout ça existe aussi de l'autre côté de la barrière. Sur Cisco,
show idprom interface <if> detailextrait les octets d'identification sans aucune gymnastique de shell, ce qui est pratique pour vérifier un lot sur un switch de rechange avant que les modules n'approchent d'un boîtier Juniper.Lire est inoffensif partout. Écrire depuis l'hôte est une autre bête : xcvrpoke est un outil interne, il n'est pas supporté comme moyen de réparer des modules, et comme noté il est de toute façon bloqué par le verrouillage constructeur environ une fois sur deux. Utilisez-le pour prouver ce qui ne va pas dans l'EEPROM, puis remettez cette preuve à celui qui vous a vendu les optiques.
Même catégorie de problème, symptôme complètement différent, au cas où quelqu'un atterrirait ici depuis une recherche.
On a mis un SFP WDM BiDi 1G sans marque dans ge-0/0/1 d'un EX4600 et l'interface n'existait tout simplement pas. Absente de
show interfaces terse, et toute commande dessus renvoyaiterror: device ge-0/0/1 not found. Le journal disaitOPTIC State changed for port: 0/0/1puisFibre channel transceiver plugged in without Fibre channel configuration!!. L'EEPROM était codé de telle sorte que Junos classait le module comme un transceiver Fibre Channel plutôt que Gigabit Ethernet, donc aucune interface Ethernet n'a jamais été créée pour lui. Aucune quantité de configuration ne corrige ça ; un module correctement codé, si.Et ce n'est pas seulement le bas de gamme du marché. Il y a eu un lot de SFP+ 10G de marque Citrix qui faisait consigner aux appliances NetScaler MPX et SDX
*** Unsupported SFP+/SFP type !au démarrage sur les propres pièces du fabricant. Les bonnes unités portent un marquage de révision A2 sur l'étiquette, les mauvaises sont reparties en RMA. Un mauvais codage arrive à tous les niveaux de prix.Confirmé, et merci pour les offsets précis.
xcvrpeek sur la page A0 montre les offsets 3 à 10 à zéro sur chacune de ces unités SFPP-C51-80-10GD que j'ai vérifiées, y compris celles encore en boîte. xcvrpoke renvoie immédiatement EIO, donc A0 est verrouillée et il n'y a rien à récupérer de notre côté.
Je suis retourné voir le fournisseur avec les offsets d'octets et la ligne de journal citée. Ils l'ont accepté et recodent le lot avec de vrais codes de conformité ; celles installées dans le MX960 restent où elles sont, puisque rien sur cette plateforme ne se plaint. Je marque l'explication ci-dessus comme réponse.