Desajuste de dúplex en un puerto de puerta de enlace VPN: lea ambos extremos

Una copia de archivo por el túnel se detiene un segundo, se reanuda y los registros de la VPN no muestran nada. La aplicación culpa a la red, la red culpa a la aplicación, y el puerto del conmutador lleva once meses activo. Este recorrido empieza en la pausa y avanza hacia el enlace físico: qué hace realmente el puerto, qué hace el extremo remoto y qué hicieron los contadores mientras usted miraba. Merece la pena hacerlo antes de que alguien toque un ajuste de dúplex.

Empiece por la pausa, no por el puerto

Describa el síntoma de forma que se pueda probar. Una parada de alrededor de un segundo durante una transferencia masiva es un problema distinto de una conexión que se reinicia, y una pausa que ocurre una vez por hora es distinta de una que ocurre cada pocos segundos. Anote la carga, la dirección y el intervalo aproximado.

Después reprodúzcalo mientras observa la interfaz. Un problema físico se manifiesta como movimiento en los contadores durante la carga afectada, y un problema que no mueve ningún contador probablemente está por encima de la capa de enlace. Observe un minuto, no un segundo, porque estas averías suelen necesitar tráfico sostenido antes de aparecer. La monitorización en reposo no demuestra nada sobre un enlace que solo se comporta mal bajo carga.

Esto importa porque los desajustes de dúplex tienen una firma: errores que solo aparecen bajo carga, en la dirección del tráfico, mientras los pings pequeños y las sesiones interactivas siguen perfectos. Si el tráfico en reposo también falla, busque primero en otro sitio.

Lea el modo operativo en ambos extremos

La configuración guardada no es el estado operativo. Un puerto puede estar configurado para autonegociación y acabar en medio dúplex, o estar configurado a una velocidad fija con la que el otro extremo nunca estuvo de acuerdo. Lea qué está haciendo el enlace ahora mismo en ambos lados.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Anote la velocidad, el dúplex y si la autonegociación está activada, y luego obtenga los mismos tres datos del conmutador adyacente o del puerto del proveedor. Un solo extremo no dice nada, porque el desajuste es una relación y no un ajuste. Ponga ambas filas en el ticket, una junto a la otra, con la hora a la que las leyó. La mitad del valor del ejercicio es tener las dos lecturas en un mismo sitio.

Si no puede leer el extremo remoto, no puede diagnosticar esto. Pida al propietario el modo operativo y los contadores, o consiga acceso antes de empezar a cambiar su lado.

Cómo se ve el caso 10/100 en medio dúplex

En enlaces de cobre 10/100, un extremo que autonegocia puede detectar la velocidad de un par forzado sin aprender su ajuste de dúplex. La detección paralela determina la velocidad a partir de la señal, y el dúplex se supone en lugar de negociarse, así que un lado puede acabar en medio dúplex mientras el otro funciona a dúplex completo.

La guía de autonegociación de Cisco explica ese caso concreto. No es un argumento para desactivar la negociación en todas partes, y no dice nada útil sobre el cobre gigabit, donde el dúplex es fijo y la autonegociación es necesaria para que el enlace se levante.

La evidencia observable es una mezcla de errores que solo existen en una dirección: errores FCS o CRC en el lado de dúplex completo, colisiones o colisiones tardías en el lado de medio dúplex, y un rendimiento que se desploma bajo carga mientras la latencia se mantiene normal en reposo. Esa asimetría es la firma. Un enlace simplemente sobresuscrito se degrada en ambas direcciones y en todo momento.

Cambie ambos extremos a la vez, con un camino de vuelta

Una corrección de dúplex es un cambio coordinado, no local. Forzar su lado sin el acuerdo del extremo remoto es como un enlace que funciona se convierte en uno roto, y que la CLI acepte el comando solo demuestra que la sintaxis era válida.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Antes de ejecutar algo así, confirme que la plataforma admite la combinación y que el extremo remoto se cambiará en la misma ventana. Conserve una vía independiente para administrar el dispositivo, porque el puerto que está a punto de cambiar puede ser el que transporta su sesión de gestión.

En muchos enlaces modernos la respuesta correcta es dejar la autonegociación activada en ambos extremos en lugar de forzar nada. Forzar es un remedio para un desajuste concreto en una tecnología concreta, no una mejora general. El cobre gigabit, en particular, necesita la autonegociación para que el enlace se levante, así que el consejo para 10/100 no se traslada.

Confirme que los contadores se movieron a mejor

Después del cambio, vuelva a leer el estado operativo en ambos extremos y confirme que coinciden. Luego ejecute la misma carga que produjo la pausa y compare las diferencias de los contadores en lugar de los totales acumulados, porque un total que se acumula desde hace un año no puede decirle qué pasó en los últimos diez minutos.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Un enlace sin errores nuevos bajo la misma carga es la evidencia que le faltaba. Un enlace que sigue fallando, o uno en el que los contadores nunca se movieron, le envía a la siguiente frontera en lugar de más adentro de la discusión del dúplex. Cualquiera de los dos resultados es progreso, que es más de lo que el archivo de configuración puede darle. No se salte la segunda lectura porque la primera pareciera correcta.

Escriba los números de antes y después en el ticket con marcas de tiempo. Ese registro es lo que convierte «la VPN va mejor» en algo sobre lo que el siguiente ingeniero puede construir.