Un enlace 2.5GbE que baja a 100Mbps solo después de la suspensión o el reinicio suele apuntar a una renegociación del estado de energía, al comportamiento del controlador o a un par físico defectuoso.
Este es un problema diferente al de un puerto que nunca puede negociar por encima de 1GbE. Primero comprueba que el enlace alcance 2.5GbE desde un estado de funcionamiento en frío; después reproduce la caída tras la suspensión o el reinicio usando el mismo cable y el mismo puerto del switch. Compara los modos anunciados, la configuración de ahorro de energía, el estado del controlador y los contadores de errores antes de sustituir toda la ruta de red.
Comprueba que la caída a 100Mbps ocurre únicamente después de una transición de energía
Registra la velocidad negociada inmediatamente después de un arranque en frío limpio, tras varios minutos de tráfico, después de suspender y reanudar el sistema, y después de un reinicio normal. Usa el estado del puerto de la NIC y del switch en lugar de los resultados de las pruebas de velocidad de Internet.
Un artículo de diagnóstico de Realtek describe un problema del estado del enlace durante la suspensión profunda y muestra por qué la propia transición puede ser el factor diferenciador útil.
Si el enlace comienza a solo 100Mbps incluso desde un arranque en frío, vuelve al artículo genérico sobre negociación. Si comienza de forma fiable a 2.5GbE y solo cae después de la suspensión o el reinicio, conserva ese cambio de estado para las siguientes pruebas.
Comprueba la configuración de ahorro de energía de la NIC antes de cambiar el cable
Inspecciona la configuración de administración de energía y del controlador avanzado del adaptador para comprobar Energy Efficient Ethernet, Green Ethernet, Reducir la velocidad al apagar, la velocidad del enlace para Wake-on-LAN y el permiso del sistema operativo para apagar la NIC.
Una guía actual sobre optimización de Ethernet señala que la administración de energía puede desactivar los adaptadores de forma independiente a la configuración habitual de velocidad y dúplex.
Desactiva o cambia una opción de energía relevante cada vez y repite la misma prueba de suspensión y reanudación. No desactives todas las funciones de descarga y rendimiento a la vez, porque un resultado satisfactorio no revelaría qué configuración fue realmente importante.
Vuelve a comprobar el controlador y el chipset después de reanudar
Registra el chipset exacto de la NIC, la versión activa del controlador, el firmware cuando corresponda y los modos de enlace anunciados antes y después de la caída. Una ruta de reanudación puede volver a cargar el mismo dispositivo con un estado diferente del controlador aunque el nombre de la interfaz no cambie.
El análisis de PLANEX sobre adaptadores 2.5GbE muestra que los controladores 2.5GbE exponen controles de energía junto con la configuración habitual de Ethernet.
Si actualizar o revertir el controlador de la NIC elimina la reducción posterior a la reanudación mientras el cable y el switch permanecen sin cambios, documenta esa versión. Evita forzar una velocidad estática como primera solución, porque podría ocultar un problema de autonegociación o de reanudación.
Descarta un par de cable defectuoso que falle durante la renegociación
Un cable puede funcionar a 2.5GbE hasta que el enlace se renegocia y luego establecerse en un modo inferior si un par, una terminación, un acoplador o un conector presenta un defecto. Vuelve a insertar ambos extremos y compara el resultado con un cable corto conocido en buen estado conectado a los mismos puertos.
Un artículo reciente sobre diagnóstico de Ethernet explica que 100Mbps puede indicar un fallo en un par aunque la categoría visible del cable parezca adecuada.
Si el cable corto mantiene 2.5GbE durante varios ciclos de suspensión y reinicio, prueba por separado los latiguillos originales, las tomas de pared, los acopladores y el tendido interno. Repara la ruta física en lugar de dejar la NIC forzada a un modo superior.
Comprueba por separado los adaptadores 2.5GbE USB o conectados mediante una base
Si el servidor o cliente utiliza un adaptador 2.5GbE USB-C o conectado mediante una base, incluye el controlador USB y el estado de energía de la base en la prueba. La reanudación puede restablecer el dispositivo USB antes de que comience la autonegociación de Ethernet.
Una prueba detallada de un adaptador 2.5GbE constató que los adaptadores USB dependen de los controladores y de la enumeración en el equipo anfitrión, que también forman parte de la ruta, no solo del cable RJ45.
Prueba el mismo adaptador directamente en el equipo anfitrión sin la base y después a través de ella. Si solo la ruta mediante la base baja de velocidad después de reanudar, centra la solución en la alimentación USB y el firmware de la base, no en el switch del NAS.
Verifica que 2.5GbE sobreviva a varios ciclos de suspensión y reinicio
Después de cambiar la causa confirmada, ejecuta al menos dos ciclos de suspensión y reanudación, un reinicio en caliente y una transferencia LAN sostenida mientras observas la velocidad negociada, los errores del enlace y los eventos de renegociación en ambos extremos.
Un artículo sobre rendimiento de redes multisigabit recuerda que la velocidad del enlace no equivale al rendimiento, por lo que la prueba final debe validar tanto una negociación estable como un tráfico útil.
La reparación está completa cuando el mismo enlace 2.5GbE supera las transiciones de energía sin bajar a 100Mbps. El artículo relacionado de ZimaSpace sobre un puerto NAS que negocia a 1GbE sigue siendo la ruta correcta cuando el problema ya no es específico de la suspensión o el reinicio.
Soporte y Consejos
Más para leer

¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...

Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...

Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...

