L'IBM Flex System EN4093 fait passer des ports trunk SFP+ en ERRDISABLE au démarrage et en fonctionnement
Deux châssis Flex System, chacun avec un switch EN4093R 10Gb Scalable (option 49Y4270) comme module réseau. Les ports reviennent error-disabled après un événement d'alimentation du châssis, et moins souvent tombent dans le même état pendant que tout fonctionne. Ce n'est pas toujours les mêmes ports, ce qui rend la chasse fatigante.
Installation :
- IBM Flex System EN4093 10Gb Scalable Switch, option 49Y4270
- trunk d'uplink de quatre ports vers le cœur, optiques IBM plus un DAC ajouté plus tard
- port QSFP+ éclaté vers le second châssis
- MSTP tourne de notre côté, le cœur est d'un autre fabricant
Ce que montre la liste des ports après un démarrage :
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesEssayé :
- shutdown / no shutdown sur les ports affectés en ramène la plupart jusqu'au prochain événement
- nettoyé et réinséré chaque fibre du trunk, aucun changement au schéma
- comparé la configuration du port distant, les vitesses correspondent sur le papier
Qu'est-ce qui pousse réellement ces ports en errdisable, et y a-t-il un moyen d'empêcher que ça arrive à chaque démarrage plutôt que de le nettoyer à la main à chaque fois ?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
Ce switch a sept états documentés qui désactivent un port, et ils ont très peu de rapport entre eux :
Le vôtre est le quatrième, et c'est celui que la plupart des gens rencontrent, parce que c'est celui qu'on se construit soi-même : mélanger des vitesses ou des types de modules dans un seul trunk et le switch s'y oppose. Un DAC assis à côté de trois modules optiques suffit. Retirez le DAC de là et remplissez le slot avec un module correspondant aux trois autres.
Pour le port sur le détecteur de flap, le faire basculer reste la récupération documentée :
Après ça, relisez la configuration du spanning tree sur ce lien et vérifiez le cuivre et la fibre à la main. Faites suivre tout changement de configuration d'un reload, sinon l'état en cours d'exécution cesse discrètement de correspondre à ce que vous pensez avoir réglé.
Deux choses à ne pas attendre. Deux de ces sept états gardent le port down après l'expiration du délai et veulent une intervention manuelle sur le port. Et aucune version de firmware ne corrige ça - la position du fabricant est que vous configurez pour contourner le problème, donc des modules identiques sur tous les membres du trunk plus une fibre propre, c'est tout ce que la prévention peut offrir.
Deux raisons différentes dans le même collage, c'est par là que je commencerais. Est-ce qu'un port donné revient toujours désactivé pour la même raison, ou est-ce qu'un port tombé pour des raisons de capacités déclenche le détecteur de flap la fois suivante ? Une raison qui reste fixe par port et une raison qui se balade sont deux investigations séparées, et une seule des deux finit par vous faire acheter du matériel.
La seconde chose qui vaut le coup d'être vérifiée, c'est ce que le cœur de réseau fait tourner comme spanning tree. Vous êtes en MSTP ; si le côté distant met des BPDU de type PVST Cisco sur ces uplinks, ce switch a un mécanisme de protection qui réagit exactement à ça et fait tomber le port, et de l'extérieur ça ressemble à la panne que vous chassez déjà. Pouvez-vous dire si l'une des chutes coïncide avec un changement de topologie sur le cœur plutôt qu'avec vos propres démarrages ?
Par port c'est cohérent, sur l'ensemble du boîtier ça ne l'est pas. Les membres du trunk qui tombent reviennent toujours avec mismatched link capabilities, et le port d'accès sur 5 ne déclenche jamais que le détecteur de flap, sans intervalle dans lequel je trouve un motif. Donc ça ressemble bien à deux pannes portant le même manteau.
Le spanning tree du côté distant, je ne peux pas encore répondre - le cœur appartient à une autre équipe et je leur ai demandé ce qu'il émet réellement sur ces uplinks. Rien dans notre journal ne relie une chute à un changement de topologie là-bas jusqu'ici, mais je le lisais pour des événements de lien plutôt que pour ça, donc je ne dirais pas que c'est écarté.
Fabricant différent, même forme. Nous avions un FortiGate 201F accroché à un FortiSwitch 548D en SFP+ avec un DAC Fortinet entre les deux, et le lien 10Gbps ne voulait tout simplement pas rester up - il tombait quoi qu'on fasse à la vitesse et au duplex, et revenir aux deux extrémités de FortiOS 7.4 à 7.2.5 n'a rien changé.
Ce qui a fini par tenir, c'est un DAC Fortinet plus court avec STP désactivé sur ce lien-là, et c'est up depuis. Ce qui vaut le coup d'être retenu, c'est le raisonnement qui a suivi : plus le tronçon cuivre passif est long, plus le signal s'est dégradé à l'arrivée, donc à 10G, tout DAC long ou limite mérite d'être sur la liste des suspects quelle que soit l'étiquette imprimée dessus. Avec trois optiques et un DAC dans un trunk en errdisable, je regarderais de près celui qui détonne.
Une chose à faire avant de toucher à aucun matériel : notez la cadence exacte des flaps par rapport aux horodatages du journal.
Sur un switch complètement sans rapport, un TL-SG3452X, chaque port SFP+ occupé tombait et remontait toutes les dix à quinze minutes avec des messages STP dans le journal à chaque flap, et la conclusion évidente était de mauvaises optiques - jusqu'à ce qu'un DAC de marque TL-SM5220-1M flappe exactement au même rythme. Ça a tué la théorie des optiques en un seul test et pointé plutôt vers une régression de firmware ; la seule solution qui a fonctionné là-bas était de rester sur l'ancienne build.
Un intervalle régulier signifie que quelque chose expire selon un horaire. Un intervalle aléatoire signifie quelque chose de physique. Test bon marché, et ça évite d'acheter des modules dont vous n'avez pas besoin. Ça vaut aussi le coup de garder l'ancienne image de firmware sous la main pour qu'un retour en arrière reste possible.