Des optiques SFP+ tierces restent down sur un DCS-7150S-24 d'occasion : le fichier flash enable3px est-il encore une option ?
J'ai récupéré quelques commutateurs Arista d'occasion pour le labo et je me suis heurté directement au verrou des optiques. Les modules codés Arista montent, les câbles DAC passifs montent, et tout ce qui est tiers laisse le port down.
Côté labo :
- DCS-7150S-24, acheté d'occasion, aucun contrat de support et aucun compte commercial derrière moi
- divers modules SFP+ tiers
- câbles DAC passifs pour les liaisons courtes à l'intérieur de la baie
Et1 passive DAC -> link comes up
Et5 third-party SFP+ -> port stays down
Et6 Arista-coded SFP+ -> link comes upCe que j'ai déjà compris :
- le fait que le DAC monte alors que les optiques ne montent pas m'indique que c'est une vérification de codage, pas un problème de câblage ni une cage morte ;
- il existe une commande de configuration de la forme
service unsupported-transceiver CUSTOMERNAME LICENSEKEY, qui demande évidemment une clé que je n'ai aucun moyen d'obtenir ; - d'anciens articles mentionnent un fichier marqueur sur la flash au lieu d'une clé, mais je n'arrive pas à savoir à quelle génération ça s'applique.
Lequel des deux mécanismes s'applique à un boîtier de cet âge, et le fichier flash est-il encore une option sur un 7150S, ou la clé est-elle désormais la seule voie possible ?
Comments 6
Sur cette génération, c'est le fichier, et c'est aussi rudimentaire que ça en a l'air. Depuis la CLI EOS :
Un fichier vide, rien dedans - sa simple présence active les optiques tierces après le reload. La liste des plateformes où ça fonctionne est longue : DCS-7120T-4S, la famille DCS-7050 et toute la gamme DCS-7150S entre autres, et chaque modèle a une version EOS la plus récente qui respecte encore le fichier, allant à peu près de 4.13.16M sur les boîtiers les plus anciens jusqu'à la branche 4.23 sur le 7150S. Les commutateurs plus récents ignorent complètement le fichier.
Donc un 7150S-24 est du bon côté de cette limite, à condition de ne pas avoir dépassé ce que le modèle prend en charge. Essayez ça avant de vous approcher de la piste de la clé.
Quelle branche EOS tourne sur ce 7150S-24, et l'avez-vous mise à jour après l'achat ? Ça compte, parce que la limite se fixe par plateforme plutôt que par famille. Le fichier drapeau est documenté comme fonctionnant sur le 7048T, le 7120T-4S, le 7140T-8S, les variantes SFP+ 7124 et 7148, les séries 7050 et 7150S et les cartes ligne 7548S-LC, mais la dernière version EOS qui le respecte encore diffère pour chacun d'eux.
Si vous avez déjà mis à jour EOS sur un boîtier d'occasion, il y a de bonnes chances que vous vous soyez mis vous-même hors de portée de l'astuce, et alors la correction la moins coûteuse consiste à redescendre d'une branche plutôt qu'à chercher une clé.
Je n'ai jamais touché à EOS depuis l'arrivée du boîtier, donc il est resté sur la branche laissée par le vendeur - ce qui s'est avéré une chance. J'ai fait le touch, le write memory, le reload - et les modules SFP+ tiers qui étaient morts avant montent désormais comme des ports ordinaires. Pas de clé, pas de compte commercial, rien d'autre nécessaire. Les DAC ont continué à fonctionner tout du long, comme prévu.
Pour quiconque atterrit ici avec un boîtier plus récent : le fichier y est réellement ignoré, et la seule voie est une clé cryptographique par client, qui vit dans la configuration active sous la forme
La clé vient de l'équipe commerciale ou SE, pas du support - le TAC n'est pas habilité à délivrer des clés de déblocage et vous renverra vers la gestion de compte, ce qui est une impasse quand le commutateur vient du marché de l'occasion.
À répéter pour les montages de labo : les câbles DAC passifs sont acceptés par défaut quel que soit l'état de déblocage. Si les liaisons sont assez courtes, vous pouvez contourner toute la question en câblant en DAC et en réservant les optiques aux liens qui en ont réellement besoin.
Petite correction sur « vit dans la configuration active » : sur l'ancien code avec lequel j'ai travaillé, il existait aussi une variante non documentée de la même commande, donc si vous tombez sur une référence qui ne correspond pas à la syntaxe ci-dessus, c'est de là qu'elle vient plutôt que d'une faute de frappe de quelqu'un.
Dans mon expérience, la clé prenait effet sans redémarrage également - la plupart des optiques tierces se sont mises à fonctionner juste après la saisie de la commande, bien que quelques modules aient continué à refuser quoi qu'il arrive. C'était il y a un moment sur du matériel que je n'ai plus, donc vérifiez ça sur votre propre boîtier avant de planifier une fenêtre de maintenance autour de ça.
Puisque cette comparaison revient à chaque fois que le sujet est abordé : sur Cisco IOS-XE et IOS XR, l'équivalent se fait en deux étapes plutôt qu'une. La commande globale seule ne suffit pas, il faut aussi la commande par interface sur chaque port physique censé accepter le module :
La ligne par interface est celle qui contourne la vérification de l'ID produit, donc le port va au moins tenter d'allumer l'optique - aucune garantie que le module fonctionne ensuite, seulement que la plateforme arrête de le refuser. Je l'ai fait sur IOS XR 5.3.3 et sur des boîtiers IOS-XE.
La réserve est la même chez les deux fournisseurs, et c'est la raison pour laquelle les gens continuent d'en débattre : si une panne est attribuée à un transceiver tiers installé par le client, le support sous garantie ou sous contrat peut être refusé. Ça passe pour un labo, c'est une décision à prendre consciemment en production.