Brocade 200e zwischen Proxmox und FreeNAS: Buffer I/O error und isp0: Receive Error, obwohl alle Ports online sind
Betreibe eine kleine Virtualisierung: zwei Proxmox-6-Knoten und ein Target auf FreeNAS 11.2. Solange die HBAs direkt mit dem Target verbunden waren, lief monatelang alles ohne einen einzigen Fehler. Habe einen gebrauchten Brocade 200e dazwischengesetzt, um nicht die Kabel über Kreuz zu ziehen, und dann ging es los.
- zwei Proxmox-6-Knoten, HBA QLogic QLE2462 und QLE2432
- Target FreeNAS 11.2
- Switch Brocade 200e, Fabric OS 6.1.0a
- SFP und LC-Patchkabel aus alten Beständen, ohne Kennzeichnung
Auf den Knoten im Log:
Buffer I/O error on dev dm-5und danach laufend Geräte-Resets. Auf der Target-Seite Firmware-Timeouts bei Befehlen (CTIO7), und etwa einmal pro Minute:
isp0: Receive ErrorDanach fällt das Target sofort bei beiden Initiatoren weg, und das kuriert nur ein Neustart des Knotens.
Was ich schon gemacht habe:
- die direkte Verbindung wiederhergestellt - überhaupt keine Fehler, HBA, Platten und das Target selbst sind also nicht die Ursache
switchshowzeigt alle drei Ports als online, minimales Zoning, eine Zone- Patchkabel umgesteckt, Switch neu gestartet
Wo am Switch selbst nachsehen? online in switchshow täuscht mich offensichtlich, aber womit ich das prüfen kann, verstehe ich noch nicht.
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
Du hast selbst schon alles gefunden: wachsende crc_err und enc_out sind Frameverfälschung auf der Leitung, weiter oben im Stack wird daraus Firmware-Timeouts, Geräte-Resets und
isp0: Receive Error. Weder der Kernel auf den Knoten noch das Target sind hier schuld, sie berichten ehrlich, was bei ihnen ankam.Was du schon abgeklopft hast, liest sich so:
sfpshowan denselben zwei Ports bei gleich langen Schnüren ist ein Vergleich symmetrischer Links untereinander, nicht mit einer Norm aus dem Kopf. Der dritte, saubere Port dient dir als MaßstabDanach bleibt nicht mehr viel.
fabriclog -slaufen lassen - dort sieht man, wie Ports durchgeschüttelt werden, selbst wenn switchshow in diesem Moment online zeichnet. Und an den verdächtigen Ports SFP zusammen mit den LC-Patchkabeln tauschen, nicht einzeln. Bei mir endete eine ähnliche Geschichte genau damit: Austausch von Modulen und Schnüren an den zwei problematischen Ports, danach blieb porterrshow einen Tag lang unter Last bei null, und die Fabric ist nicht mehr auseinandergefallen.Die Logik ist einfach: Bei Direktverbindung liegen zwei Steckverbinder auf der Strecke, über den Switch vier, plus zwei zusätzliche Module. Ein SFP am Rand seiner Leistungsfähigkeit oder eine verstaubte Schnur, die die Direktverbindung noch durchgezogen hat, trägt so eine Strecke nicht mehr. online in switchshow ist also keine Diagnose, sondern nur die Tatsache eines Logins.
switchshow sagt genau eins: Der Port hat Licht gesehen und sich in der Fabric eingeloggt. Über die Signalqualität weiß er nichts, ihm in so einer Situation zu vertrauen ist also sinnlos.
portstatsclearan allen drei Ports ausführen, Last durchlaufen lassen und danachporterrshowansehen - interessant sind crc_err und enc_out, ob sie wachsen und an welchen Ports genau. Gleichzeitigsfpshowpro Port: Empfangsleistung und Spannung, die lohnt es sich zwischen den Ports zu vergleichen. Und zeigen, wassysctl dev.isp.0auf der FreeNAS-Seite in dem Moment liefert, in dem das Target wegfällt.Zähler geleert, Last gegeben, nachgesehen. Das Bild sieht so aus: An zwei Ports wachsen crc_err und enc_out in Schüben, und zwar genau in den Momenten, in denen auf den Knoten Buffer I/O error hereinbricht, am dritten Port bleibt es bei null.
sfpshowzeigt an denselben zwei Ports einen deutlich niedrigeren Empfang als am Nachbarn, bei gleich langen Schnüren.sysctl dev.isp.0zeigt während des Wegfalls, dass sich der HBA neu initialisiert, er reagiert also auf den Abriss, statt ihn zu verursachen. Sieht nach Physik aus, nicht nach Proxmox und nicht nach dem Target.Eine ähnliche Falle gibt es auch außerhalb von FC, Zähler lohnt es sich also so oder so anzuschauen. Es gab eine Kombination aus Intel X520-2 mit 10Gtek-SR-Modulen bei 850 nm und einem Brocade FastIron CX 648S-PoE mit einem FCX-2XG-Modul und Brocade-XFPs, fünf Meter Faser dazwischen.
Der Server hat ehrlich 10GbE hochgefahren und gesendet, Empfang gab es aber überhaupt keinen, und der Port am Switch hing bei Up mit Speed None.
show mediaangeschaut, Wellenlänge und Reichweite auf beiden Seiten verglichen, die Trunk-Verhandlung am Port abgeschaltet - nichts davon führte irgendwohin, die Geschwindigkeit lässt sich am XFP nicht festnageln. Dieselbe Faser lief an den SFP+-Ports problemlos mit Gigabit. Die Moral ist genau dieselbe wie bei dir: Up am Port heißt nicht, dass die Frames ankommen.