Tiempos de espera aleatorios en Debian/Ubuntu: rastrea la ruta de red con mtr/tcpdump y soluciona la causa (Caso #64)

Los tiempos de espera aleatorios son el peor tipo de incidencia: nada está “caído”, todo está “bastante bien”, y sin embargo los usuarios miran ruedas giratorias. Tus paneles parecen satisfechos. Tus registros parecen aburridos. Y el director ejecutivo siempre puede reproducirlo con el Wi‑Fi del hotel.

Esta es una guía de campo para operadores Debian/Ubuntu que necesitan probar dónde ocurre el tiempo de espera, asignarlo a un salto o a un subsistema, y corregir la causa real. Usaremos mtr y tcpdump como adultos: no como ritual, sino como instrumentos. En el camino separaremos “pérdida de paquetes” de “ICMP despriorizado”, atraparemos los agujeros PMTU, detectaremos mentiras de DNS e identificaremos el dolor especial que es el enrutamiento asimétrico.

Guion de diagnóstico rápido

Si estás de guardia, no necesitas una lección de filosofía. Necesitas una secuencia que encuentre el cuello de botella rápido y evite falsos positivos.

Primero: determina qué falla (DNS, conexión TCP, TLS o aplicación)

• Comprueba latencia y fallos de DNS (es el clásico “culpable aleatorio” porque el caché lo hace esporádico).
• Comprueba el tiempo de conexión TCP (handshake SYN/SYN-ACK). Si la conexión es lenta, enfócate en la ruta/firewalls/conntrack.
• Comprueba el handshake TLS (si TLS se queda colgado después de la conexión, sospecha PMTU, middleboxes o rarezas de offload de MTU).
• Comprueba el tiempo de petición/respuesta (si conexión y TLS están bien, es carga de aplicación o del servidor).

Segundo: decide si es “trayecto” o “endpoint”

• Ejecuta mtr desde el cliente hacia la IP del servidor, y desde el servidor de vuelta a la red del cliente si puedes.
• Ejecuta tcpdump en el endpoint que controlas para verificar si los paquetes llegan y si salen las respuestas.

Tercero: clasifica el tipo de tiempo de espera

• Retransmisiones sin ACK → pérdida, filtrado, enrutamiento asimétrico o descartes por conntrack.
• Desaparecen paquetes grandes → agujero PMTU (DF establecido, ICMP bloqueado).
• Solo falla UDP “aleatoriamente” → timeouts de NAT, firewalls stateful o rarezas de DNS/QUIC.
• Solo un ASN/proveedor de destino → problema de enrutamiento/peering upstream; obtén evidencia y escala.

Una regla operativa: no confíes en una sola perspectiva. Si mides solo desde el servidor, te perderás problemas de último tramo. Si mides solo desde el cliente, culparás a Internet por tu propia tabla conntrack llena.

Un modelo mental práctico: qué suelen ser los “tiempos de espera”

Los tiempos de espera raramente son aleatorios. Son condicionales. Algo sobre el patrón de tráfico, el tamaño de paquete, la elección del resolvedor, la ruta o la tabla de estado desencadena una falla. La “aleatoriedad” es tu observabilidad que no captura la condición.

En producción, los tiempos de espera intermitentes suelen caer en uno de estos grupos:

• Problemas de DNS: resolvedores lentos, split-horizon roto, problemas EDNS0/fragmentación UDP o limitación por tasa en el resolvedor.
• Pérdida de paquetes en un salto: pérdida real (congestión, Wi‑Fi, mala fibra) vs “ICMP despriorizado” (mtr muestra pérdida pero TCP va bien).
• Agujeros PMTU: Path MTU Discovery falla porque ICMP “fragmentation needed” está bloqueado; paquetes pequeños funcionan, los grandes se atascan.
• Agotamiento de estado: tabla conntrack llena, tabla NAT llena, CPU del firewall al máximo, mitigaciones DDoS descartando estado.
• Enrutamiento asimétrico: SYN sale por una ruta, SYN-ACK vuelve por otra y es descartado por un firewall stateful o validación de origen.
• Offload y fallos de driver: interacciones con GRO/TSO/LRO, checksum offload extraña o firmware de NIC defectuoso—poco comunes, pero memorables.
• Encolamiento y bufferbloat: picos de latencia bajo carga provocan “tiempos de espera” sin pérdida alta.

La verdad poco glamorosa: mtr te dice dónde mirar; tcpdump te dice qué pasó. Usa ambos.

Datos interesantes y contexto histórico

• La idea central de traceroute data de 1987, usando TTL creciente para provocar respuestas ICMP “time exceeded” de cada salto.
• mtr (My Traceroute) existe desde finales de los 90, combinando traceroute y ping en el tiempo para exponer fallos intermitentes.
• ICMP no es “opcional” en la práctica: bloquea demasiado y rompes PMTU discovery, causando fallos clásicos de “funciona con cargas pequeñas”.
• Path MTU Discovery (PMTUD) se volvió importante en los 90 conforme las redes se diversificaron; sigue siendo una causa principal de bloqueos extraños hoy.
• El comportamiento de retransmisión TCP es intencionalmente conservador; el backoff exponencial hace que un pequeño evento de pérdida parezca una gran parada al usuario.
• conntrack en Linux existe porque firewalls stateful y NAT lo necesitan; cuando está lleno, tu red no “degrada”, miente y descarta nuevas conexiones.
• EDNS0 aumentó tamaños de mensajes DNS; genial hasta que firewalls y NATs manejan mal UDP fragmentado y DNS empieza a “fallar aleatoriamente”.
• CDNs y servicios multihomed modernos hacen el enrutamiento más dinámico; tu “mismo destino” puede tomar rutas diferentes minuto a minuto.
• El rate limiting de ICMP es común en routers; puede hacer que mtr muestre pérdida en un salto intermedio aunque el reenvío sea perfecto.

Herramientas que realmente necesitas en Debian/Ubuntu

Instala lo básico. No seas la persona que depura redes solo con curl y buenas intenciones.

cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done

cr0x@server:~$ sudo apt-get install -y mtr-tiny tcpdump iproute2 dnsutils iputils-ping traceroute ethtool conntrack netcat-openbsd
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  conntrack dnsutils ethtool mtr-tiny netcat-openbsd tcpdump traceroute
0 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.

mtr-tiny es suficiente para la mayoría de los casos. Si quieres la versión completa con más funciones, instala mtr cuando tu distribución lo provea. tcpdump es innegociable.

Tareas prácticas: comandos, salidas y decisiones

A continuación hay tareas prácticas que puedes ejecutar en Debian/Ubuntu. Cada una incluye: comando, qué buscar y la decisión que debe provocar.

Task 1: Confirmar que el tiempo de espera es real y medir dónde ocurre (DNS vs connect vs TLS)

cr0x@server:~$ time curl -sS -o /dev/null -w "namelookup:%{time_namelookup} connect:%{time_connect} appconnect:%{time_appconnect} starttransfer:%{time_starttransfer} total:%{time_total}\n" https://api.example.net/health
namelookup:0.002 connect:0.012 appconnect:0.054 starttransfer:0.061 total:0.061

real	0m0.070s
user	0m0.010s
sys	0m0.004s

Interpretación: Si namelookup se dispara en fallos, persigue DNS. Si connect se dispara, persigue ruta/firewall/conntrack. Si appconnect se dispara, persigue TLS/MTU/middleboxes. Si solo starttransfer se dispara, probablemente es latencia de servidor/aplicación.

Decisión: Elige el subsistema a instrumentar a continuación. No ejecutes mtr a un nombre de host si el DNS está fallando; resuelve a una IP primero.

Task 2: Resolver el hostname y fijar una IP

cr0x@server:~$ dig +time=1 +tries=1 api.example.net A
; <<>> DiG 9.18.24-1ubuntu1.4-Ubuntu <<>> +time=1 +tries=1 api.example.net A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1203
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.net.	60	IN	A	203.0.113.42

;; Query time: 18 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Dec 30 12:01:02 UTC 2025
;; MSG SIZE  rcvd: 58

Interpretación: Observa el resolvedor (127.0.0.53 sugiere systemd-resolved) y el tiempo de consulta. Si el tiempo de consulta son cientos de ms o falla intermitentemente, DNS es culpable hasta que se demuestre lo contrario.

Decisión: Usa la IP (203.0.113.42) para pruebas de ruta y capturas de paquetes para evitar ruido de DNS.

Task 3: Ejecutar mtr en modo TCP al puerto del servicio (no ICMP)

cr0x@server:~$ mtr -rwz -c 200 -T -P 443 203.0.113.42
Start: 2025-12-30T12:02:10+0000
HOST: server                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.0.1                     0.0%   200    0.4   0.6   0.3   2.1   0.2
  2.|-- 192.0.2.10                    0.0%   200    1.2   1.5   1.0   5.4   0.6
  3.|-- 198.51.100.9                  0.0%   200    2.8   3.0   2.2   9.7   0.8
  4.|-- 203.0.113.1                   0.0%   200    9.9  10.3   8.7  22.1   2.1
  5.|-- 203.0.113.42                  6.0%   200   18.2  14.1  11.0  85.3  10.7

Interpretación: mtr en modo TCP está más cerca de tu tráfico real. La pérdida en el salto final con intermedios limpios es significativa. La desviación estándar y los picos peores importan: 85 ms peor no es fatal, pero 6% de pérdida sí lo es.

Decisión: Si la pérdida aparece solo en el último salto, sospecha del host destino, su firewall o un dispositivo adyacente. Si la pérdida comienza en un salto y continúa hacia adelante, sospecha ese salto o enlace.

Task 4: Ejecutar mtr con ICMP para detectar limitación de ICMP vs pérdida real en el reenvío

cr0x@server:~$ mtr -rwz -c 200 203.0.113.42
Start: 2025-12-30T12:03:44+0000
HOST: server                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.0.1                     0.0%   200    0.5   0.6   0.3   1.6   0.2
  2.|-- 192.0.2.10                    0.0%   200    1.3   1.4   1.0   4.1   0.4
  3.|-- 198.51.100.9                 22.0%   200    3.0   3.2   2.4  11.8   1.1
  4.|-- 203.0.113.1                   0.0%   200   10.2  10.5   8.8  21.9   2.0
  5.|-- 203.0.113.42                  0.0%   200   12.9  13.6  11.2  40.5   4.4

Interpretación: El salto 3 muestra 22% de pérdida, pero los saltos posteriores muestran 0% de pérdida. Eso es clásica despriorización o limitación de respuestas ICMP en el salto 3, no pérdida real en el reenvío.

Decisión: No escales al proveedor basándote solo en esto. Prefiere mtr en TCP al puerto real y corrobora con tcpdump.

Task 5: Comprobar errores y descartes en la interfaz local (aburrido, a menudo decisivo)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
     987654321  123456      0    421       0   10234
    TX:  bytes packets errors dropped carrier collsns
     876543210  120001      0     19       0       0

Interpretación: RX dropped 421 indica descartes locales (desbordamiento de colas, driver o presión de CPU del host). No siempre es fatal, pero no es “Internet”.

Decisión: Si los descartes suben durante incidentes, investiga carga del host, buffers de NIC, qdisc y offloads. Si ves errores/carrier, sospecha cableado o problemas en la NIC virtual.

Task 6: Comprobar enrutamiento y selección de IP de origen

cr0x@server:~$ ip route get 203.0.113.42
203.0.113.42 via 10.10.0.1 dev eth0 src 10.10.0.23 uid 1000
    cache

Interpretación: Confirma qué gateway y qué IP de origen se usan. Una IP de origen equivocada es un asesino silencioso cuando existe policy routing o múltiples interfaces.

Decisión: Si la IP de origen es incorrecta, corrige reglas de enrutamiento, ip rule o el binding de la aplicación. Si el gateway es inesperado, podrías tener enrutamiento asimétrico.

Task 7: Buscar agotamiento de conntrack (tiempos de espera que huelen a “nuevas conexiones fallan”)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 262132
net.netfilter.nf_conntrack_max = 262144

Interpretación: Estás prácticamente al 100%. Las nuevas conexiones pueden ser descartadas o demoradas, produciendo timeouts de conexión intermitentes que mágicamente “desaparecen”.

Decisión: Incrementa nf_conntrack_max (con cuidado: impacto en memoria), reduce churn de conexiones, acorta timeouts donde sea seguro, o mueve NAT/estado a otro dispositivo.

Task 8: Capturar tráfico durante un tiempo de espera (retransmisiones SYN vs silencio del servidor)

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.42 and tcp port 443 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:01.120001 IP (tos 0x0, ttl 64, id 43121, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.0.23.53124 > 203.0.113.42.443: Flags [S], seq 3021001001, win 64240, options [mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 7], length 0
12:06:02.121045 IP (tos 0x0, ttl 64, id 43122, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.0.23.53124 > 203.0.113.42.443: Flags [S], seq 3021001001, win 64240, options [mss 1460,sackOK,TS val 2000 ecr 0,nop,wscale 7], length 0
12:06:04.123210 IP (tos 0x0, ttl 64, id 43123, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.0.23.53124 > 203.0.113.42.443: Flags [S], seq 3021001001, win 64240, options [mss 1460,sackOK,TS val 4000 ecr 0,nop,wscale 7], length 0

Interpretación: Retransmisiones SYN sin ningún SYN-ACK de vuelta. O el SYN nunca llega al servidor, o el SYN-ACK no regresa, o se descarta localmente por conntrack/firewall.

Decisión: Captura también en el lado del servidor si es posible. Si el servidor ve SYN pero el cliente no ve SYN-ACK, sospecha ruta de retorno/asimetría o un dispositivo stateful que descarta la respuesta.

Task 9: Capturar en el servidor para probar si llega el SYN

cr0x@server:~$ sudo tcpdump -ni eth0 src 10.10.0.23 and tcp port 443 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:06:01.129900 IP 10.10.0.23.53124 > 203.0.113.42.443: Flags [S], seq 3021001001, win 64240, options [mss 1460,sackOK,TS val 1000 ecr 0,nop,wscale 7], length 0
12:06:01.130010 IP 203.0.113.42.443 > 10.10.0.23.53124: Flags [S.], seq 901200200, ack 3021001002, win 65160, options [mss 1440,sackOK,TS val 7000 ecr 1000,nop,wscale 7], length 0

Interpretación: El servidor envía SYN-ACK. Si la captura del cliente no lo mostró, la ruta de retorno lo está descartando. Eso no es aplicación. Es red.

Decisión: Escala al equipo de red/proveedor con esta evidencia, o revisa firewalls/NAT intermedios por enrutamiento asimétrico o descartes de estado.

Task 10: Detectar agujero PMTU con tracepath

cr0x@server:~$ tracepath -n 203.0.113.42
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.10.0.1                          0.471ms
 2:  192.0.2.10                         1.312ms
 3:  198.51.100.9                       3.004ms
 4:  203.0.113.1                       10.142ms
 5:  203.0.113.42                      13.012ms reached
     Resume: pmtu 1500 hops 5 back 64

Interpretación: Si tracepath informa una PMTU menor (como 1472/1460/1400) o se queda en “sin respuesta”, puedes tener problemas PMTU.

Decisión: Si sospechas de un agujero PMTU, prueba con pings con DF y ajusta MTU/MSS clamping.

Task 11: Validar PMTU con pings “no fragmentar” de distintos tamaños

cr0x@server:~$ ping -c 3 -M do -s 1472 203.0.113.42
PING 203.0.113.42 (203.0.113.42) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 203.0.113.42 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2046ms

Interpretación: Esta salida indica que tu MTU de interfaz local es 1500, y probaste una carga que la excedería tras encabezados. Eso es un problema de tamaño local, no del camino.

Decisión: Reintenta con tamaños correctos. Para MTU 1500, payload ICMP 1472 suele ser válido; si ves “message too long”, puede que estés en una interfaz de túnel o con MTU diferente al que crees. Confirma MTU con ip link.

Task 12: Comprobar MTU local y túneles que la reducen silenciosamente

cr0x@server:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
3: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

Interpretación: La interfaz WireGuard con MTU 1420 es común. Si el tráfico pasa por wg0 o está encapsulado, la MTU efectiva es menor que 1500.

Decisión: Si tu ruta usa un túnel, ajusta la MTU adecuadamente y aplica MSS clamping en el borde.

Task 13: Buscar descartes en logs de firewall y contadores nftables

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    counter packets 1024 bytes 65536 drop
  }
}

Interpretación: Ese contador en una regla de drop no es decoración. Si aumenta durante los tiempos de espera, tu firewall local está participando.

Decisión: Añade reglas accept explícitas para el servicio, o arregla el seguimiento de estado/enrutamiento para que las respuestas coincidan con el estado establecido.

Task 14: Verificar comportamiento de systemd-resolved y salud de resolvers upstream

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53 192.0.2.54

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.0.2.53
       DNS Servers: 192.0.2.53 192.0.2.54

Interpretación: Sabes qué resolvers estás realmente usando. “Usamos Google DNS” suele ser un mito que sobrevive a un módulo terraform anterior.

Decisión: Prueba cada resolver directamente con dig @server. Si uno es inestable, elimínalo o arréglalo.

mtr bien usado: léelo como un SRE

mtr es un traceroute en series temporales. También es generador de tickets malos cuando se interpreta mal. La trampa principal: la pérdida mostrada en un salto intermedio no significa necesariamente pérdida para tu tráfico. Muchos routers despriorizan respuestas ICMP TTL-expired; aún así reenvían paquetes sin problema.

Reglas prácticas que te mantienen fuera de problemas

• Confía en la pérdida solo si persiste hasta el salto final. La pérdida que aparece en el salto N y desaparece en N+1 suele ser limitación de respuesta ICMP.
• Prefiere mtr en TCP al puerto del servicio. ICMP puede tratarse diferente que tu tráfico, especialmente entre proveedores y firewalls.
• Mira la distribución de latencia (avg, worst, stdev), no solo “Loss%”. El encolamiento puede arruinar la experiencia sin pérdida alta.
• Ejecuta suficientes muestras (-c 200 o más) para capturar intermitencia. Cinco paquetes es un horóscopo.
• Ancla las pruebas a la IP real. Los CDNs pueden dirigir a clientes distintos a bordes distintos; quieres un objetivo estable.

Chiste #1: mtr es como una llamada de conferencia: alguien siempre “se cae”, y suele ser la persona que no hace ningún trabajo real.

Cómo luce una buena evidencia de mtr

La buena evidencia es comparativa y consistente:

• mtr TCP a puerto 443 muestra 5–10% de pérdida en el salto final durante el incidente.
• tcpdump muestra retransmisiones SYN y SYN-ACKs faltantes en el lado del cliente.
• La captura en el servidor muestra SYN-ACK saliendo (o no saliendo) de la interfaz.
• Pruebas de ruta desde otro punto de vista muestran comportamiento distinto (problema de enrutamiento) o el mismo comportamiento (problema en el endpoint).

tcpdump bien usado: captura el tiempo de espera en la red

tcpdump es tu acta de tribunal. La traza de paquetes no se preocupa por tus suposiciones, tu organigrama o el hecho de que “funcionó ayer”. Solo registra lo enviado y lo observado.

Estrategia de captura: no te ahogues

• Filtra agresivamente: host + puerto + protocolo. Si capturas todo, perderás el momento que importa.
• Captura en ambas direcciones cuando sea posible: cliente y servidor. Al enrutamiento asimétrico le encanta la captura unilateral.
• Correlaciona con marcas temporales: registra los tiempos del incidente y usa relojes monotónicos si puedes. Si NTP está roto, sufrirás doble.

Qué buscar en timeouts TCP

• Retransmisiones SYN: problema de camino de conexión, filtrado, ruta de retorno o conntrack.
• SYN/SYN-ACK/ACK tiene éxito pero TLS se queda: PMTU, interferencia de middlebox o reordenamiento con MTU extraña.
• Datos enviados, sin ACKs, retransmisiones: pérdida aguas abajo o dispositivo stateful descartando.
• RSTs: rechazo activo por firewall o servicio no escuchando.

Una verdad operativa más: los timeouts no son errores, son falta de evidencia. tcpdump te da esa evidencia.

Soluciona la causa: MTU, enrutamiento, DNS, conntrack y compañía

Clase de solución 1: timeouts “aleatorios” de DNS

El DNS a menudo parece la red porque todo lo usa. Modos de fallo típicos:

• Un resolvedor está lento o descarta UDP intermitentemente.
• Respuestas EDNS0 se fragmentan; fragmentos se descartan; clientes reintentan por TCP y se quedan en cola.
• Split-horizon devuelve IPs no enrutable según qué resolvedor responda.

Qué hacer:

• Prueba cada resolvedor directamente usando dig @192.0.2.53 y dig @192.0.2.54 con timeouts cortos.
• Si ves respuestas grandes que fallan, prueba con +tcp y considera limitar el tamaño de buffer EDNS en resolvedores o clientes.
• En sistemas con systemd-resolved, confirma qué servidores están activos; no des nada por sentado.

Clase de solución 2: agujeros PMTU

Los agujeros PMTU son clásicos: peticiones pequeñas funcionan, peticiones grandes fallan, usualmente durante TLS o con cabeceras/cookies grandes. El culpable suele ser ICMP “fragmentation needed” bloqueado. TCP sigue enviando con DF puesto, nunca aprende la MTU menor y obtienes retransmisiones hasta timeout.

Qué hacer:

• Permite los tipos ICMP necesarios a través de firewalls (al menos “fragmentation needed” y “time exceeded” según corresponda).
• Clampa MSS en bordes de túnel (WireGuard, IPsec, GRE) para que los endpoints nunca envíen segmentos demasiado grandes.
• Configura la MTU correcta en interfaces de túnel y verifica que el enrutamiento realmente las use.

Clase de solución 3: agotamiento de conntrack/NAT

El agotamiento de conntrack hace que nuevas conexiones sean inestables mientras las existentes siguen funcionando. Es el equivalente en red de un restaurante que mantiene a los clientes viejos sentados para siempre y finge estar “completo”.

Qué hacer:

• Aumenta nf_conntrack_max y ajusta timeouts si tu carga hace muchas conexiones.
• Reduce churn: habilita keep-alives, reutiliza conexiones, configura pools.
• Mueve NAT/estado a dispositivos dimensionados para ello, o elimina NAT cuando sea posible.

Clase de solución 4: enrutamiento asimétrico

El enrutamiento asimétrico no es intrínsecamente malo; Internet lo hace todo el tiempo. Se vuelve problemático cuando dispositivos stateful asumen simetría (firewalls, NATs) o cuando la validación de ruta de retorno descarta paquetes que regresan por una interfaz inesperada.

Qué hacer:

• Valida el enrutamiento con ip route get y con capturas en ambos extremos.
• Si tienes múltiples uplinks, alinea el policy routing y asegúrate de que las respuestas salgan por la misma ruta que las solicitudes cuando pasen por dispositivos stateful.
• Revisa la configuración de reverse path filtering (rp_filter) cuando hosts multi-homed vean tráfico de retorno por otra interfaz.

Clase de solución 5: descartes locales, NIC/driver o encolamiento

A veces el problema de red es tu host descartando paquetes bajo carga. Observa descartes de interfaz, presión de softirq en CPU y comportamiento de qdisc.

• Si ip -s link muestra descartes durante incidentes, inspecciona la carga de CPU y softirqs.
• Revisa offloads con ethtool -k si sospechas rarezas; desactívalos selectivamente para diagnóstico, no permanentemente por superstición.
• Considera fq_codel o cake en el borde si el bufferbloat está causando picos de latencia.

Chiste #2: Si “arreglaste” timeouts reiniciando el firewall, no lo arreglaste: le pusiste la siesta al problema con autoridad.

Tres mini-historias empresariales (anonimizadas)

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa ejecutaba una API multirregión. Usuarios de una geografía informaron fallos intermitentes en el checkout: algunas peticiones tenían éxito, otras se quedaban en timeout a 10–15 segundos. El equipo de aplicación juró que era un problema de backend porque sus paneles mostraban latencia elevada en la capa API. Empezaron a escalar.

La primera suposición equivocada fue sutil: asumieron que “timeouts” significaba “servidor lento”. En realidad, curl -w mostró que se disparaba time_connect, no starttransfer. Ese único dato cambió toda la investigación de aplicación a red.

mtr desde una red cliente con fallos mostró pérdida en el último salto solo cuando se usaba TCP al puerto 443. El mtr por ICMP estaba limpio. Ese fue un detalle importante: la red podía reenviar ICMP e incluso algo de TCP, pero no consistentemente a ese puerto de servicio. El equipo finalmente ejecutó tcpdump en el servidor y vio SYNs llegar, SYN-ACKs salir y… nada. El cliente nunca vio el SYN-ACK.

La causa real fue enrutamiento asimétrico introducido por un cambio “temporal” upstream. El SYN entró por el proveedor A, pero el SYN-ACK salió por el proveedor B debido a una preferencia de ruta cambiada. Un firewall stateful upstream esperaba el retorno por A y descartó el SYN-ACK como “inválido”.

La solución no fue heroica: ajustar la política de enrutamiento para que la ruta de retorno coincidiera, y coordinar con el equipo upstream para mantener la simetría donde existía inspección stateful. La lección fue simple y dura: no dejes que la palabra “timeout” te obligue a escalar la aplicación. Mide a qué se fue el tiempo.

Mini-historia 2: La optimización que salió mal

Un equipo de plataforma quiso reducir costes y latencia. Movieron la resolución DNS cerca de las cargas desplegando resolvedores cache locales y apuntando todos los hosts a ellos. Parecía funcionar en pruebas sintéticas. Se felicitaron, lo cual suele ser precursor de dolor.

Luego empezaron fallos intermitentes: la discovery de servicios ocasionalmente colgaba y luego se recuperaba. No era constante, lo que lo hacía políticamente molesto. Logs de aplicación mostraban timeouts al consultar dependencias por hostname; las llamadas por IP funcionaban. La guardia desarrolló la superstición de que “el DNS está embrujado”.

Las capturas cuentan la historia. Las respuestas DNS para ciertos registros eran más grandes por DNSSEC y muchos registros A/AAAA. El resolvedor local usaba EDNS0 con un buffer UDP grande. En algún punto del camino—específicamente un dispositivo NAT con una política antigua de fragmentación—las respuestas UDP fragmentadas se descartaban. Los clientes reintentaban por TCP, pero el resolvedor tenía capacidad TCP insuficiente y empezó a hacer colas. Ahora tenías timeouts DNS “aleatorios” según el registro y el tamaño de respuesta.

La optimización fue bienintencionada, pero cambió la forma del tráfico: menos consultas upstream, sí, pero respuestas locales mayores y más ráfagas, y más fragmentación. La solución fue reducir el tamaño EDNS anunciado, asegurar capacidad TCP de fallback y actualizar la política NAT para manejar fragmentos correctamente. El equipo también añadió monitorización directa de la distribución de tiempos de consulta DNS, no solo “tasa de éxito”.

El resultado: DNS estable, y la “optimización” dejó de ser un incidente en cámara lenta. La conclusión perdurable es que las optimizaciones que cambian tamaño de paquete y patrones de ráfaga son cambios de red, se registren o no.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una firma de servicios financieros tenía fama de ser aburrida en gestión de cambios. Mantenían un runbook que exigía capturar evidencia desde ambos extremos para cualquier fallo intermitente de red. No era cool. También fue la razón por la que el incidente terminó antes de la hora de almuerzo.

Una mañana, varios jobs batch empezaron a fallar con “connection timed out” hacia un endpoint de partner externo. Servicios internos estaban bien. El equipo de red sospechó del partner. El equipo de aplicación sospechó de la red. Todos prepararon su blasfemia favorita.

El de guardia siguió el runbook: ejecutó mtr TCP al puerto del partner, capturó tcpdump durante un fallo y registró el 5‑tupla exacto. Capturaron en el host cliente y vieron retransmisiones SYN. Capturaron en el firewall de borde y vieron SYNs salir pero ningún SYN-ACK regresar. Eso no es “quizá”, es una observación direccional.

Repitieron la prueba desde otra IP de egress y vieron conexiones limpias. Así que el problema no era “el partner está caído”. Era específico de ruta. Escalaron al proveedor upstream con mtr y evidencia de paquetes, y el proveedor confirmó un camino roto a ese prefijo de destino desde un punto de peering.

La resolución fue básicamente papeleo más rerouting, pero la velocidad vino de una disciplina aburrida: siempre captura al menos una traza de paquetes en el límite que controlas. El runbook no los hizo más listos. Los hizo más rápidos y difíciles de discutir.

Errores comunes: síntoma → causa raíz → solución

• mtr muestra 30% de pérdida en el salto 4, pero el destino está bien → limitación de ICMP en el salto 4 → Ignora la pérdida de saltos intermedios a menos que continúe hasta el salto final; valida con mtr TCP y tcpdump.
• HTTPS conecta y luego “cuelga” durante el handshake TLS → agujero PMTU o MSS demasiado alto sobre un túnel → Verifica con tracepath, pings DF y corrige MTU/MSS clamping; permite ICMP fragmentation-needed.
• Nuevas conexiones fallan aleatoriamente, las existentes siguen → tabla conntrack/NAT casi llena → Revisa nf_conntrack_count; aumenta límites y reduce churn de conexiones.
• Solo una ruta ISP tiene timeouts → enrutamiento asimétrico o problema de peering upstream → Prueba con capturas (SYN llega, SYN-ACK sale, no se recibe); ajusta enrutamiento o escala con evidencia.
• Los timeouts se correlacionan con ráfagas de tráfico → encolamiento/bufferbloat o saturación CPU del firewall → Observa distribución de latencia (worst/stdev), descartes de interfaz y contadores del firewall; aplica fq_codel/cake y mejoras de capacidad.
• DNS falla “a veces”, especialmente para ciertos nombres → EDNS/fragmentación o un resolvedor malo en la lista → Prueba cada resolvedor directamente; reduce buffer EDNS, asegura fallback TCP, elimina resolvedor defectuoso.
• mtr TCP al puerto funciona, pero la app aún hace timeout → timeouts a nivel de aplicación o sobrecarga del servidor → Usa curl para desglose de tiempos; perfila la app y el servidor; deja de culpar a la red prematuramente.
• Paquetes vistos saliendo del servidor, el cliente no los recibe → descarte en la ruta de retorno (ACL, firewall stateful, rp_filter) → Valida simetría de enrutamiento; ajusta rp_filter; corrige políticas de dispositivos stateful.

Listas de verificación / plan paso a paso

Checklist A: triaje de 15 minutos (operador único, acceso mínimo)

1. Ejecuta curl -w para clasificar DNS vs connect vs TLS vs app.
2. Resuelve hostname a IP con dig; conserva la IP para pruebas.
3. Ejecuta mtr -T -P <port> a la IP con al menos 200 muestras.
4. Ejecuta mtr ICMP una vez para identificar patrones de limitación ICMP (no reacciones exageradas).
5. Comprueba descartes de interfaz local con ip -s link.
6. Comprueba enrutamiento con ip route get.
7. Si timeouts de conexión: ejecuta tcpdump filtrado por host+puerto mientras reproduces.

Checklist B: Probar asimetría o descarte stateful (cuando controlas ambos extremos)

1. Inicia tcpdump en el cliente: filtra host SERVER and tcp port SERVICE.
2. Inicia tcpdump en el servidor: filtra host CLIENT and tcp port SERVICE.
3. Reproduce el timeout y guarda timestamps y la 5‑tupla.
4. Si el servidor ve SYN y envía SYN-ACK, pero el cliente no ve SYN-ACK: ruta de retorno descartada/asimetría.
5. Si el servidor nunca ve SYN: pérdida en la ruta de ida o enrutamiento/ACL antes del servidor.
6. Correlaciona con contadores de firewall/nft y presión de conntrack.

Checklist C: Verificación PMTU / MTU (cuando “pequeño funciona, grande falla”)

1. Ejecuta tracepath -n al objetivo; registra pistas de PMTU.
2. Identifica túneles y MTUs de interfaz con ip link show.
3. Prueba con pings DF a varios tamaños (dentro de las restricciones de MTU local).
4. Clampa MSS en borde de túnel; permite ICMP esencial; vuelve a probar handshake TLS.

Guía operativa que deberías adoptar

• Siempre recoge una traza de paquetes durante el fallo. Una captura de diez segundos vale más que una hora de conjeturas.
• Prefiere mediciones al puerto del servicio (mtr TCP, tcpdump). ICMP es otra clase de tráfico y se trata distinto.
• Mantén un punto de vista “conocido bueno” (una VM pequeña en otra red) para distinguir “tu red” del resto del mundo.

Preguntas frecuentes

1) ¿Por qué mtr muestra pérdida en un salto intermedio pero no en el destino?

Porque el router está despriorizando respuestas ICMP TTL-expired (o limitándolas) mientras sigue reenviando tus paquetes. Confía en la pérdida de extremo a extremo.

2) ¿Debo usar siempre mtr -T?

Para diagnosticar timeouts de aplicación en un puerto TCP específico, sí. Las pruebas ICMP siguen siendo útiles para pistas PMTU y reachability general, pero TCP corresponde mejor a tu carga.

3) ¿Cómo sé si el timeout es DNS?

Usa curl -w y mira time_namelookup. También consulta directamente con dig +time=1 +tries=1. Si DNS está lento, todo parece lento.

4) ¿Cuál es la señal más sencilla de un agujero PMTU?

La conexión TCP funciona, pero el handshake TLS o respuestas grandes se quedan, a menudo con retransmisiones. tracepath puede dar pistas, pero las capturas y pruebas MSS/MTU confirman.

5) ¿Por qué solo algunos usuarios ven timeouts?

Diferentes rutas, diferentes resolvers, diferentes MTUs (VPNs), distinto comportamiento de NAT o distintos bordes de CDN. “Algunos usuarios” suele ser “algunas rutas”.

6) ¿Se puede ejecutar tcpdump de forma segura en servidores de producción?

Sí, si filtras estrictamente y capturas brevemente. Usa filtros host/port, evita escribir pcap enormes en discos muy activos y no lo dejes corriendo sin supervisión.

7) mtr muestra resultados limpios pero los usuarios aún hacen timeout. ¿Y ahora?

mtr no ve colas a nivel de aplicación, problemas TLS o sobrecarga del servidor. Usa el desglose de tiempos de curl, métricas del servidor y tcpdump para ver si los paquetes se atascan después de la conexión.

8) ¿Cómo sé si conntrack es el culpable?

Cuando nf_conntrack_count se acerca a nf_conntrack_max y las nuevas conexiones fallan mientras las existentes se mantienen. Es especialmente común en gateways NAT.

9) ¿Qué cita debo tener en mente durante estos incidentes?

Werner Vogels (idea parafraseada): “Todo falla, todo el tiempo; diseña y opera sistemas asumiendo que la falla es normal”.

Pasos prácticos siguientes

Los tiempos de espera aleatorios dejan de ser “aleatorios” en el momento en que mides la capa correcta y capturas los paquetes adecuados. Haz lo siguiente:

1. Estandariza una clasificación rápida: DNS vs connect vs TLS vs app usando curl -w.
2. Usa mtr TCP al puerto real del servicio y muestrea lo suficiente para captar la intermitencia.
3. Captura tcpdump durante una falla real en al menos un endpoint que controles; si es posible, captura en ambos extremos.
4. Si encuentras problemas PMTU/MTU, arréglalos correctamente (MTU, MSS clamping, ICMP esencial) en lugar de confiar en reintentos.
5. Si encuentras presión de conntrack, trátala como capacidad: sube límites, reduce churn y monitorízala con seriedad.

Lo más importante: anota lo que aprendiste. La próxima vez que el timeout vuelva (y volverá), querrás un runbook, no una sesión de espiritismo.