Dell DD9900 im HA-Paar sieht kein SFP in ethMa: State UP, link status NO, Cannot get module EEPROM information
Ich betreue ein Backup-Storage im Rechenzentrum. Ein DD9900-Paar im HA-Verbund, die Netzwerkports sitzen auf NDC QLogic. Nach einem Neustart oder dem Neueinsetzen eines Moduls sieht der Port ethMa den Transceiver nicht mehr, und das ist kein Einzelfall mehr, sondern ein stabil wiederkehrendes Muster.
- Dell DD9900, DD OS 7.2.0.95, HA-Konfiguration
- NDC QLogic QL41164HMCU 4x10GbE (Dell 0XVVY1)
- Module ABCU-5710RZ-CS4B, FCLF-8521-3-HP, FTLX8571D3BCL-FC, AFBR-703ASDZ - betrifft Kupfer und Optik gleichermaßen
Was das System zeigt:
State UP
link status NO
Transceiver is unplugged
Cannot get module EEPROM informationethtool -m liefert für diesen Port gar nichts.
Was wir schon versucht haben:
- Module zwischen den Ports getauscht und Patchkabel gewechselt - das Problem hängt am Port, nicht am Modul
- den Link auf einen anderen Switch und einen anderen Switch-Port gelegt
- den NDC selbst gegen einen neuen getauscht, nach einiger Zeit kam genau dasselbe wieder
Der Port steht dabei weiter auf UP, das System hält also alles für in Ordnung und schlägt keinen Alarm. Wo grabe ich weiter - Treiber, DD OS oder doch die Hardware?
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
Wenn es sich auf einem Einzelsystem nicht reproduzieren lässt, auf HA aber stabil auftritt, kann man die Hardware aus dem Verdacht entlassen. Das ist ein Fehler im QLogic-Treiber, der genau in der HA-Konfiguration auf DD OS 7.2 auftaucht. Daher auch das ganze Bild: Der Port steht auf UP, es gibt keinen Link, und im Log stehen Transceiver is unplugged und Cannot get module EEPROM information. Der Treiber kommt schlicht nicht bis zum EEPROM des Moduls durch, und ob dort ein Kupfer- oder ein Optikmodul steckt, ist ihm egal - deshalb hat das Durchprobieren von Modulen, Kabeln, Switch-Ports und selbst der Tausch des NDC nichts gebracht.
Behoben wird das mit einem Update von DD OS auf mindestens 7.10.1, dort kommt ein aktualisiertes Bundle aus Firmware und Treibern mit, danach verschwindet das Symptom. Solange das Update-Fenster noch nicht abgestimmt ist:
Ein Hinweis zum Support: Vor dem Upgrade beim Vendor die Kompatibilitätsmatrix genau für eure HA-Konfiguration prüfen, 7.10.1 ist die untere Grenze und keine Empfehlung, exakt diese Version zu nehmen. Und für die Zukunft: In neueren DD-Modellen ist man von diesen NDCs auf Intel X710 umgestiegen, damit erledigt sich die Frage bei der nächsten Flottenerneuerung von selbst.
Drei Fragen, um den Kreis einzuengen. Erstens: Tritt das auch auf einem Einzelsystem auf oder nur im HA-Paar? Das ist entscheidend, weil HA verändert, wie Interfaces hochkommen und umziehen, und die Hälfte solcher Fälle hängt genau daran.
Zweitens: Stecken auf dieser Karte nur SFP-Module, oder hängt irgendwo im Nachbarport ein DAC? QLogic verbietet in der Dokumentation ausdrücklich, DAC und SFP auf derselben Karte zu mischen, und die Folgen sehen genau so aus - ein Teil der Ports liest das EEPROM nicht mehr.
Drittens: Läuft
ethtool -man den Nachbarports derselben Karte normal oder schweigt es dort auch?Wir haben einen Testaufbau zusammengestellt und durchlaufen lassen. Auf dem Einzelsystem mit denselben Modulen und derselben DD OS 7.2 ließ sich das überhaupt nicht reproduzieren, egal wie oft wir Module gezogen und neu gestartet haben. Es tritt nur im HA-Paar auf, und das scheint der Schlüssel zu sein.
DAC und SFP mischen wir auf einer Karte nicht, in allen vier Ports stecken Module desselben Typs.
ethtool -mliest an den Nachbarports normal, das EEPROM kommt vollständig zurück, nur bei ethMa erscheint genau dieses Cannot get module EEPROM information, bis der Port nach dem nächsten Neustart von selbst hochkommt.Dem "Weg von QLogic" schließe ich mich an. Wir hatten eine QLogic 8262 (Serie 8200) in FreeNAS 11.3-U5 auf einem HP MicroServer Gen10: Beide PCI-Funktionen werden erkannt, aber nur ql0 funktioniert, ql1 kommt als none2 hoch und initialisiert sich nicht, die halbe Karte ist also schlicht tot.
Im Log steht bei jedem Boot
0x200000 bytes of rid 0x10 res 3 failedund direkt danachunable to map any ports. Empfohlen wurde, mitpciconf -lzu prüfen, ob das nicht eine umgelabelte HP NC523SFP ist, die Adapter-Firmware zu aktualisieren und mit den MSI/MSI-X-Tunables zu spielen. Nichts davon hat geholfen, die Karte wurde am Ende ausgetauscht, und für Storage wird dort ganz offen zu Chelsio T520-CR oder Intel X520 geraten. Der Umstieg auf X710 in neueren Systemen wirkt vor diesem Hintergrund folgerichtig.