Diagnostica la pérdida de paquetes en Linux: enlace, colas y límites

Una cifra de pérdida en un salto de MTR no basta para señalar un enlace averiado. El router puede estar limitando las respuestas ICMP que recibe mientras sigue reenviando el tráfico. Para separar ese caso de errores físicos, colas saturadas o un límite de tasa, hay que comprobar si la pérdida llega al destino y contrastarla con los contadores del host.

El recorrido de este tutorial es concreto: medir con distintos tamaños de paquete, leer el patrón de MTR, tomar contadores antes y después de la prueba y, si hace falta, aumentar gradualmente la tasa de un flujo UDP. Usaremos direcciones reservadas para documentación: 198.51.100.10 como destino remoto y eth0 como interfaz local. Sustitúyelas por valores de tu entorno.

flowchart TD
    A["Medir con ping y MTR"] --> B["Comprobar el destino"]
    B --> C["Revisar contadores locales"]
    C --> D["Clasificar errores o colas"]
    D --> E["Probar una tasa UDP"]
    E --> F["Aislar el tramo y registrar"]

Preparar una medición que se pueda repetir

En Linux, instala MTR con el gestor de paquetes de tu distribución. Alibaba Cloud documenta apt para Ubuntu y Debian y yum para CentOS y Alibaba Cloud Linux. El ejemplo usa Debian o Ubuntu; las pruebas siguientes también requieren iproute2, que proporciona el comando ip, y ethtool para consultar estadísticas del dispositivo.

# Debian o Ubuntu: instala MTR y ethtool
sudo apt install mtr ethtool

Antes de ejecutar las pruebas, anota la hora, la interfaz y el destino. Una muestra corta puede confundir una fluctuación puntual con una tendencia; la prueba de abajo envía 200 sondas con un intervalo de 0,2 segundos. Repite con paquetes grandes y compara las familias IPv4 e IPv6 si el problema también aparece en IPv6.

# Mide pérdida y latencia con paquetes pequeños y grandes
ping -c 200 -i 0.2 198.51.100.10
ping -c 200 -i 0.2 -s 1400 198.51.100.10

# Guarda un informe de MTR con 200 sondas
mtr -rwzc 200 198.51.100.10

Si solo fallan los paquetes grandes, investiga MTU o fragmentación antes de atribuirlo a congestión. Si la pérdida aparece a ciertas horas, el patrón es compatible con congestión; si es constante, busca también un fallo persistente. Son indicios, no una localización definitiva.

Leer MTR sin culpar al primer salto que falla

MTR combina sondeos continuos con el trazado de saltos. La regla útil es mirar qué pasa después del salto que muestra pérdida: si el destino no pierde, esa cifra intermedia puede reflejar limitación de ICMP, no pérdida del tráfico reenviado. Si el mismo patrón continúa hasta el destino, hay más motivos para investigar el camino de datos.

Un salto que no responde —representado a veces como ???— tampoco demuestra por sí solo que haya pérdida. Puede no haber información de ruta para ese nodo, o el router puede no contestar a las sondas. Cuando MTR muestra pérdida en varios saltos, compara los porcentajes hasta el final y no te quedes con el primer valor distinto de cero. Alibaba Cloud describe, por ejemplo, una muestra en la que un salto marca un 41,2 % y el siguiente un 0 %: esa discontinuidad apunta a limitación de respuestas, no a una pérdida que se propague por la ruta.

Si puedes, repite la prueba con TCP además de ICMP. La documentación de Edge Diagnostics de Akamai advierte que las sondas ICMP pueden estar sujetas a límites de proveedores o cortafuegos; también señala que TCP puede ser menos fiable en algunas de sus pruebas. Si un tipo falla, contrástalo con el otro en vez de tomar un único resultado como veredicto.

Tomar los contadores antes y después

Una ruta con síntomas no exculpa al propio host. Guarda una lectura de la interfaz y de las estadísticas del kernel, ejecuta la prueba y vuelve a leerlas. Lo que interesa es el incremento durante el intervalo, no solo el valor acumulado desde que arrancó el sistema.

# Revisa las estadísticas detalladas de la interfaz y del kernel
ip -s -s link show dev eth0
ethtool -S eth0 | grep -Ei 'err|drop|miss|fifo|crc'
nstat -az | grep -Ei 'drop|retrans|overflow'

Linux expone estadísticas estándar de interfaz mediante ip; con -s repetido se muestran también campos detallados. ethtool -S ofrece estadísticas del dispositivo y del controlador. Los nombres concretos varían según el dispositivo, así que busca familias de contadores y compara sus valores, sin asumir que todos los controladores publican el mismo conjunto.

Un aumento de CRC, errores de trama o alineación dirige la investigación hacia la capa física: cable, conector, óptica o negociación dúplex. Contadores RX de paquetes perdidos o FIFO pueden indicar que la NIC o el controlador no dan abasto. Los descartes TX o de qdisc apuntan a la cola de salida. En cambio, un conjunto limpio en el host desplaza la sospecha al camino entre extremos, aunque no identifica por sí solo el tramo exacto.

Separar errores físicos, congestión y límite de tasa

Consulta la disciplina de cola y su actividad durante el mismo periodo. Si los descartes aumentan con la carga en una interfaz de salida, comprueba también su utilización: es una firma distinta de los errores CRC, que se reflejan en contadores de errores del enlace.

# Consulta estadísticas de la cola de salida de eth0
tc -s qdisc show dev eth0

Un patrón de cola que descarta paquetes mientras sube el tráfico encaja con congestión o con ráfagas que superan el espacio disponible en el búfer. Los errores físicos, en cambio, crecen en los contadores de interfaz y pueden aparecer con independencia de la carga. Antes de sustituir hardware, registra los valores y repite la prueba: el cambio entre las dos lecturas es la evidencia más útil.

Un policer o un limitador de tasa suele mostrar otra forma: el rendimiento se estabiliza cerca de un techo y aparecen pérdidas aunque el enlace no parezca lleno. Para buscar ese umbral, envía UDP a una tasa fija y súbela en pruebas sucesivas. El ejemplo siguiente requiere un servidor iperf3 accesible en el destino; empieza en 50 Mbit/s y dura 30 segundos.

# Envía UDP a 50 Mbit/s durante 30 segundos
iperf3 -c 198.51.100.10 -u -b 50M -t 30

Repite con tasas mayores, cambiando el valor de -b en cada ejecución. Una pérdida que comienza bruscamente en torno a una tasa concreta es compatible con un límite o un cuello de botella a esa velocidad. No distingue por sí sola entre ambos: contrasta el resultado con la utilización y los contadores de cola, y pide al proveedor que revise el enlace concreto si los datos apuntan fuera del host.

Aislar el tramo y dejar evidencia

Si el host está limpio y la pérdida llega al destino, compara puntos intermedios que controles. También puedes capturar tráfico en ambos extremos y cotejar paquetes y marcas de tiempo; una prueba en sentido inverso ayuda cuando la latencia o la pérdida de ida no explican lo que observa la aplicación. MTR muestra el trayecto desde el origen de la prueba: no convierte automáticamente el salto con más pérdida en el responsable.

Al escalar el caso a un operador, proporciona la ventana horaria, las direcciones, el tamaño de paquete, la tasa de prueba, el resultado de MTR y los contadores antes y después. Registra también desde qué extremo se hizo la prueba. Ese conjunto permite repetirla tras un cambio y acota la conversación a un tramo y un síntoma concretos.

La secuencia práctica es medir, comprobar el destino, revisar el host y clasificar el patrón antes de cambiar configuración. Si un salto intermedio pierde sondas pero el destino no, no des por perdida la ruta; si una cola o un contador físico crece durante la prueba, ya tienes una pista local que se puede verificar.

Fuentes: DEV Community, Linux Kernel Documentation, Alibaba Cloud Documentation, Edge Diagnostics