El IBM Flex System EN4093 deja los puertos trunk SFP+ en ERRDISABLE al arrancar y durante la operación
Dos chasis Flex System, cada uno con un switch escalable 10Gb EN4093R (opción 49Y4270) como módulo de red. Los puertos vuelven en estado de error tras un evento de energía del chasis, y con menos frecuencia caen en el mismo estado mientras todo está funcionando. No siempre son los mismos puertos, lo que hace que sea tan tedioso perseguirlo.
Montaje:
- IBM Flex System EN4093 10Gb Scalable Switch, opción 49Y4270
- trunk de enlace ascendente de cuatro puertos al core, ópticas IBM más un DAC añadido después
- puerto QSFP+ desglosado hacia el segundo chasis
- MSTP corriendo en nuestro lado, el core es de otro fabricante
Lo que muestra la lista de puertos tras un arranque:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesProbado:
- shutdown / no shutdown en los puertos afectados devuelve la mayoría hasta el siguiente evento
- limpié y reasenté cada fibra del trunk, sin cambio en el patrón
- comparé la configuración del puerto en el extremo remoto, las velocidades coinciden sobre el papel
¿Qué está realmente empujando estos puertos a errdisable, y hay una forma de evitar que ocurra en cada arranque en vez de limpiarlo a mano cada vez?
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
Este switch tiene siete estados documentados que desactivan un puerto, y tienen muy poco que ver entre sí:
El tuyo es el cuarto, y es el que más gente encuentra, porque es el que uno mismo construye: mezcla velocidades o tipos de módulo dentro de un mismo trunk y el switch protesta. Un solo DAC junto a tres módulos ópticos basta. Saca el DAC de ahí y llena la ranura con un módulo que coincida con los otros tres.
Para el puerto en el detector de flapping, reiniciarlo sigue siendo la recuperación documentada:
Después de eso, vuelve a leer la configuración de spanning tree en ese enlace y revisa el cobre y la fibra a mano. Sigue cualquier cambio de configuración con un reload, o el estado en ejecución silenciosamente deja de coincidir con lo que crees que configuraste.
Dos cosas que no esperar. Dos de esos siete estados mantienen el puerto caído después de que expira el tiempo de espera y quieren una mano en el puerto. Y ninguna versión de firmware arregla esto - la línea del fabricante es que configures a tu alrededor, así que módulos idénticos en cada miembro del trunk más fibra limpia es hasta donde llega la prevención.
Dos razones distintas en el mismo pegado es por donde yo empezaría. ¿Un puerto dado siempre vuelve desactivado por la misma razón, o uno que cayó por capacidades este arranque dispara el detector de flapping el siguiente? Una razón que se queda fija por puerto y una que vaga son dos investigaciones separadas, y solo una de ellas termina contigo comprando hardware.
Lo segundo que vale la pena precisar es qué corre el core para spanning tree. Estás en MSTP; si el lado remoto pone BPDU con sabor PVST de Cisco en esos enlaces ascendentes, este switch tiene un mecanismo de protección que reacciona exactamente a eso y tumba el puerto, y desde fuera se ve como el fallo que ya estás persiguiendo. ¿Puedes saber si alguna de las caídas coincide con un cambio de topología en el core en vez de con tus propios arranques?
Por puerto es consistente, en toda la caja no lo es. Los miembros del trunk que caen siempre vuelven con capacidades de enlace no coincidentes, y el puerto de acceso en 5 solo dispara el detector de flapping, sin ningún intervalo en el que pueda encontrar un patrón. Así que sí parece dos fallos con la misma chaqueta.
Spanning tree del lado remoto todavía no puedo responderlo - el core pertenece a otro equipo y les pregunté qué emite realmente en esos enlaces ascendentes. Nada en nuestro log ata hasta ahora una caída a un cambio de topología allá, pero lo estaba leyendo buscando eventos de enlace en vez de eso, así que no lo daría por descartado.
Fabricante distinto, misma forma. Teníamos un FortiGate 201F colgado de un FortiSwitch 548D por SFP+ con el propio DAC de Fortinet entre ellos, y el enlace de 10Gbps simplemente no se mantenía arriba - caía hiciéramos lo que hiciéramos con velocidad y dúplex, y retroceder ambos extremos de FortiOS 7.4 a 7.2.5 no cambió nada.
Lo que finalmente se sostuvo fue un DAC de Fortinet más corto con STP apagado en ese enlace en particular, y ha estado arriba desde entonces. La parte que vale la pena llevarse es el razonamiento que vino después: cuanto más largo el tramo de cobre pasivo, más se ha degradado la señal para cuando llega, así que a 10G cualquier DAC largo o al límite pertenece a la lista de sospechosos sin importar la marca impresa en él. Con tres ópticas y un DAC en un trunk en errdisable, yo estaría mirando muy de cerca al que no encaja.
Una cosa que hacer antes de tocar ningún hardware: anota la cadencia exacta de los flaps contra las marcas de tiempo del log.
En un switch completamente distinto, un TL-SG3452X, cada puerto SFP+ poblado se caía y volvía a subir cada diez a quince minutos con mensajes de STP en el log en cada flap, y la conclusión obvia era óptica defectuosa - hasta que un DAC de primera marca TL-SM5220-1M hizo flap exactamente en el mismo ritmo. Eso mató la teoría de la óptica en una sola prueba y apuntó en su lugar a una regresión de firmware; la única respuesta que funcionó ahí fue quedarse en la build más antigua.
Un intervalo regular significa que algo está expirando según un horario. Uno aleatorio significa algo físico. Prueba barata, y te ahorra comprar módulos que no necesitas. También compensa guardar la imagen de firmware anterior a mano para que un downgrade siga siendo una opción.