TL-SG3428X-M2 (V1): la jaula SFP+ 26 no da enlace con ningún TL-SM5310-T, la jaula 27 parpadea al usarla
Administro la red de una oficina pequeña, un solo armario de comunicaciones, y las cuatro jaulas SFP+ de nuestro switch de acceso llevan los enlaces de 10G hasta el rack de servidores. Funcionó meses sin problemas y ahora una jaula simplemente desapareció.
- TP-Link TL-SG3428X-M2 (V1), firmware 1.20.4 Build 20241104 Rel.40746, adoptado en Omada
- cuatro módulos TP-Link TL-SM5310-T 10GBASE-T en los puertos SFP+ 25-28
- latiguillos CAT6A, en el otro extremo hay dos servidores y un NAS
Estado de los puertos ahora mismo:
port 25 up, 10G
port 26 down, no link LED with any module
port 27 up, 10G, but drops for a moment whenever a cable goes into or out of port 26
port 28 up, 10GQué he probado:
- roté los módulos por las cuatro jaulas: el módulo del puerto 26 enlaza bien en 25 y 28, y cualquier módulo que meto en 26 se queda apagado, así que los módulos en sí están sanos
- latiguillos nuevos, distintos puertos en el otro extremo, sin cambios
- reinicio del switch, deshabilitar/habilitar el puerto, sin cambios
Lo que no puedo explicar es que el puerto 27 se sacuda cuando lo único que toco es el puerto 26. ¿Está muerta la jaula 26 y vale la pena un RMA, o hay algo más que descartar primero?
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 6
Esto es una regresión de firmware en 1.20.4 Build 20241104, no hardware muerto. El patrón que describes -una jaula SFP+ que nunca se enciende con módulos que se sabe que están bien, más un vecino que parpadea cuando se toca la muerta- es lo que hace esa versión con los módulos de cobre TL-SM5310-T.
Revierte el switch a la versión anterior y los puertos vuelven. En la práctica:
El propio personal de TP-Link reconoció que algo va mal en esa versión en switches Omada adaptados al controlador v5.14, dijo que lo estaban investigando y aconsejó quedarse en el firmware anterior por ahora. Así que no gastes un caso de soporte en el hardware, gástalo en el número de versión.
Si de verdad no puedes degradar la versión, la única solución temporal es vivir con las tres jaulas que sí funcionan y dejar el puerto 26 vacío. Eso no es una solución, solo una forma de seguir en servicio hasta que aparezca una versión corregida.
Antes de rellenar un formulario de RMA: ¿cuándo empezó esto, y el switch recibió una actualización de firmware más o menos por la misma fecha? 1.20.4 Build 20241104 es bastante reciente, y el controlador empuja alegremente una imagen nueva por su cuenta si se dejaron activadas las actualizaciones automáticas.
También vale la pena precisar: ¿el puerto 27 se sacude solo mientras el 26 tiene un módulo puesto, o también con el 26 vacío? Una jaula muerta normalmente no hace que un vecino parpadee. Esa parte huele mucho más al software detrás de los puertos que a una soldadura agrietada.
Mismo switch, misma versión aquí, así que no estás solo. El puerto 25 estaba bien, el puerto 26 no daba LED de enlace con ninguno de mis módulos, y el 27 y el 28 iban y venían -uno de ellos alimenta un EAP783, así que cada caída era muy visible. Pasé exactamente por el mismo ritual de intercambiar módulos y me convencí de que era una jaula muerta.
No era la jaula. El equipo había recibido una actualización de firmware poco antes de que empezaran los problemas, y volver a la imagen anterior recuperó los cuatro puertos SFP+. Revisa el historial de actualizaciones antes de mandar nada a ningún sitio.
Confirmado, y da vergüenza lo cerca que estuve de enviar el switch de vuelta. El historial de actualizaciones muestra que 1.20.4 Build 20241104 llegó unos días antes de que los puertos empezaran a comportarse raro, y yo nunca la inicié a mano, así que entró sola.
Volví a la versión anterior, readopté el equipo, y las cuatro jaulas están arriba a 10G, incluido el puerto 26. El puerto 27 ya no se sacude cuando trabajo en el 26. Las actualizaciones automáticas están desactivadas ahora y la imagen antigua está guardada en el servidor de archivos junto a la copia de la configuración.
Para el archivo: la misma familia tiene otra trampa de firmware que conviene conocer. En un TL-SX3008F (V1) con un SM5310-T(UN) alimentando una estación de trabajo, el firmware 1.20.2 y 1.20.3 dejaba el puerto SFP+ muerto en cuanto el PC entraba en suspensión o se apagaba. Mover el módulo a una jaula libre funcionaba exactamente una vez por jaula, y una vez usadas todas las jaulas solo un reinicio del switch devolvía los puertos. Fijar el puerto a 1G lo evitaba, al precio de la velocidad por la que pagaste.
Otro usuario tuvo lo mismo con módulos RJ45 de 10Gtek (ASF-10G2-T), Wiitek y Xicom detrás de un adaptador Iocrest AQC113. Degradar a 1.20.0 Build 20231011 Rel.42220 lo resolvió para los dos. Síntoma distinto, misma lección: el manejo de SFP+ de cobre en estas versiones es donde viven los errores.
Ten otra cosa más presente con esta línea de switches: un módulo inactivo puede costarte más que un puerto. En un TL-SX3016F con 1.0.0 Build 20210730 Rel.65115 la CPU se quedaba en 87-89% sin tráfico alguno y soltaba una línea CPU RISING THRESHOLD en el registro cada tres minutos.
La carga seguía el número de módulos instalados -un módulo 0-1%, dos 73-76%, tres o más 88-90%- y se debía a módulos Mellanox MFM1T02A-SR con la fibra conectada pero sin nada encendido en el otro extremo, así que el enlace se quedaba caído. Cambiarlos por Ubiquiti UF-MM-10G mantenía la CPU baja hiciera lo que hiciera el puerto, y simplemente retirar los módulos sin usar también lo curaba. La respuesta del propio TP-Link fue que un módulo ahí sentado con el enlace caído simplemente resulta caro para el chipset, y que la carga vuelve a bajar en cuanto el puerto enlaza correctamente. Eso deja sin explicar la parte incómoda: cambia de marca, deja el módulo igual de inactivo, y la CPU se queda tranquila. Así que una vez de vuelta en el firmware anterior, échale un vistazo también a la gráfica de la CPU.