Le Brocade G610 sous FOS 9.x met en défaut des optiques compatibles 16G SWL : Mod_Inv et Speed Mismatch / Incompatible SFP
Nous ajoutons de la capacité à une petite fabric FC et avons acheté des SFP+ 16G short-wave compatibles chez un fournisseur d'optiques plutôt que de payer le prix du fabricant du switch. Le switch les refuse.
- Brocade G610, Fabric OS 9.x
- SFP+ 16G SWL codés génériquement, longueur d'onde et portée correctes selon l'étiquette
- pièces codées Brocade 16G dans des ports voisins du même switch, fonctionnelles
- mêmes modules essayés dans un Brocade 300 plus ancien, même comportement
À l'insertion, le port se met en défaut :
switchshow
12 12 010c00 id N16 Mod_Inv FC Speed Mismatch / Incompatible SFP
sfpshow 12
Port does not use an SFP or is disabled!L'interface graphique est plus directe : Faulted due to SFP validation failure. Check if the SFP is valid for the configuration. et Port Health passe à FAULTY. errdump a une entrée de châssis correspondante à propos du port mis en défaut à cause d'un SFP invalide, d'une vitesse en conflit ou d'un défaut laser.
Déjà essayé :
- réinséré le module et déplacé sur deux autres ports, résultat identique partout
- fixé la vitesse du port à 16G au lieu de auto, aucun changement
- mis un module codé Brocade dans le même port pour prouver que le port et le câble vont bien, il établit le lien instantanément
Qu'est-ce que Fabric OS valide exactement ici, et y a-t-il quelque chose côté switch qui les ferait accepter, ou est-ce que les modules doivent simplement repartir ?
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 3
Cette sortie est cohérente, et rien de tout ça n'est une erreur de configuration de votre côté.
Fabric OS embarque des tables de correspondance et vérifie l'identité codée du transceiver conjointement avec les bits de vitesse pris en charge. Il s'attend à ce que les capacités de vitesse Fibre Channel soient codées, quelque chose comme 4/8/16G ou 8/16/32G selon la pièce. Un module codé génériquement, ou codé avec des débits Ethernet placés dans les champs de vitesse, échoue à ce contrôle même si les optiques sont de la bonne longueur d'onde et portée, donc le port est mis en défaut plutôt que de simplement rester down. Le
sfpshowvide est un effet de bord du même contrôle : une fois la validation échouée, le module se lit comme absent plutôt que comme rejeté, ce qui envoie les gens chasser des cages soi-disant mortes.Il n'y a aucun réglage côté switch pour contourner ça : la décision se fait sur le codage, pas sur le débit négocié. La sortie, c'est un module codé pour Fibre Channel avec les bons débits FC pour votre plateforme, correspondant à la matrice de support des transceivers Broadcom. Votre fournisseur peut normalement recoder les pièces que vous avez déjà, ce qui vaut mieux que de les renvoyer.
Le Brocade 300, le G610, le G720 et des boîtiers OEM comme l'IBM SAN64B-6 se comportent tous ainsi, et les variantes SWL, LWL, ELWL, CWDM et DWDM sont traitées de la même façon. C'est devenu nettement plus fréquent avec FOS 9.x, ce qui explique que des pièces qui allaient bien dans une fabric plus ancienne ne vont soudain plus.
Un piège si ça finit un jour dans un boîtier Gen 7 : un G720 refuse aussi les optiques non sécurisées, et même une pièce Brocade 32G comme la 57-1000333-01 se retrouve en Mod_Inv là-bas. Le Gen 7 veut les références sécurisées de la matrice, pas juste un codage FC correct.
Avant de les renvoyer, poussez le fournisseur sur un détail : quels débits sont réellement gravés dans les champs de capacité de vitesse de ces modules. Des débits Fibre Channel, quelque chose dans le genre 4/8/16G, ou des débits Ethernet ? Un codage générique sur l'étiquette ne vous dit rien là-dessus, et c'est habituellement là que ça coince.
À poster aussi :
sfpshowsur un des ports fonctionnels codés Brocade juste à côté du port en défaut, pour comparer quelle identité le switch lit dans chaque cas. Et ne perdez pas plus de temps sur le réglage de vitesse du port, ce n'est pas ce que le contrôle regarde.Je leur ai demandé, et c'est le second cas. Les champs de vitesse portent des débits Ethernet, il n'y a aucun débit FC défini là-dedans, rien dans le genre 4/8/16G que le switch puisse trouver. Les optiques ont la bonne longueur d'onde et portée pour du 16G SWL, mais l'identité n'a jamais été écrite pour une pièce Fibre Channel, et le fournisseur l'a concédé une fois que je leur ai cité l'erreur.
La comparaison que vous vouliez n'est pas très informative.
sfpshowsur le port fonctionnel juste à côté affiche le bloc d'identité complet comme prévu, tandis que sur le port en défaut j'obtiens toujours seulementdonc le switch ne le présente même pas comme un module refusé, la cage se lit comme vide. Et noté pour le réglage de vitesse du port, celui-là était déjà écarté avant que je poste.