Un SFP+ DWDM tiers reste down sur un Arista 7050T avec EOS 4.10.6 - autre chose que patcher l'image ?

Avant que quelqu'un ne vous pointe vers l'image, deux choses.

Sur quelle branche EOS êtes-vous réellement contraint sur ce 7050T ? Si vous devez rester en 4.10.6, alors un bricolage spécifique à cette version est au moins cohérent avec lui-même. Si vous pouvez le faire évoluer, comprenez que la gestion des transceivers a été réorganisée dans les versions ultérieures et qu'aucune recette écrite pour 4.10.6 ne se transpose.

Et que peut réellement graver ce fournisseur dedans ? Ça vaut le coup de demander si son programmateur porte un profil Arista du tout, ou seulement le codage Cisco par plateforme que la plupart d'entre eux gardent - les pièces ASR9K, par exemple, ont besoin de leur propre profil et les vendors d'optiques en maintiennent bien un. Faire recoder le lot revient bien moins cher que de vivre sur une image modifiée. Séparément : avez-vous déjà demandé à votre équipe commerciale la clé unsupported-transceiver, ou est-ce exclu pour des raisons commerciales ?

Le patch d'image fonctionne bien sur exactement cette build, et ce n'est pas beaucoup de travail - mais faites-le sur un boîtier de labo ou de rechange, jamais sur quoi que ce soit qui porte du trafic.

La forme : décompresser EOS-4.10.6.swi et garder les membres, qui sont boot0, initrd-i386, linux-i386, rootfs-i386.sqsh et version. Décompacter le système de fichiers racine en root, éditer l'agent, recompacter :

unsquashfs rootfs-i386.sqsh
mksquashfs squashfs-root/ rootfs-i386.sqsh
zip -Z store EOS-4.10.6a.swi boot0 initrd-i386 linux-i386 rootfs-i386.sqsh version

La modification elle-même est dans squashfs-root/usr/lib/python2.7/site-packages/XcvrAgent.py : commenter les quatre lignes vers la ligne 172 qui vérifient l'état de présence puis exécutent l'authentification du transceiver. Le -Z store du zip n'est pas optionnel, le swi doit rester non compressé sinon le boîtier ne démarrera pas dessus.

Après ça, les ports montent avec tout ce que vous branchez, parce que plus rien n'est validé. Deux prix à payer : vous n'avez plus de support vendor sur une image modifiée, et le patch est lié à cette build, donc gardez le .swi d'origine sur la flash pour y redémarrer quand quelque chose tourne mal.

Pour répondre aux questions ci-dessus : le boîtier est une pièce de rechange sans contrat de support, et le fournisseur n'a aucun profil Arista dans son programmateur du tout - ils codent pour des plateformes Cisco et c'est la fin de la liste, donc recoder ce lot n'est pas proposé. La voie de l'équipe commerciale n'est pas exclue, elle ne m'aide juste pas cette semaine.

J'ai reconstruit la 4.10.6 comme décrit, démarré sur l'image patchée, et les deux ports DWDM sont montés du premier coup. L'image d'origine est toujours sur la flash. Le lien est stable depuis, et l'autre extrémité ne voit rien d'inhabituel.

Content que ça ait marché, mais soyez honnête avec vous-même sur la durée de vie de ce patch, parce que le fil ci-dessus le fait paraître plus général qu'il ne l'est.

C'est écrit pour la 4.10.6 et rien d'autre. Des gens ont demandé comment reproduire ça sur 4.14.5F, 4.14.7M et 4.23.8M et personne n'a jamais posté de réponse qui fonctionne, parce que le gestionnaire de transceiver a été réorganisé dans les versions ultérieures et ces quatre lignes ne sont plus là à vous attendre. Chaque mise à niveau remplace aussi l'image, donc le patch disparaît et les ports tombent la prochaine fois que quelqu'un fait une maintenance de routine.

Les voies qui survivent à une mise à niveau sont la clé service unsupported-transceiver spécifique au client que l'équipe commerciale délivre, et sur les plateformes plus anciennes le fichier marqueur enable3px. Utilisez l'image patchée pour garder un vieux boîtier utile, pas comme un standard pour le réseau.

Même combat côté Cisco, avec un détail qui mérite d'être retenu. Des SFP+ DWDM 80 km tiers (Pro10Optix, étiquetés SFP-10G-DWDM-192) faisaient tourner sans problème dans des switches Catalyst 6500. Déplacés dans les ports SFP+ intégrés d'un ASR 9001 sous IOS XR 5.3.3, ils donnaient :

%PLATFORM-SFP-3-DEV_SFP_SUPPORTED_ERROR: SFP Module is not supported
%PLATFORM-SFP-3-DEV_SFP_PID_NOT_SUPPORTED: Not supported Product ID

LED de port rouge, interface down, état rapporté comme perte de lien ou lumière faible sans boucle, longueur d'onde relue comme 0 nm et le laser ne s'allumant jamais. transceiver permit pid all sur l'interface n'a rien changé à lui seul, et le service unsupported-transceiver global par-dessus n'a pas non plus sauvé ce lot. La plateforme attend une référence dans la forme DWDM-SFP10G-xx.yy issue de sa propre matrice d'optiques, et un PID générique ne correspond à aucune optique supportée du tout, donc il n'y a rien que le contournement puisse assouplir.

Quelqu'un d'autre sur la même version avait des modules Skylane SPDTU080100D139 80 km qui fonctionnaient sur un 9001 - mais seulement avec les deux commandes configurées, sinon l'interface ne se rétablissait pas après un rebond de lien. Le lot défaillant a finalement été échangé contre des modules correctement codés.

J'ajoute une chose qui évite un aller-retour quand vous retournez voir un fournisseur : demandez-leur de coder pour la plateforme, pas pour la marque. Une grande part de ces fils concerne des modules qui s'identifient comme le bon vendor mais portent une référence que la matrice de la plateforme n'a jamais rencontrée, et les contournements de type permit n'assouplissent la vérification que pour des modules qui paraissent par ailleurs corrects au boîtier.

Pendant qu'ils ont les modules sur le banc, faites-leur confirmer que l'EEPROM est strictement conforme à SFF-8472. Des données A2h mal faites se relisent comme du non-sens - la longueur d'onde de 0 nm mentionnée plus haut est exactement de cette nature - et une fois la lecture propre et que la plateforme refuse quand même la pièce, vous avez quelque chose de concret pour le support vendor au lieu d'un argument général sur les optiques tierces.