Un SFP+ FC 32G tiers dans un Brocade G610 : Mod_Inv est-il la fin de la conversation
Nous ajoutons un G610 à une fabric existante et il reste une boîte de SFP+ FC 16G/32G non-Brocade d'une autre installation. Avant de planifier des ports autour d'eux, j'en ai mis un dans un port libre sur l'établi pour voir ce que le switch en fait.
- Brocade G610, Gen 6
- SFP+ FC 32G tiers, aucun marquage Brocade sur le module
- optiques 16G de marque Brocade récupérées d'un switch plus ancien, pour comparaison
- même cordon de brassage dans les deux tests
switchshow
...
8 8 010800 id N32 Mod_InvIl y a aussi une entrée dans le journal d'erreurs système à propos d'un transceiver non qualifié à chaque insertion du module.
Ce que j'ai essayé :
- déplacé le module vers un autre port et réinséré correctement par la languette
- changé le câble et confirmé que le port se lie bien avec une optique de marque
- parcouru la documentation Fabric OS à la recherche de quoi que ce soit qui laisse passer un module non qualifié
Y a-t-il un moyen supporté de faire tourner des optiques non qualifiées dans un G610, ou est-ce que Mod_Inv est simplement la fin de la conversation sur cette plateforme ? Je préférerais le savoir maintenant plutôt qu'après que les optiques soient sur un bon de commande.
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 4
Mod_Inv est un comportement documenté, pas une panne sur votre établi. Le guide d'installation matérielle du G610 ne laisse aucune place à l'interprétation : un module doit être qualifié pour les produits Brocade avant que le switch ne le fasse fonctionner, et tout le reste est mis de côté en Mod_Inv avec une ligne écrite dans le journal d'erreurs système. Aucun contournement n'est documenté - aucun réglage, aucun mode optiques-non-supportées, rien à activer.
La liste qu'il vous faut avant que quoi que ce soit n'aille sur un bon de commande, c'est la Brocade Transceiver Support Matrix, organisée par plateforme avec les références de fabrication et de commande. Si une référence n'est pas listée pour le G610, planifiez en conséquence plutôt que d'espérer.
Puisque vous manipulez des optiques en vrac de toute façon : tirez-les par la languette, elles chauffent ; poussez jusqu'à ce que le loquet clique ; et faites attention au sens - dans la rangée supérieure de ports, le bord à contact doré est vers le bas, dans la rangée inférieure il est vers le haut. Ne forcez pas non plus un câble prévu pour un autre type de transceiver dans la cage, il ira assez loin pour avoir l'air en place et se comportera ensuite exactement comme un module défectueux.
Compris pour les modules sans marque, ils retournent dans la boîte.
Ce à quoi je ne m'attendais pas : une des optiques 16G étiquetées Brocade que j'ai récupérées de l'ancien switch atterrit aussi en Mod_Inv sur le G610, alors que celle qui lui ressemble exactement, juste à côté, monte et se lie normalement.
sfpshowme donne un nom de vendor Brocade et une référence sur les deux, et les deux fonctionnent dans le châssis d'où elles viennent.Donc l'étiquette sur le module n'est clairement pas toute l'histoire. Qu'est-ce que Fabric OS pèse d'autre avant de décider qu'une optique est qualifiée ?
L'étiquette n'est pas le critère - c'est la combinaison de la référence, du préfixe de numéro de série et de la version de Fabric OS. La matrice de support est par plateforme et porte une longue traîne de notes de bas de page, et c'est exactement là que vit ce genre de surprise.
Quelques-unes, pour que vous voyiez la forme de la règle. Les optiques sécurisées sont le cas le plus bruyant : dans une lame SX6 ou un 7810, elles ne monteront pas en dessous de 8.2.1e ou 8.2.2c, alors que partout ailleurs les mêmes modules n'ont aucune condition de version du tout. Le QSFP FC 4x32G à 2 km veut du 8.1.0b une fois dans un port ICL X6. Ensuite ça se resserre jusqu'au numéro de série - un préfixe JDB vous pousse vers 9.1.1a ou 9.2.0, d'autres références vers 9.2.0c2 ou 9.2.1b, un préfixe BAB1 vers 9.2.0 - et plusieurs références 64G ont chacune leur propre plancher : 9.0.1a, 9.1.0, 9.1.1, dans un cas 10.0.1. Quelques entrées sont plafonnées à 32G/16G, et le FC32-64 a ses propres exclusions.
Version pratique pour vos deux modules : prenez la référence et le préfixe de numéro de série depuis
sfpshow, la version depuisfirmwareshow, puis lisez la ligne de la matrice pour votre plateforme avant de déclarer quoi que ce soit défectueux. Encore un piège dans la même table : le XBR-000479 insiste pour avoir des optiques identiques aux deux extrémités.Par contraste, les descendants côté Ethernet de ces mêmes familles Brocade répondent à la question dans un registre complètement différent. SLX, VDX et MLX sont maintenant sous Extreme, et leur portail d'optiques tient une liste approuvée par famille - modules, adaptateurs, cordons de brassage et câbles de dérivation compris. La note de politique est sans détour : du matériel tiers qui n'est pas sur cette liste n'a droit à aucune garantie et aucune déclaration de conformité ; faites tourner une optique hors de cette liste, ou le module d'interface à côté, et le risque est entièrement le vôtre - aucune responsabilité, aucune obligation de service de la part d'Extreme. Les pièces listées portent des documents de certification : CE et CDRH, EN60825-1, GR-468, FCC CFR 21 1040.10, NRTL. Ce que le portail ne dit pas, c'est ce qu'une plateforme donnée fait réellement avec un module non listé - donc là, « non supporté » est une déclaration commerciale, alors que sur votre G610 c'est appliqué par le firmware.
Sur les switches FC plus anciens - 300, 6505, 6510, 6520 - la FAQ déclare que des SFP de marque Brocade sont requis et l'explique par les tolérances plus serrées de longueur d'onde et de paramètres à 16G, où un module hors spécification peut mettre un port en défaut et faire tomber des applications avec lui. C'est le raisonnement du vendor lui-même tel qu'écrit, pas quelque chose de mesuré.