Dell DD9900 en paire HA ne voit pas le SFP dans ethMa : State UP, link status NO, Cannot get module EEPROM information
Je gère un stockage de sauvegarde dans un datacenter. Une paire de DD9900 en HA, ports réseau sur NDC QLogic. Après un redémarrage ou une réinstallation de module, le port ethMa arrête de voir le transceiver, et ce n'est plus un accident isolé mais un tour qui se répète de façon stable.
- Dell DD9900, DD OS 7.2.0.95, configuration HA
- NDC QLogic QL41164HMCU 4x10GbE (Dell 0XVVY1)
- modules ABCU-5710RZ-CS4B, FCLF-8521-3-HP, FTLX8571D3BCL-FC, AFBR-703ASDZ - ça accroche aussi bien le cuivre que l'optique
Ce qui est visible dans le système :
State UP
link status NO
Transceiver is unplugged
Cannot get module EEPROM informationethtool -m sur ce port ne rend rien.
Ce qui a déjà été essayé :
- déplacé les modules entre les ports et changé les cordons - le problème suit le port, pas le module
- rebasculé le lien sur un autre switch et sur un autre port du switch
- remplacé le NDC lui-même par un neuf, au bout d'un moment on a retrouvé exactement la même chose
Le port est pourtant listé comme UP, c'est-à-dire que le système pense que tout va bien, et ne remonte aucun signal d'alarme. Où creuser ensuite - le driver, DD OS, ou quand même le matériel ?
Show original (Русский)
Also available in: Русский
العربية
Deutsch
English
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Türkçe
Tiếng Việt
简体中文
Comments 4
Puisque ça ne se reproduit pas sur un système isolé mais de façon stable en HA, on peut lâcher le matériel. C'est un défaut du driver QLogic qui ressort justement dans une configuration HA sur DD OS 7.2. D'où tout le tableau : le port est listé UP, il n'y a pas de lien, et dans le log Transceiver is unplugged et Cannot get module EEPROM information. Le driver n'arrive tout simplement pas jusqu'à l'EEPROM du module, et peu importe quel module est en place, cuivre ou optique, ça lui est égal - c'est pourquoi permuter les modules, les cordons, les ports du switch et même remplacer le NDC n'a rien donné.
Ça se soigne en mettant à jour DD OS au minimum vers 7.10.1, où arrive un bundle mis à jour de firmwares et de drivers, après quoi le symptôme disparaît. Tant que la fenêtre de mise à jour n'est pas validée :
Mise en garde sur le support : avant la mise à jour, vérifiez avec le vendeur la matrice de compatibilité pour votre configuration HA exacte, 7.10.1 est un plancher, pas une recommandation de s'y tenir pile. Et pour l'avenir : dans les DD plus récents, ces NDC ont laissé la place à des Intel X710, donc en renouvelant le parc la question se règle d'elle-même.
Trois questions pour resserrer le cercle. Premièrement : ça se produit sur un système isolé ou seulement sur la paire HA ? C'est déterminant, parce que le HA change la façon dont les interfaces montent et migrent, et la moitié de ce genre d'histoires vit exactement là.
Deuxièmement : sur cette carte il n'y a que des modules SFP, ou y a-t-il un DAC sur un port voisin ? QLogic interdit explicitement dans sa documentation de mélanger DAC et SFP sur la même carte, et les conséquences sont exactement celles-là - une partie des ports arrête de lire l'EEPROM.
Troisièmement :
ethtool -msur les ports voisins de la même carte fonctionne normalement ou est aussi silencieux ?Monté un banc et testé. Sur un système isolé avec les mêmes modules et la même DD OS 7.2, impossible de reproduire du tout, malgré tous les modules permutés et redémarrages. Ça ne se produit que sur la paire HA, et c'est apparemment la clé.
On ne mélange pas DAC et SFP sur la même carte, les quatre ports ont des modules du même type.
ethtool -mse lit normalement sur les ports voisins, l'EEPROM sort en entier, et sur ethMa c'est le fameux Cannot get module EEPROM information, jusqu'à ce que le port se remette en route tout seul après un redémarrage.Je signe des deux mains pour « quitter QLogic ». Il y avait une carte QLogic 8262 (série 8200) dans un FreeNAS 11.3-U5 sur un HP MicroServer Gen10 : les deux fonctions PCI sont visibles, seul ql0 fonctionne, et ql1 monte comme none2 sans s'initialiser, donc la moitié de la carte est tout simplement morte.
Dans le log à chaque démarrage
0x200000 bytes of rid 0x10 res 3 failedpuisunable to map any ports. On a conseillé de vérifier viapciconf -ls'il ne s'agissait pas d'une HP NC523SFP re-marquée, de mettre à jour le firmware de l'adaptateur et de jouer avec les réglages MSI/MSI-X. Rien de tout ça n'a aidé, la carte a finalement été remplacée, et pour du stockage on y conseille explicitement un Chelsio T520-CR ou un Intel X520. Donc le passage vers le X710 dans les nouveaux systèmes paraît logique.