Un Lenovo RackSwitch G8124E refuse un SFP+ SR 10G générique avec UNAPPROVED - SR SFP+ is DISABLED
Nous avons récupéré une paire de G8124E sur une baie décommissionnée et je les reconstruis comme couche d'agrégation pour un environnement de test interne. Le budget pour des optiques de marque est nul, donc tout part avec des modules SR 10G génériques du type qu'on fait déjà tourner ailleurs.
- Lenovo RackSwitch G8124E, châssis ex-marque IBM
- SFP+ SR 10G génériques, LC duplex, même lot que ceux qui fonctionnent dans notre top-of-rack de production
- cordon OM3 vers une carte réseau serveur qui établit un lien à 10G avec exactement le même type de module
Le port s'anime un instant puis le switch le coupe :
UNAPPROVED - SR SFP+ is DISABLEDAprès ça, le lien ne s'établit jamais et le port reste down.
Ce que j'ai déjà essayé :
- déplacé le module dans quatre cages différentes, message identique à chaque fois
- mis un second module du même lot puis un troisième d'un autre fournisseur
- parcouru la config d'interface à la recherche d'un réglage type allow-unsupported et n'ai rien trouvé
Y a-t-il un moyen de faire accepter des optiques tierces à ce boîtier, ou est-ce que le contrôle d'approbation ne peut être satisfait qu'avec des modules codés Lenovo ?
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 5
Avant que quiconque ne vous donne une commande, que rapporte
show version? Sur cette famille, le remède n'est pas une seule commande, il se divise par branche de code : ce que vous faites sur une image 7.x n'est pas ce que vous faites sur du 8.x, donc la version doit d'abord être établie.Dites aussi si les modules sont de simples génériques ou portent une chaîne de fabricant reconnaissable dans l'EEPROM. Le firmware évalue chaque module selon cette chaîne, et des gens avec du SFP+ codé Intel sur exactement ce switch obtiennent aussi l'avertissement de transceiver non approuvé, donc le message seul ne vous dit pas grand-chose sur l'optique elle-même.
show versionle place sur une image 7.x, donc l'ancienne branche et pas l'actuelle.Les modules sont de simples génériques, aucun codage Intel ou Cisco dedans, ils s'identifient comme l'OEM qui les a fabriqués. J'ai aussi mis le troisième module dans un IBM RackSwitch G8124 posé à côté et obtenu le même comportement là aussi, donc ce n'est pas une seule cage défectueuse ou une seule optique défectueuse.
Sur les anciennes branches, il existe une variable du chargeur de démarrage qui désactive le contrôle d'approbation. Elle est décrite pour 5.x, 6.x, 7.x et 8.3.x ou inférieur, donc un boîtier en 7.x est concerné.
Il vous faut la console série pour ça, le port mini-USB RS232, pas le réseau. Rechargez le switch et maintenez Shift+M pendant le test mémoire jusqu'à ce que le chargeur de démarrage vous donne l'invite
=>, puis :La valeur est sensible à la casse,
Overrideavec un O majuscule. Lancezprintenvavantbootpour vérifier réellement que la variable a été stockée. Une fois que le switch a fini de démarrer, il arrête de désactiver les modules SFP+ non approuvés et les ports montent simplement.Deux mises en garde. C'est une mesure de labo et d'urgence, Lenovo ne supporte pas les optiques tierces et rien ici n'est officiel. Et restez à l'écart des optiques double débit sur ces anciens boîtiers, elles causent des problèmes même une fois le contrôle écarté.
C'est la même histoire sur toute la gamme de switches Lenovo, pas seulement le G8124E. J'ai ici un G8272 qui évalue un
SFP-10G-LR-SCisco-Finisar comme Unapproved, montre le port comme Disabled et laisse le lien down. Optique Cisco authentique, simplement pas sur la liste de Lenovo.Du côté ThinkSystem, NE1032 et NE1032T, c'est du CNOS plutôt que de l'ENOS, et là le chemin d'entrée est une commande de plateforme pour autoriser les transceivers non supportés plutôt que l'astuce du chargeur de démarrage. Je ne l'ai pas testée moi-même, donc vérifiez la syntaxe sur votre propre boîtier avant de planifier une fenêtre autour de ça. Le schéma sous-jacent ne change pas : le firmware compare la chaîne de fabricant de l'EEPROM à une liste et désactive tout ce qu'il ne reconnaît pas.
Une chose à ajouter à ça : le contournement ne survit pas forcément à une mise à jour de firmware. Si vous poussez une nouvelle image et que les ports retombent morts, retournez sur la console série et vérifiez
printenvavant de commencer à retirer des modules, la variable a peut-être simplement disparu.Et ne traitez pas les commutateurs de déverrouillage constructeur comme fiables en général. Sur un Catalyst 9200 avec IOS-XE 16.9.x,
service unsupported-transceivern'a absolument aucun effet à cause de CSCvk03296, et ce que les gens ont utilisé à la place étaitno errdisable recovery cause gbic-invaliden config globale, ce qui empêchait les ports d'être err-disabled et laissait fonctionner les modules FS et Cables and Kits. Fabricant différent, même leçon : le réglage documenté et le réglage qui fonctionne réellement ne sont pas toujours le même.