Brocade 200e między Proxmox a FreeNAS: Buffer I/O error i isp0: Receive Error przy wszystkich portach online
Prowadzę niewielką wirtualizację: dwa węzły Proxmox 6 i target na FreeNAS 11.2. Póki HBA były połączone z targetem bezpośrednio, wszystko chodziło miesiącami bez jednego błędu. Wstawiłem między nie używanego wcześniej Brocade 200e, żeby nie ciągnąć kabli na krzyż, i się zaczęło.
- dwa węzły Proxmox 6, HBA QLogic QLE2462 i QLE2432
- target FreeNAS 11.2
- switch Brocade 200e, Fabric OS 6.1.0a
- SFP i patchcordy LC ze starych zapasów, bez oznaczeń
Na węzłach w logu:
Buffer I/O error on dev dm-5a zaraz potem ciągłe resety urządzenia. Po stronie targetu - timeouty firmware'u na komendach (CTIO7), a mniej więcej raz na minutę:
isp0: Receive ErrorPo tym target odpada od razu od obu inicjatorów, a pomaga na to tylko restart węzła.
Co już zrobiłem:
- wróciłem do podłączenia bezpośredniego - błędów nie ma w ogóle, czyli HBA, dyski i sam target są bez winy
switchshowpokazuje wszystkie trzy porty online, zonowanie minimalne, jedna strefa- przepiąłem patchcordy, zrestartowałem switch
Gdzie szukać na samym switchu? online w switchshow najwyraźniej mnie okłamuje, ale czym to sprawdzić, na razie nie wiem.
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
Sam już wszystko znalazłeś: rosnące crc_err i enc_out to psucie się ramek na linii, dalej w stosie zamienia się to w timeouty firmware'u, resety urządzenia i
isp0: Receive Error. Ani jądro na węzłach, ani target nie są tu winne, uczciwie opowiadają tylko o tym, co do nich doleciało.To, co już zebrałeś, czyta się tak:
sfpshowna tych samych dwóch portach przy sznurach o tej samej długości to porównanie symetrycznych linków między sobą, a nie z normą z głowy. Trzeci, czysty port działa u ciebie jako wzorzecDalej zostaje niewiele. Odpal
fabriclog -s- widać tam, jak porty się przełączają, nawet jeśli switchshow w tym momencie rysuje online. I zmieniaj na podejrzanych portach SFP razem z patchcordami LC, nie osobno. U mnie podobna historia skończyła się właśnie tak: wymiana modułów i sznurów na dwóch problematycznych portach, po czym porterrshow przez dobę pod obciążeniem został zerowy, a fabric przestał się sypać.Logika jest prosta: przy podłączeniu bezpośrednim na trasie są dwa konektory, przez switch - cztery, plus dwa dodatkowe moduły. Graniczny pod względem mocy SFP albo zapylony sznur, który wyciągał połączenie bezpośrednie, takiej trasy już nie pociągnie. Więc online w switchshow to nie diagnoza, a jedynie fakt zalogowania.
switchshow mówi dokładnie jedno: port zobaczył światło i zalogował się do fabric. O jakości sygnału nie wie nic, więc wierzyć mu w takiej sytuacji nie ma sensu.
Zrób
portstatsclearna wszystkich trzech portach, przepuść obciążenie i potem patrz naporterrshow- interesują crc_err i enc_out, czy rosną i na których dokładnie portach. Przy okazjisfpshowna każdym porcie: moc odbioru i napięcie, warto je porównać między portami. I pokaż, co zwracasysctl dev.isp.0po stronie FreeNAS w momencie, gdy target odpada.Wyczyściłem liczniki, dałem obciążenie, popatrzyłem. Obraz jest taki: na dwóch portach crc_err i enc_out rosną paczkami, dokładnie w tych momentach, kiedy na węzłach sypie Buffer I/O error, a na trzecim porcie zera.
sfpshowna tych samych dwóch portach pokazuje wyraźnie niższy odbiór niż na sąsiednim, przy sznurach o tej samej długości.sysctl dev.isp.0podczas odpadania pokazuje, że HBA się reinicjalizuje, czyli reaguje na zerwanie, a nie je tworzy. Wygląda na to, że to fizyka, a nie Proxmox czy target.Podobna pułapka zdarza się też poza FC, więc liczniki warto sprawdzać zawsze. Był zestaw Intel X520-2 z modułami 10Gtek SR na 850 nm i Brocade FastIron CX 648S-PoE z modułem FCX-2XG i brokadowskimi XFP, pięć metrów światłowodu między nimi.
Serwer uczciwie podnosił 10GbE i nadawał, a odbioru nie było w ogóle, i port na switchu wisiał Up z prędkością None. Patrzyliśmy na
show media, sprawdziliśmy długość fali i zasięg z obu stron, wyłączaliśmy negocjację trunku na porcie - niczym się to nie skończyło, prędkości na XFP się nie ustawi na sztywno. To samo włókno na portach SFP+ spokojnie chodziło na gigabicie. Morał dokładnie ten sam co u ciebie: Up na porcie nie znaczy, że ramki dojeżdżają.