Brocade 200e tussen Proxmox en FreeNAS: Buffer I/O error en isp0: Receive Error terwijl alle poorten online staan
Ik draai een kleine virtualisatieopstelling: twee Proxmox 6-nodes en een target op FreeNAS 11.2. Zolang de HBA's rechtstreeks met het target verbonden waren, liep alles maandenlang zonder een enkele fout. Ik zette er een tweedehands Brocade 200e tussen om niet kris-kras kabels te hoeven trekken, en toen begon het.
- twee Proxmox 6-nodes, HBA QLogic QLE2462 en QLE2432
- target FreeNAS 11.2
- switch Brocade 200e, Fabric OS 6.1.0a
- SFP en LC-patchkabels uit oude voorraad, zonder herkenningstekens
In het log op de nodes:
Buffer I/O error on dev dm-5en daarna voortdurende resets van het device. Aan de targetkant firmware-timeouts op commando's (CTIO7), en ongeveer eens per minuut:
isp0: Receive ErrorDaarna valt het target meteen bij beide initiators weg, en dat is alleen te verhelpen door de node te herstarten.
Al gedaan:
- de rechtstreekse verbinding teruggezet - helemaal geen fouten, dus de HBA's, de schijven en het target zelf zijn niet de oorzaak
switchshowtoont alle drie de poorten als online, minimale zonering, één zone- de patchkabels omgestoken, de switch herstart
Waar moet ik op de switch zelf naar kijken? Online in switchshow bedriegt me duidelijk, maar waarmee ik dat moet controleren, snap ik nog niet.
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
Je hebt het zelf al gevonden: oplopende crc_err en enc_out betekenen beschadigde frames op de lijn, verderop in de stack wordt dat timeouts van de firmware, resets van het device en
isp0: Receive Error. Noch de kernel op de nodes, noch het target heeft hier schuld, ze vertellen eerlijk wat hen overkomt.Wat je al hebt vastgelegd, laat zich zo lezen:
sfpshowop diezelfde twee poorten bij even lange snoeren is een vergelijking tussen symmetrische links onderling, niet met een norm uit je hoofd. De derde, schone poort werkt bij jou als referentieEr blijft niet veel meer over. Draai
fabriclog -s- daar zie je hoe poorten wegvallen en terugkomen, zelfs als switchshow op dat moment online tekent. En vervang op de verdachte poorten de SFP samen met de LC-patchkabels, niet apart. Bij mij eindigde een vergelijkbaar verhaal precies daarmee: modules en snoeren vervangen op de twee probleempoorten, waarna porterrshow een etmaal onder belasting op nul bleef, en de fabric niet meer instortte.De logica is simpel: bij een rechtstreekse verbinding zitten er twee connectoren op het traject, via de switch vier, plus twee extra modules. Een SFP die qua vermogen op de grens zit, of een stoffig snoer dat de rechtstreekse verbinding nog net trok, redt zo'n traject niet meer. Dus online in switchshow is geen diagnose, maar slechts het feit van een login.
switchshow zegt precies één ding: de poort heeft licht gezien en heeft zich aangemeld bij de fabric. Over de signaalkwaliteit weet het niets, dus het heeft geen zin om het in zo'n situatie te vertrouwen.
Doe
portstatsclearop alle drie de poorten, jaag er belasting doorheen en kijk daarna naarporterrshow- interessant zijn crc_err en enc_out, groeien ze en op welke poorten precies. Doe er meteensfpshowper poort bij: ontvangstvermogen en spanning, die zijn nuttig om tussen poorten te vergelijken. En laat zien watsysctl dev.isp.0aan de FreeNAS-kant teruggeeft op het moment dat het target wegvalt.Tellers schoongemaakt, belasting gegeven, gekeken. Het beeld is dit: op twee poorten lopen crc_err en enc_out met sprongen op, en precies op de momenten dat op de nodes Buffer I/O error naar binnen komt, terwijl de derde poort op nul staat.
sfpshowtoont op diezelfde twee poorten een merkbaar lager ontvangstniveau dan op de buurpoort, bij even lange snoeren.sysctl dev.isp.0toont tijdens het wegvallen dat de HBA opnieuw initialiseert, dus hij reageert op de onderbreking in plaats van hem te veroorzaken. Het lijkt erop dat dit fysiek is, en niet Proxmox of het target.Een vergelijkbare valkuil komt ook buiten FC voor, dus de tellers zijn sowieso de moeite van het bekijken waard. Er was een combinatie van een Intel X520-2 met 10Gtek SR-modules op 850 nm en een Brocade FastIron CX 648S-PoE met een FCX-2XG-module en Brocade-XFP's, vijf meter vezel ertussen.
De server bracht eerlijk 10GbE omhoog en zond, maar er kwam helemaal niets binnen, en de poort op de switch hing op Up met snelheid None. We bekeken
show media, vergeleken golflengte en reikwijdte aan beide kanten, schakelden de trunkonderhandeling op de poort uit - niets hielp, de snelheid op een XFP zet je niet vast. Diezelfde vezel liep op de SFP+-poorten rustig op gigabit. De moraal is precies dezelfde als bij jou: Up op de poort betekent niet dat de frames aankomen.