Brocade 200e entre Proxmox et FreeNAS : Buffer I/O error et isp0: Receive Error alors que tous les ports sont online
Je gère une petite virtualisation : deux nœuds Proxmox 6 et une cible sur FreeNAS 11.2. Tant que les HBA étaient reliés directement à la cible, tout tournait pendant des mois sans une seule erreur. J'ai mis un Brocade 200e d'occasion entre eux pour ne pas tirer les câbles en croix, et ça a commencé.
- deux nœuds Proxmox 6, HBA QLogic QLE2462 et QLE2432
- cible FreeNAS 11.2
- switch Brocade 200e, Fabric OS 6.1.0a
- SFP et jarretières LC de vieux stocks, sans marquage
Sur les nœuds, dans le log :
Buffer I/O error on dev dm-5
et ensuite des réinitialisations constantes du périphérique. Côté cible - des timeouts firmware sur les commandes (CTIO7), et environ une fois par minute :
isp0: Receive Error
Après ça, la cible se déconnecte immédiatement des deux initiateurs, et ça ne se répare qu'en redémarrant le nœud.
Ce qui a déjà été fait :
- retour au branchement direct - aucune erreur du tout, donc les HBA, les disques et la cible elle-même n'y sont pour rien
switchshowmontre les trois ports online, un zonage minimal, une seule zone- rebranché les jarretières, redémarré le switch
Où regarder sur le switch lui-même ? online dans switchshow me trompe visiblement, mais je ne vois pas encore comment le vérifier.
Comments 4
Tu as déjà tout trouvé toi-même : les crc_err et enc_out qui augmentent, c'est de la corruption de trames sur la ligne, qui se transforme ensuite plus haut dans la pile en timeouts firmware, réinitialisations de périphérique et
isp0: Receive Error. Ni le noyau sur les nœuds, ni la cible n'y sont pour quoi que ce soit, ils rapportent honnêtement ce qui leur arrive.Ce que tu as déjà relevé se lit ainsi :
sfpshowsur ces deux mêmes ports, avec des cordons de longueur identique, c'est une comparaison entre liens symétriques, pas avec une norme sortie de nulle part. Le troisième port, propre, te sert de référenceIl ne reste plus grand-chose. Lance
fabriclog -s- on y voit les ports qui se rétablissent, même quand switchshow affiche online à ce moment-là. Et remplace sur les ports suspects le SFP en même temps que la jarretière LC, pas séparément. Chez moi, une histoire similaire s'est terminée exactement comme ça : remplacement des modules et des cordons sur les deux ports posant problème, après quoi porterrshow est resté à zéro pendant vingt-quatre heures sous charge, et la fabric ne s'est plus effondrée.La logique est simple : en direct, il y a deux connecteurs sur le trajet, via le switch, il y en a quatre, plus deux modules supplémentaires. Un SFP à la limite de puissance ou un cordon poussiéreux, que la liaison directe tolérait encore, ne passe plus sur un tel trajet. Donc online dans switchshow n'est pas un diagnostic, c'est juste le constat d'une connexion établie.
switchshow dit exactement une chose : le port a vu de la lumière et s'est connecté à la fabric. Il ne sait rien de la qualité du signal, donc lui faire confiance dans cette situation ne sert à rien.
Fais un
portstatsclearsur les trois ports, mets de la charge et regarde ensuiteporterrshow- ce qui intéresse, ce sont les crc_err et enc_out, s'ils augmentent et sur quels ports exactement. Fais aussi unsfpshowpar port : puissance en réception et tension, ça vaut la peine de les comparer entre ports. Et montre ce que renvoiesysctl dev.isp.0côté FreeNAS au moment où la cible se déconnecte.J'ai nettoyé les compteurs, mis de la charge, regardé. Le tableau est le suivant : sur deux ports, crc_err et enc_out augmentent par paquets, exactement au moment où les Buffer I/O error tombent sur les nœuds, et sur le troisième port, c'est à zéro.
sfpshowsur ces deux mêmes ports montre une réception nettement plus basse que sur le voisin, avec des cordons de longueur identique.sysctl dev.isp.0au moment de la déconnexion montre que le HBA se réinitialise, donc il réagit à une coupure plutôt qu'il n'en crée une. On dirait bien que c'est physique, pas Proxmox ni la cible.Ce piège existe aussi hors FC, donc ça vaut le coup de regarder les compteurs dans tous les cas. Il y a eu une combinaison Intel X520-2 avec des modules 10Gtek SR à 850 nm et un Brocade FastIron CX 648S-PoE avec un module FCX-2XG et des XFP Brocade, cinq mètres de fibre entre les deux.
Le serveur montait bien le 10GbE et transmettait, mais il n'y avait aucune réception, et le port sur le switch restait Up avec une vitesse à None. On a regardé
show media, comparé la longueur d'onde et la portée des deux côtés, désactivé la négociation de trunk sur le port - rien n'y a fait, la vitesse ne se fixe pas sur un XFP. La même fibre sur des ports SFP+ tournait tranquillement en gigabit. La morale est exactement la même que chez toi : Up sur le port ne veut pas dire que les trames arrivent.