Debian 13: Las retransmisiones TCP matan el rendimiento — encuentre dónde está realmente la pérdida

noviembre 17, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 8

¿Te fue útil?

Empieza igual cada vez: el equipo de aplicaciones jura “la red está lenta”, el equipo de red jura “los servidores están tirando paquetes”, y tú te quedas mirando un panel que dice “TCP Retransmits” como si fuera un diagnóstico. No lo es. Es un síntoma.

En Debian 13, las retransmisiones pueden significar pérdida real de paquetes, colapso de colas, problemas de PMTU, rarezas de offload, sobrecarga de conntrack, reordenamiento de paquetes o una caja intermedia que hace algo “útil” con tu tráfico. El truco no es demostrar que existen retransmisiones. El truco es determinar dónde ocurre realmente la pérdida (o la ilusión de pérdida): host, hipervisor, tarjeta NIC, switch, firewall o el extremo remoto.

Qué significan realmente las retransmisiones (y qué no)

Las retransmisiones TCP ocurren cuando el emisor cree que un segmento no llegó al receptor. Lo importante es “cree”. TCP infiere pérdida por ACKs faltantes, ACKs duplicados, bloques SACK y temporizadores. Ese ACK faltante puede deberse a:

El segmento de datos se descartó en el camino.
El ACK se perdió en la ruta de retorno.
El segmento llegó pero se quedó detrás de una cola gigante (bufferbloat), llegando lo “suficientemente tarde” como para activar la recuperación por pérdida.
Los paquetes se reordenaron y temporalmente “parecieron perdidos”.
El receptor estaba tan sobrecargado que no ACKeó a tiempo.
Una caja intermedia manipuló MSS/MTU/ECN, causando blackholing o bloqueo.

Así que “las retransmisiones son altas” es como decir “la alarma de humo está sonando”. Sí. Y ahora necesitas encontrar el fuego, la tostada quemada o la persona vapeando debajo del detector.

En Linux moderno, la pila TCP del kernel es excelente. Cuando ves retransmisiones que “matan el rendimiento”, habitualmente es el sistema diciéndote que algo debajo o al lado de TCP se comporta mal: anillos de NIC, bugs del driver, interacciones con offload, inanición de IRQ, o la ruta de red descartando ráfagas.

Verdad seca: tu app puede estar bien. Tus discos pueden estar bien. Tu CPU puede estar bien. Tus retransmisiones siguen siendo reales, y siguen desacelerándote. Arregla la ruta.

Lista de actuación para diagnóstico rápido

Este es el orden que gana incidentes. No prueba todo; encuentra el cuello de botella lo bastante rápido para detener la hemorragia.

Primero: decide si es un host, un enlace o la ruta

Compara varios clientes/servidores. Si un host Debian 13 es el caso atípico, empieza ahí. Si todos los hosts lo ven hacia el mismo destino, sospecha la ruta o el destino.
Revisa contadores de interfaz. Si la NIC muestra errores RX/TX, drops, missed o “no buffer”, probablemente tienes un problema de drops en el host.
Revisa estadísticas TCP. Si las retransmisiones aumentan pero los drops de interfaz se mantienen planos, sospecha congestión aguas arriba, reordenamiento, agujeros MTU o pérdida de ACKs en retorno.

Segundo: localiza la dirección de la pérdida (datos vs ACK)

tcpdump en ambos extremos (o un extremo más span/mirror) y verifica: ¿faltan segmentos de datos en ingreso, o faltan ACKs en egreso?
Revisa la asimetría. La pérdida en la ruta de ACKs se ve como “el emisor retransmite, el receptor recibió los datos”.

Tercero: prueba los sospechosos habituales en el bucle más corto posible

MTU/PMTUD (especialmente VLANs, túneles, tramas jumbo, redes overlay).
Offloads (GRO/LRO/TSO/GSO) cuando la captura de paquetes se ve “rara” o cuando una combinación NIC/driver es conocida por comportarse mal.
Inanición de IRQ/softirq (alta CPU en ksoftirqd, drops con “no buffer”).
Firewall/conntrack (drops, timeouts, “invalid” o presión en la tabla conntrack).
Bonding/LACP (reordenamiento entre enlaces, especialmente con ciertas políticas de hashing).

Una regla: no ajustes TCP hasta que hayas probado que la culpa es de la pila TCP. La mayoría del “tuning de TCP” es superstición costosa con una bonita hoja de cálculo.

Hechos y contexto útiles en war rooms

La lógica de retransmisión TCP es anterior a tu datacenter. Los comportamientos clásicos de fast retransmit y fast recovery se formalizaron en los 90 a medida que Internet crecía y la pérdida se volvió normal.
SACK (Selective Acknowledgment) cambió el juego. Permite a los receptores decir exactamente qué bloques llegaron, reduciendo retransmisiones innecesarias en rutas con pérdida.
Linux ha sido una implementación TCP seria durante décadas. Muchas características de red de alto rendimiento —como opciones modernas de control de congestión— se probaron en Linux antes de convertirse en “estándares de la industria”.
CUBIC se convirtió en el control de congestión por defecto de Linux porque Internet se hizo más rápido. El comportamiento tipo Reno era demasiado conservador para enlaces de alta latencia y ancho de banda.
RACK (Recent ACK) mejoró la detección de pérdidas. Intenta distinguir reordenamiento de pérdida mejor que heurísticos antiguos, reduciendo retransmisiones espurias.
Los offloads GRO/TSO cambiaron cómo se ven las capturas de paquetes. tcpdump puede mostrar paquetes “gigantes” u odd segmentación porque la NIC/kernel están haciendo trabajo que antes veías en la red.
Ethernet no tiene fiabilidad end-to-end incorporada. Los drops son comportamiento permitido bajo congestión; TCP es la capa de fiabilidad, no el switch.
Los microbursts no son tendencia; son clásicos. Enlaces rápidos y buffers poco profundos pueden descartar picos cortos aun cuando la utilización media parece bien.
El fallo de PMTUD es un clásico recurrente. El filtrado de ICMP + túneles/overlays = agujeros negros que parecen “retransmisiones aleatorias”.

Una idea parafraseada que aún aplica viene de Werner Vogels: “Todo falla, todo el tiempo; diseña y opera así.” (idea parafraseada)

Obtener la verdad: medir retransmisiones, pérdida y dónde ocurre

“TCP retransmits” aparece en el monitoreo porque se correlaciona con mala experiencia de usuario. Pero correlación no es localización. Quieres una respuesta a tres preguntas:

¿La pérdida es real o aparente? (Reordenamiento/paquetes tardíos pueden activar recuperación sin caída real.)
¿Ocurre en el host? (Driver/NIC/IRQ/cola drops.)
¿Ocurre en la ruta de red? (Congestión en switch, agujero MTU, drops de firewall.)

Debian 13 incluye un kernel y userland modernos. Eso es buena noticia. También significa que puedes interpretar mal las herramientas si no consideras offloads, namespaces, capas de virtualización y redes overlay. Tu tcpdump no es una confesión; es una declaración de testigo.

Broma #1: La pérdida de paquetes es como la política de oficina: raramente está donde la persona más ruidosa dice que está.

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son tareas de campo: ejecútalas durante un incidente y reducirás el espacio de búsqueda sin empezar una “iniciativa de rendimiento de red” de una semana. Cada tarea incluye: comando, qué significa una salida típica y qué decisión tomar a continuación.

Task 1 — Confirmar retransmisiones y quién las sufre (ss)

cr0x@server:~$ ss -ti dst 10.20.30.40
ESTAB 0 0 10.20.30.10:54322 10.20.30.40:443
	 cubic wscale:7,7 rto:204 rtt:5.2/0.8 ato:40 mss:1460 pmtu:1500 rcvmss:1460 advmss:1460 cwnd:10 bytes_acked:1453297 segs_out:12094 segs_in:11820 send 22.5Mbps lastsnd:12 lastrcv:12 lastack:12 pacing_rate 45.0Mbps unacked:3 retrans:57/1034 reordering:3

Significado: retrans:57/1034 muestra segmentos retransmitidos. Si las retransmisiones aumentan durante un colapso de rendimiento, tienes un problema de recuperación TCP, no simplemente “app lenta”.

Decisión: Si las retransmisiones se concentran en un destino o una interfaz, acótalo. Si es global, sospecha un elemento de ruta compartida (switch, firewall, hipervisor, uplink).

Task 2 — Estadísticas TCP a nivel sistema (nstat / netstat)

cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|TcpTimeouts|TcpExtTCPSynRetrans|TcpExtTCPFastRetrans'
TcpRetransSegs                 18933              0.0
TcpTimeouts                    412                0.0
TcpExtTCPFastRetrans           12080              0.0
TcpExtTCPSynRetrans            55                 0.0

Significado: El aumento de TcpTimeouts implica retransmisiones basadas en RTO (peor) en lugar de fast retransmit (a menudo congestión o reordenamiento). Las retransmisiones de SYN indican problemas de ruta/filtrado.

Decisión: Si los timeouts suben, revisa inmediatamente MTU/agujeros negros y drops severos. Si son en su mayoría fast retransmits, concéntrate en congestión, microbursts o reordenamiento.

Task 3 — Revisar contadores de error y drops de la NIC (ip -s link)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed  mcast
    9876543210  8123456  0       1432     980     12034
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  7456123  0       0       0       0

Significado: dropped y missed en RX que aumentan significan que el host no pudo procesar paquetes entrantes lo suficientemente rápido (desbordamiento de ring, inanición de IRQ, presión de CPU).

Decisión: Si los RX drops/missed aumentan, prioriza el lado del host: estadísticas del driver, anillos, afinidad de IRQ, RPS/XPS, offloads, contención de CPU.

Task 4 — Contadores a nivel driver profundos (ethtool -S)

cr0x@server:~$ sudo ethtool -S eno1 | egrep -i 'drop|miss|err|timeout|buffer|fifo' | head
     rx_dropped: 1432
     rx_missed_errors: 980
     rx_no_buffer_count: 975
     rx_fifo_errors: 0
     tx_timeout_count: 0

Significado: rx_no_buffer_count es la NIC diciendo “tuve tramas, pero no donde ponerlas”. Es una pistola humeante para problemas de ring/IRQ/softirq.

Decisión: Aumenta anillos (Task 9), reparte interrupciones, revisa carga softirq (Task 6) y verifica que no estés haciendo firewall caro en esta máquina.

Task 5 — Validar velocidad/enlace y autonegociación (ethtool)

cr0x@server:~$ sudo ethtool eno1 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes

Significado: Un servidor atascado a 1Gb/s cuando esperas 10/25/100Gb/s no es “pérdida TCP”, es una máquina del tiempo a 2009.

Decisión: Arregla cableado/SFP/config del switch. No ajustes TCP para compensar una degradación por negociación.

Task 6 — Revisar presión de softirq y contención de CPU (mpstat / top)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.12.0 (server)  12/29/2025  _x86_64_  (32 CPU)

12:03:11 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
12:03:12 PM  all  12.1  0.0   8.2   0.3    0.0  18.4   0.0   61.0
12:03:12 PM   7   5.0  0.0   6.1   0.0    0.0  72.3   0.0   16.6

Significado: Un CPU saturado en %soft mientras otros están ociosos grita “desequilibrio de interrupciones/softirq”. Los paquetes llegan, pero un core se está ahogando.

Decisión: Inspecciona distribución de IRQ (Task 7). Considera habilitar/modificar RPS/XPS o ajustar afinidad de IRQ.

Task 7 — Revisar distribución de IRQ para la NIC (procfs)

cr0x@server:~$ grep -E 'eno1|eth0|ixgbe|i40e|mlx|ens' /proc/interrupts | head -n 5
  88:  12000342        0        0        0  IR-PCI-MSI 262144-edge  eno1-TxRx-0
  89:         3        0        0        0  IR-PCI-MSI 262145-edge  eno1-TxRx-1
  90:         1        0        0        0  IR-PCI-MSI 262146-edge  eno1-TxRx-2

Significado: La cola 0 está manejando esencialmente todas las interrupciones. Eso crea drops en RX bajo carga, que se convierten en retransmisiones TCP.

Decisión: Arregla afinidad (irqbalance, máscaras manuales), verifica que RSS esté habilitado, confirma que múltiples colas estén activas.

Task 8 — Buscar drops dentro de qdisc (tc -s)

cr0x@server:~$ tc -s qdisc show dev eno1
qdisc mq 0: root
qdisc fq_codel 8001: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 8123456789 bytes 7456123 pkt (dropped 0, overlimits 0 requeues 2)
 backlog 0b 0p requeues 2

Significado: Si qdisc muestra drops significativos, puede que estés auto-infligiendo pérdida en egreso (traffic shaping, fq_codel mal dimensionado o txqueuelen demasiado pequeño).

Decisión: Si existen drops en egreso, arregla shaping y configuración de colas antes de culpar a la red. Si no hay, sigue adelante.

Task 9 — Revisar y ajustar tamaños de ring de NIC (ethtool -g / -G)

cr0x@server:~$ sudo ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:	4096
TX:	4096
Current hardware settings:
RX:	512
TX:	512

Significado: Un ring RX pequeño puede desbordarse durante ráfagas. Eso produce drops RX, que parecen “retransmisiones TCP aleatorias”.

Decisión: Si ves rx_no_buffer_count y drops missed, aumenta RX/TX rings con cuidado y vuelve a probar.

cr0x@server:~$ sudo ethtool -G eno1 rx 2048 tx 2048

Task 10 — Confirmar MTU end-to-end y detectar desajustes (ip link, ping -M do)

cr0x@server:~$ ip link show dev eno1 | head -n 1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

cr0x@server:~$ ping -c 3 -M do -s 1472 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
1472 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.412 ms
1472 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.398 ms
1472 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=0.405 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Significado: Esto prueba DF (don’t fragment). Si falla en una ruta que crees que soporta 1500/9000, has encontrado un problema de PMTU.

Decisión: Si los pings DF fallan a tamaños esperados, para. Arregla consistencia de MTU o el filtrado de ICMP “fragmentation needed”. Las retransmisiones son un síntoma aguas abajo.

Task 11 — Captura en el host y etiqueta retransmisiones (tcpdump)

cr0x@server:~$ sudo tcpdump -i eno1 -nn 'host 10.20.30.40 and tcp port 443' -vv
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:05:01.101010 IP 10.20.30.10.54322 > 10.20.30.40.443: Flags [P.], seq 12001:13461, ack 8801, win 501, length 1460
12:05:01.104444 IP 10.20.30.10.54322 > 10.20.30.40.443: Flags [P.], seq 12001:13461, ack 8801, win 501, length 1460 (retransmission)
12:05:01.105000 IP 10.20.30.40.443 > 10.20.30.10.54322: Flags [.], ack 13461, win 8192, length 0

Significado: tcpdump anotará “(retransmission)” según lo que vea. Pero recuerda: el punto de captura importa. Capturar en el emisor no prueba que nunca salió de la NIC.

Decisión: Si es posible, captura en ambos extremos. Si sólo en uno: correlaciona con drops de NIC y contadores de switch para evitar culpar a fantasmas.

Task 12 — Verificar offloads cuando la captura se ve mal (ethtool -k)

cr0x@server:~$ sudo ethtool -k eno1 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload|large-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]

Significado: TSO/GSO/GRO pueden hacer que las capturas sean engañosas y pueden interactuar mal con ciertos drivers o túneles, especialmente en overlays virtualizados.

Decisión: Si sospechas rarezas por offload, prueba con un toggle temporal en un host (no a nivel de flota) y mide retransmisiones otra vez.

cr0x@server:~$ sudo ethtool -K eno1 gro off gso off tso off

Task 13 — Revisar presión de conntrack y drops de nftables

cr0x@server:~$ sudo nft list ruleset | head -n 20
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		iif "lo" accept
		tcp dport { 22, 443 } accept
		counter packets 189234 bytes 120934234 drop
	}
}

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

Significado: Si conntrack está cerca del máximo, los flujos nuevos pueden descartarse o retrasarse. Eso produce retransmisiones de SYN y bloqueos “aleatorios”.

Decisión: Si haces firewall stateful en un host muy ocupado, sube límites con cuidado de memoria, reduce tráfico rastreado o mueve el filtrado fuera de la máquina.

Task 14 — Buscar reordenamiento y pistas DSACK (ss -i, nstat)

cr0x@server:~$ ss -ti src 10.20.30.10:54322
ESTAB 0 0 10.20.30.10:54322 10.20.30.40:443
	 cubic rtt:5.1/1.0 rto:204 mss:1460 cwnd:9 unacked:2 retrans:22/903 reordering:18

cr0x@server:~$ nstat -az | egrep 'TcpExtTCPDSACKRecv|TcpExtTCPDSACKOfoRecv|TcpExtTCPSACKReorder'
TcpExtTCPDSACKRecv             3812               0.0
TcpExtTCPDSACKOfoRecv          1775               0.0
TcpExtTCPSACKReorder           2209               0.0

Significado: Contadores relacionados con reordenamiento que suben sugieren que la red no está tanto descartando paquetes como barajándolos. El reordenamiento aún puede dañar el rendimiento porque TCP reacciona a la defensiva.

Decisión: Investiga hashing de LACP/bonding, rutas ECMP y cualquier dispositivo que haga balanceo por paquete. Arreglar el reordenamiento a menudo “arregla retransmisiones” sin cambiar las tasas de pérdida.

Task 15 — Confirmar PMTU desde la vista del kernel (ip route get)

cr0x@server:~$ ip route get 10.20.30.40
10.20.30.40 dev eno1 src 10.20.30.10 uid 1000
    cache mtu 1500

Significado: El MTU en la caché de ruta es lo que el kernel cree que es seguro. Si esperas 9000 y ves 1500, algo aprendió una PMTU más pequeña.

Decisión: Si la PMTU es inesperadamente baja, revisa túneles/VPNs/VXLAN/GRE y si los ICMP “frag needed” se reciben y se toman en cuenta.

Task 16 — Validar estado de bonding/LACP (si aplica)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.12.0

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
Slave Interface: eno1
MII Status: up
Slave Interface: eno2
MII Status: up

Significado: LACP en sí no garantiza entrega en orden si el upstream está mal configurado o si el hashing cambia. Algunas configuraciones producen reordenamiento bajo ciertos patrones de flujo.

Decisión: Si suben contadores de reordenamiento y estás en bonding, prueba con un solo enlace o ajusta la política de hashing y la configuración del port-channel upstream.

Patrones de pérdida que engañan a la gente inteligente

1) “No hay drops en la interfaz, pero toneladas de retransmisiones”

Este es el clásico punto muerto en war rooms. El host dice que no está descartando. TCP dice que está retransmitiendo. Ambos pueden ser verdad.

Pérdidas en la ruta: buffers del switch saturándose, policing/shaping aguas arriba, óptica defectuosa o un firewall que descarta bajo carga.
Pérdida en la ruta de ACKs: tu emisor ve ACKs faltantes, retransmite, pero el receptor en realidad recibió los datos.
Retrasos por colas: los paquetes llegan tarde (bufferbloat), activando fast retransmit o timeouts aunque no se hayan descartado.

Cómo probarlo: captura en ambos extremos (o emisor + SPAN). Si el receptor ve el segmento original y el emisor retransmite de todos modos, probablemente sea problema en la ruta de ACKs o retraso extremo.

2) Microbursts: la utilización promedio miente

Los microbursts son la razón por la que “enlaces al 20%” aún descartan. Los sistemas modernos pueden emitir tráfico en ráfagas: coalescencia de interrupciones, batching en el kernel, GRO, escrituras de la aplicación o replicación de almacenamiento que empuja un gran bloque. Buffers poco profundos en switches ToR pueden descartar estas ráfagas en microsegundos. Tu gráfica SNMP a resolución de 60 segundos te informará alegremente “todo bien”.

Qué hacer: pide contadores de descartes y drops de buffer del switch, idealmente a alta resolución. En el host, busca rx no-buffer y presión de softirq. Si no puedes obtener telemetría del switch, aún puedes inferir microbursts por “sin drops obvios en host” más retransmisiones bajo fan-in alto o emisores sincronizados.

3) Agujeros negros PMTUD: no es pérdida, es un desajuste silencioso de MTU

Si ICMP “fragmentation needed” está bloqueado o mal manejado, los paquetes grandes desaparecen. TCP retransmite. Eventualmente las conexiones se atascan o cojean con comportamiento extraño de MSS. Esto es muy común con túneles, VPNs y overlays.

No adivines. Prueba con ping -M do. Si falla a tamaños razonables, deja de “tunear TCP”. Estás enviando paquetes que la ruta no puede transportar.

4) Reordenamiento: los paquetes llegan, solo que mal educados

TCP asume que el reordenamiento es menos común que la pérdida, aunque Linux ha mejorado en su detección. Si tu red hace balanceo por paquete (intencional o accidentalmente) puedes inducir reordenamiento. Malas configuraciones de bonding también lo hacen.

El resultado: ACKs duplicados, fast retransmits, DSACKs. El rendimiento cae. Todos culpan “pérdida de paquetes” porque ese es el gráfico que tienen.

5) “Activamos la característica X y empeoró” (porque cambió los tiempos)

Offloads, ECN, pacing, qdiscs — muchos son buenos. Pero activarlos en el lugar equivocado puede cambiar el comportamiento de ráfagas y tiempos lo suficiente para exponer un eslabón débil. Eso no significa que la característica sea mala. Significa que tu entorno es frágil.

Broma #2: Desactivar GRO para “arreglar la red” es como apagar el detector de humo para reducir el ruido.

Tres mini-historias corporativas (qué falla realmente)

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

La empresa tenía una nueva flota Debian 13 entrando en producción detrás de un par de firewalls. El despliegue fue suave hasta que un servicio—exportaciones masivas—empezó a fallar por timeout. Las retransmisiones subieron, los RTOs subieron y las exportaciones se volvieron “poco fiables”. El responsable de la aplicación insistió en que era una regresión del kernel.

El equipo de red señaló contadores limpios en los servidores. Sin drops en RX. Sin errores CRC. “No somos nosotros.” El SRE de guardia hizo lo más aburrido posible: probó PMTU con ping -M do entre los hosts exportadores y la API aguas abajo. Falló a tamaños que deberían haber funcionado en esa VLAN.

Todos habían asumido que la VLAN era un dominio Ethernet de 1500 bytes. No lo era. Había un segmento de túnel en medio, y los firewalls estaban configurados para descartar ICMP “fragmentation needed” como “ruido no deseado”. PMTUD no funcionó, y la ruta efectivamente hacía blackhole de paquetes grandes.

Arreglarlo no requirió revertir Debian, cambiar el driver de NIC ni una hoguera de sysctls TCP. Permitieron los tipos ICMP relevantes y ajustaron MSS en el firewall para el túnel. Las retransmisiones bajaron, el throughput volvió y la war room terminó antes del almuerzo.

La suposición equivocada no fue “Debian 13 tiene bugs”. La suposición equivocada fue “nuestra red tiene la MTU que creemos”. Así te llegan las llamadas de emergencia.

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

Otra organización quiso exprimir más throughput de tráfico de replicación. Alguien leyó que “buffers más grandes mejoran rendimiento”, así que aumentaron tamaños de ring de NIC y cambiaron qdisc en un clúster de almacenamiento durante una ventana de mantenimiento. Las pruebas iniciales parecían geniales: menos drops, mayor pico en benchmarks sintéticos.

Entonces llegó producción. Servicios sensibles a latencia que compartían los mismos uplinks empezaron a reportar timeouts. Las retransmisiones subieron en todas partes, no sólo en replicación. Las gráficas no mostraban saturación de enlace, así que las culpas rebotaron entre equipos.

El problema no era que rings más grandes fueran “malos”. El problema fue que rings más grandes más cambios en qdisc incrementaron la latencia de cola bajo carga con ráfagas. La red empezó a almacenar más en buffers del host, el switch almacenó más, y la jitter del RTT se volvió lo bastante grande como para activar RTO y recuperación por pérdida más seguido. Parecía pérdida de paquetes. Parte era entrega retrasada.

La solución fue deshacer los cambios, luego reintroducirlos selectivamente. La replicación obtuvo una clase de interfaz dedicada con pacing controlado, y el tráfico de servicio general volvió a una gestión de colas sensata. Las retransmisiones bajaron porque la red dejó de comportarse como un dispositivo de almacenamiento tratando de ganar un benchmark.

Por eso no “optimices” sin un modelo de lo que tus cargas realmente necesitan. Rápido no es lo mismo que estable.

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

En una tercera empresa, un rack empezó a mostrar retransmisiones TCP elevadas en nodos Debian 13 después de una renovación de hardware. Nada estaba caído, sólo lo bastante lento como para que los clientes notaran. La primera reacción fue perseguir versiones de kernel, firmware de NIC y “quizá IPv6”.

Pero el equipo tenía una práctica aburrida: cada rack tenía una captura “golden” y snapshot de contadores tomada cuando el rack estaba sano. No era nada sofisticado—solo ethtool -S, ip -s link, ss -s y un tcpdump corto. Vivía en un repo junto a las notas de construcción del rack.

Comparar contadores actuales con la baseline mostró una diferencia clara: errores CRC y de alineación en el puerto del switch conectado a un uplink leaf estaban en valor distinto de cero y subiendo. En los hosts los errores aún no eran visibles (el switch estaba viendo el problema físico primero).

Reemplazaron el óptico sospechoso y limpiaron un conector de fibra. Las retransmisiones bajaron en minutos. Sin cambio de kernel, sin tuning de rendimiento, sin apuntar con el dedo. Solo física.

Las prácticas aburridas no dan grandes charlas en conferencias. Terminan incidentes.

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

Esta sección es intencionalmente específica. Estos son los patrones que consumen tiempo porque parecen otra cosa.

1) Retransmisiones TCP altas, drops RX de NIC subiendo

Síntoma: Retransmisiones aumentan con el throughput. ip -s link muestra RX dropped/missed en aumento.
Probable causa raíz: El host no puede atender RX lo suficientemente rápido (IRQ pegado, rings demasiado pequeños, problemas de driver, contención de CPU, nftables pesado, overhead de virtualización).
Solución: Balancea IRQs/RSS, aumenta tamaños de rings, verifica RPS/XPS, reduce carga de firewall/conntrack, coloca cargas lejos de cores saturados por softirq, actualiza firmware/driver de NIC si procede.

2) Retransmisiones altas, sin drops en host, retransmisiones SYN subiendo

Síntoma: TcpExtTCPSynRetrans sube; las conexiones tardan en establecerse.
Probable causa raíz: Firewall que descarta, tabla conntrack llena, enrutamiento asimétrico a través de dispositivo stateful o destino sobrecargado/rechazando.
Solución: Revisa conteo/máximo de conntrack, contadores/logs del firewall, asegura enrutamiento simétrico, reduce tráfico rastreado, ajusta capacidad de firewall o evita filtrado para tráfico interno seguro.

3) Retransmisiones aparecen tras habilitar jumbo frames

Síntoma: Funciona para respuestas pequeñas, se atasca en transferencias grandes; los pings DF fallan.
Probable causa raíz: Desajuste de MTU en algún punto (switch, firewall, túnel overlay), PMTUD bloqueado.
Solución: Haz MTU consistente end-to-end o clampa MSS en los bordes; permite ICMP frag-needed; valida con pings DF a través de la ruta real.

4) Retransmisiones con contadores altos de “reordering”

Síntoma: reordering en ss -i y contadores DSACK suben.
Probable causa raíz: Cambios en hashing de ECMP/LACP, balanceo por paquete, enlaces de velocidades mixtas o bonding/port-channel mal configurado.
Solución: Asegura hashing por flujo, valida configuración de LACP, evita distribución por paquete, prueba con un solo enlace para confirmar.

5) Retransmisiones “solo durante backups” o “solo a la hora en punto”

Síntoma: Picos periódicos de retransmisiones con trabajos programados.
Probable causa raíz: Microbursts y congestión por emisores sincronizados, presión de buffer en switches o colapso de colas en hosts.
Solución: Desfase en horarios, aplica pacing/shaping a flujos masivos, separa clases de tráfico y solicita/inspecciona contadores de descarte del switch.

6) tcpdump muestra retransmisiones, pero logs del receptor indican que los datos llegaron

Síntoma: El emisor retransmite; la aplicación receptora ve duplicados o gestión de datos fuera de orden (o simplemente alta CPU).
Probable causa raíz: Pérdida de ACKs en la ruta de retorno o el punto de captura engaña por offloads/virtual switching.
Solución: Captura en ambos extremos; verifica offloads y puntos de captura; investiga dispositivos en la ruta de retorno y enrutamiento asimétrico.

Listas de verificación / plan paso a paso

Paso a paso: encuentra dónde está la pérdida en 60–90 minutos

Elige un flujo afectado (origen, destino, puerto). No persigas gráficas agregadas. Ejecuta ss -ti dst <ip> y registra retransmisiones, RTT, cwnd.
Revisa contadores de interfaz en ambos extremos: ip -s link, ethtool -S. Si RX drops/missed/no-buffer suben en cualquiera de los extremos, tienes un problema del host que arreglar antes de culpar a la red.
Revisa balance de softirq de CPU: mpstat y /proc/interrupts. Si un core está sobrecargado, arregla IRQ/RSS.
Valida MTU y PMTUD con pings DF a tamaños realistas. Si falla, arregla MTU/ICMP/MSS. No sigas hasta que pase.
Captura paquetes durante un pico de retransmisiones. Si es posible, captura en ambos extremos para la misma ventana. Confirma si los segmentos originales aparecen en el receptor y si los ACKs regresan.
Revisa firewall/conntrack si aplica: contadores nft, conntrack count/max, logs. Si las tablas están cerca del límite o los drops aumentan, arregla esa capa.
Investiga reordenamiento si los contadores suben: bonding, ECMP, overlays multipath. Prueba un test controlado evitando el bond o fijando una ruta.
Involucra al equipo de red con datos concretos: “drops en puerto de switch X”, “errores CRC en uplink”, “PMTU falla a 1472”, “picos de reordenamiento con bond activo”. “Retransmisiones altas” vago obtiene respuestas vagas.

Checklist operativo: evita revivir esto

Baselines de ethtool -S, ip -s link, ss -s para hosts conocidos buenos.
Registrar errores/discards de puertos de switch y correlacionarlos con ventanas de incidentes.
Estandarizar MTU por dominio; documentar dónde cambia (túneles, overlays, WAN).
Preferir hashing por flujo; evitar balanceo por paquete para tráfico TCP intenso.
Mantener dimensionado intencional de conntrack; no dejar defaults en firewalls críticos sin revisar.
Requerir un “mapa de puntos de captura” en entornos virtualizados (host, VM, vSwitch, físico).

Preguntas frecuentes

1) ¿Las retransmisiones TCP son siempre pérdida de paquetes?

No. Son la reacción del emisor a ACKs faltantes. La caída real es común, pero también lo son el reordenamiento y la demora excesiva en colas.

2) ¿Por qué las retransmisiones destruyen tanto el throughput?

TCP reduce su ventana de congestión cuando cree que ocurrió una pérdida. Eso limita la tasa de envío. En rutas de alto BDP, la recuperación puede ser lenta.

3) Si mis contadores de NIC no muestran drops, ¿el host aún puede ser culpable?

Sí. Los drops pueden ocurrir en lugares que no estás mirando: capas de switching virtual, hooks de firewall, conntrack o upstream. Además, no todos los drivers exponen todos los contadores de drops claramente.

4) tcpdump dice “retransmission”. ¿Es definitivo?

Es indicativo, no definitivo. Se basa en lo que tcpdump observa en ese punto de captura. Con offloads y virtualización, podrías estar observando tráfico post-procesado.

5) ¿Debería desactivar GRO/GSO/TSO para arreglar retransmisiones?

Sólo como diagnóstico en un host. Si ayuda, has aprendido algo sobre interacción driver/offload, pero no has comprobado la configuración “correcta” para producción aún.

6) ¿Cómo sé si es un problema MTU/PMTUD?

Pruebas DF ping fallando a tamaños esperados son una señal fuerte. También revisa estancamientos en transferencias grandes y comportamiento extraño de MSS. Arregla manejo de ICMP frag-needed y consistencia de MTU.

7) ¿Por qué las retransmisiones suben durante backups o replicación?

Los flujos masivos generan ráfagas y congestión. Puedes obtener drops por microburst aun cuando la utilización media es moderada. Considera pacing, escalonar o separar clases de tráfico.

8) ¿Puede conntrack causar retransmisiones aunque el servidor “no sea un firewall”?

Sí. Si nftables rastrea tráfico por defecto (común), la tabla conntrack puede llenarse o volverse costosa en CPU, causando drops y demoras—especialmente en churn de conexiones.

9) ¿Cuál es la prueba más rápida de que la ruta de red está descartando paquetes?

Capturas simultáneas en emisor y receptor mostrando segmentos faltantes en el receptor, más contadores limpios del host, apuntan fuertemente a drops en la ruta. Los contadores de descarte del switch lo confirman.

10) ¿Debo ajustar sysctls como tcp_rmem/tcp_wmem primero?

No. Si tienes drops reales, buffers más grandes pueden amplificar la colas y empeorar la latencia. Arregla pérdida y reordenamiento primero; ajusta segundo, con mediciones.

Siguientes pasos que puedes hacer hoy

Deja de tratar “TCP retransmits” como causa raíz. Trátalo como una pista.

Elige un flujo afectado y captura la salida de ss -ti durante el problema.
Revisa ip -s link y ethtool -S en ambos extremos por drops, missed, no-buffer, CRC.
Valida MTU con pings DF a lo largo de la ruta real.
Revisa balance de softirq y distribución de IRQ.
Si sigue sin estar claro, captura paquetes en ambos extremos y compara lo que salió vs lo que llegó.
Solo entonces ajusta rings/offloads/qdisc—y hazlo quirúrgicamente, con rollback.

Si haces esto metódicamente, la discusión sobre “de quién es la culpa” se volverá aburrida. Aburrido es bueno. Aburrido significa que estás a punto de arreglarlo.