Ruteo asimétrico: la causa invisible de las «caídas aleatorias»

febrero 6, 2026 • febrero 6, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Todo SRE se topa tarde o temprano con un incidente que se comporta como un fantasma. Las métricas se disparan. Aparecen resets TCP que van y vienen. Una zona de disponibilidad parece maldita. Los usuarios juran que es “aleatorio” y tu canal de incidentes se convierte en una sesión grupal de terapia.

La mitad del tiempo, la red está haciendo exactamente lo que le pediste—simplemente no lo que pensabas que le habías pedido. El ruteo asimétrico es el clásico culpable: el tráfico sale por un camino y vuelve por otro, y cualquier elemento stateful en el medio empieza a tomar decisiones “útiles” que parecen sabotaje.

Qué es realmente el ruteo asimétrico (y por qué duele)

El ruteo asimétrico significa que la ruta de ida y la de vuelta de un flujo son diferentes. No “diferentes por un salto”. Diferentes por un límite de dispositivo que importa: un clúster de firewall, una puerta de enlace NAT, un balanceador de carga, un appliance anti-DDoS, un IDS/IPS, o incluso un host Linux que hace connection tracking.

Internet es inherentemente asimétrica. BGP no promete simetría. Promete alcanzabilidad, y eso viene con un encogimiento de hombros. En muchos entornos, la asimetría es normal e inofensiva porque los routers son máquinas de reenvío sin estado y no les importa por qué interfaz llegan los paquetes.

Las redes de producción, sin embargo, están llenas de dispositivos y kernels que mantienen estado:

Firewalls stateful rastrean sesiones. Si un SYN va por un lado y un SYN-ACK vuelve por otro, obtendrás drops o logs de “invalid state”.
NAT es estado por definición. Los paquetes de retorno necesitan la misma entrada de traducción.
Balanceadores de carga a menudo dependen de una 5-tupla consistente, o inyectan comportamientos SNAT/DSR que cambian dónde debería salir el tráfico de retorno.
Conntrack en Linux (iptables/nftables) puede descartar paquetes que no coinciden con el estado esperado.
Reverse-path filtering (rp_filter) puede descartar respuestas si el kernel piensa que la fuente no debería ser alcanzable por esa interfaz.

El ruteo asimétrico no siempre es “malo”. Es problemático cuando tus middleboxes stateful no están de acuerdo sobre la realidad, o cuando tu postura de seguridad asume “si no vino por mí, es sospechoso”. La mayoría de redes las diseñan optimistas y luego las operan pesimistas. Esa es la tensión.

Por qué parece aleatorio: estado, hashing y dolor selectivo

La asimetría no suele romperlo todo. Rompe algunos flujos, en patrones que se sienten como superstición. He aquí por qué:

ECMP hace que el comportamiento por flujo parezca tirar dados

Equal-Cost Multi-Path (ECMP) reparte flujos entre múltiples next-hops usando un hash (a menudo de la 5-tupla). Eso significa:

Una conexión TCP puede funcionar perfectamente mientras otra, hacia la misma IP, falla.
Los reintentos pueden funcionar porque la tupla cambia (nuevo puerto origen, nuevo hash, nuevo next-hop).

A los ojos humanos, eso es “aleatorio”. Para el router, es matemática determinista.

Los dispositivos stateful fallan cerrando, de forma selectiva

Firewalls, conntrack y dispositivos NAT típicamente descartan paquetes que no pueden clasificar. Pero la clasificación depende de ver el inicio de la conversación (SYN) y mantener la traducción/estado. Si sólo el tráfico de retorno es asimétrico, tu cliente ve bloqueos y retransmite; si sólo el tráfico de ida es asimétrico, tu servidor ve sesiones semi-abiertas. En ambos casos, el equipo de la aplicación recibe la alerta primero. Naturalmente.

Los reintentos borran la escena del crimen

Los stacks modernos reintentan agresivamente. Los clientes HTTP abren nuevas conexiones. QUIC cambia otra vez las reglas. Los balanceadores reintentan upstreams. Lo que ves son picos de latencia, no fallos totales. Eso es peor porque nadie cree que sea “la red” hasta que ya es tarde.

Broma #1: El ruteo asimétrico es como perder un calcetín en la lavandería: todo sigue funcionando, pero te arruina la mañana en silencio.

Hechos interesantes y contexto histórico

Un poco de contexto ayuda porque el ruteo asimétrico no es un “problema de la nube” ni un “problema moderno”. Es una propiedad de cómo construimos Internet y luego le atornillamos seguridad y observabilidad.

BGP nunca garantizó simetría. Es un protocolo path-vector centrado en política y alcanzabilidad, no en elegancia del ida y vuelta.
Las redes tempranas asumían forwarding sin estado. El diseño original de IP esperaba routers “tontos” y endpoints encargándose de la fiabilidad.
Los firewalls stateful popularizaron “la ruta de retorno debe coincidir”. Cuando las empresas estandarizaron en inspección stateful, la asimetría se convirtió en un gatillo práctico de outages.
NAT hizo la asimetría peligrosamente operativa. NAT requiere tablas de traducción; romper la ruta de retorno rompe la sesión, no solo el rastro.
ECMP se volvió común conforme creció la necesidad de ancho de banda. El reparto por hash funciona hasta que lo combinas con dispositivos stateful que no comparten estado correctamente.
Las comprobaciones anti-spoofing evolucionaron hacia rp_filter y uRPF. Estas mitigaciones mejoraron seguridad pero convirtieron la asimetría en condición de drop en vez de curiosidad.
El clustering de firewalls impulsó la sincronización de estado. Los vendedores añadieron sync/HA porque el tráfico asimétrico y los failovers arruinaban sesiones.
Anycast normalizó la asimetría a escala global. Anycast te rutea al sitio más cercano—hasta que el camino de retorno sigue otra política y aprendes humildad.
El networking en la nube hizo los caminos menos visibles. Cuando no posees el underlay, depuras síntomas—y la asimetría prospera en las sombras.

Modos de fallo: qué se rompe y cómo se manifiesta

El ruteo asimétrico en sí no es una falla. Es la precondición. La falla es lo que pasa cuando algo espera simetría. Aquí están los rompimientos comunes, con el “olor” que notas primero.

1) Firewalls stateful descartando paquetes “fuera de estado”

Olor: algunas conexiones quedan colgadas en SYN-SENT o ESTABLISHED con retransmisiones. Los logs del firewall muestran “invalid state” o “no session”.

Mecanismo: el SYN de ida pasa por Firewall A, el SYN-ACK de retorno llega por Firewall B. Firewall B nunca vio el SYN; descarta el SYN-ACK.

2) El tráfico de retorno de NAT no encuentra el traductor

Olor: conexiones salientes funcionan de forma intermitente; las respuestas entrantes nunca llegan; las capturas muestran respuestas golpeando otro borde.

Mecanismo: source NAT creado en un dispositivo, la respuesta llega a otro sin esa entrada en la tabla de traducción.

3) Linux rp_filter descarta respuestas en la interfaz “incorrecta”

Olor: problema en un único host; pings desde una parte funcionan, desde otra no; dmesg muestra martian source o drops por rp_filter según la configuración/logs.

Mecanismo: la comprobación de ruta inversa falla: el kernel cree que la fuente sería alcanzable por otra interfaz diferente a la que llegó el paquete.

4) Conntrack marca “INVALID” y tus reglas lo descartan

Olor: contadores de nftables/iptables se incrementan en reglas de drop por INVALID; algunos flujos mueren tras reroutes/failovers.

Mecanismo: los paquetes llegan sin una entrada conntrack porque el paquete iniciador tomó un camino diferente, o hubo un reroute a mitad de flujo.

5) Desajuste de ruta de retorno en el balanceador (confusión SNAT/DSR)

Olor: health checks en verde, tráfico de usuario inestable; sólo fallan ciertas redes cliente; el servidor ve tráfico pero el cliente no recibe respuestas.

Mecanismo: en diseños DSR o NAT parcial, el tráfico de retorno evita el LB o elige un egress distinto; dispositivos de seguridad aguas arriba lo descartan o se enruta mal.

6) PMTUD/MTU mal diagnosticado como asimetría (y viceversa)

Olor: paquetes pequeños funcionan, los grandes se quedan; ajustar TCP MSS “arregla” el problema; traceroute es inconsistente.

Mecanismo: el blackholing por MTU es su propio problema, pero las rutas asimétricas pueden tener MTUs distintas y comportamiento ICMP diferente, haciendo que todo parezca pérdida aleatoria.

Broma #2: Si tu paquete toma un camino diferente a casa, no lo llames “aventurero”—llámalo “a punto de ser descartado por un firewall”.

Guion de diagnóstico rápido (primero/segundo/tercero)

Esta es la parte que sigues a las 02:13 cuando todos quieren una respuesta y tú quieres volver a la cama.

Primero: Prueba que es un problema de camino, no local del host

Elige una 5-tupla que falle (src IP:port → dst IP:port). No depures “el servicio”. Depura un flujo específico.
Revisa retransmisiones y resets en cliente y servidor. Si ves retransmisiones SYN o stalls en el medio, estás en territorio de red/estado.
Ejecuta traceroutes hacia adelante y hacia atrás (o al menos compara patrones de saltos desde ambos extremos). Si las rutas difieren de forma significativa a través de límites de seguridad, sospecha asimetría.

Segundo: Identifica el cuello de botella stateful

Encuentra límites de NAT/firewall/LB en el camino. La mayoría de “caídas aleatorias” son dispositivos stateful haciendo cumplir una narrativa sobre sesiones.
Busca contadores/logs de “invalid state” en esos dispositivos (o en reglas de drop de conntrack en Linux).
Comprueba ECMP / múltiples next-hops en las rutas relevantes. Si tienes dos salidas, puedes tener dos retornos.

Tercero: Confirma con captura de paquetes y tablas de enrutamiento

Captura en ambos extremos. Si el servidor envía respuestas y el cliente no las ve (o viceversa), has acotado el problema al medio de la red.
Revisa rp_filter y policy routing en los hosts si el problema es unilateral.
Forza simetría temporalmente (fija la ruta, desactiva ECMP para el prefijo, configura persistencia de sesión correctamente) para validar la hipótesis antes de un cambio permanente.

Regla práctica: si un flujo funciona desde una subred origen pero no desde otra, probablemente estás viendo una diferencia de política de ruteo, no una NIC defectuosa.

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

A continuación hay tareas que puedes ejecutar. Cada una incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar la selección de ruta hacia el destino (Linux)

cr0x@server:~$ ip route get 203.0.113.10
203.0.113.10 via 192.0.2.1 dev eth0 src 192.0.2.20 uid 1000
    cache

Qué significa: El kernel enviará tráfico a 203.0.113.10 vía gateway 192.0.2.1 por eth0, usando la IP origen 192.0.2.20.

Decisión: Si el egress esperado es distinto (interfaz equivocada, IP origen equivocada), tienes problemas de policy routing o prioridad de rutas antes incluso de alcanzar la red.

Task 2: Comprobar reglas de policy routing (Linux)

cr0x@server:~$ ip rule show
0:	from all lookup local
100:	from 192.0.2.0/24 lookup 100
32766:	from all lookup main
32767:	from all lookup default

Qué significa: El tráfico originado desde 192.0.2.0/24 usa la tabla de ruteo 100. Eso puede crear rutas de retorno asimétricas si las respuestas eligen otra tabla.

Decisión: Si la asimetría es específica del host, valida la ruta por defecto de la tabla 100 y asegúrate de que el tráfico de retorno use la misma política (o aplica SNAT deliberadamente).

Task 3: Inspeccionar la tabla de ruteo alternativa usada por policy routing

cr0x@server:~$ ip route show table 100
default via 198.51.100.1 dev eth1
198.51.100.0/24 dev eth1 proto kernel scope link src 198.51.100.20

Qué significa: Las respuestas originadas desde 192.0.2.0/24 pueden salir por eth1 vía un gateway distinto. Disparador clásico de asimetría.

Decisión: Alinea la subred origen prevista con el egress previsto, o aplica SNAT/marca de tráfico para que ida y vuelta coincidan con tus límites de seguridad.

Task 4: Comprobar reverse-path filtering (rp_filter)

cr0x@server:~$ sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1

Qué significa: Está habilitado reverse-path filtering estricto. Si los paquetes llegan por una interfaz que el kernel no usaría para alcanzar la fuente, pueden ser descartados.

Decisión: Si tienes rutas asimétricas legítimas (multihoming, VRFs, túneles), ajusta rp_filter a modo loose (2) o desactívalo por interfaz tras una revisión de riesgos.

Task 5: Observar drops de conntrack vía contadores nftables

cr0x@server:~$ sudo nft list chain inet filter input
table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		ct state established,related accept
		ct state invalid counter packets 184 bytes 11040 drop
		iif "lo" accept
		tcp dport 22 accept
	}
}

Qué significa: 184 paquetes han golpeado la regla de conntrack INVALID y fueron descartados. Eso es una pista clara cuando “conexiones aleatorias” fallan.

Decisión: Investiga por qué los paquetes son INVALID: ruteo asimétrico, reroutes a mitad de flujo, problemas NAT o helpers de conntrack faltantes. No aceptes INVALID a ciegas sin comprenderlo.

Task 6: Vigilar eventos de conntrack en vivo (identificar resets/síntomas de asimetría)

cr0x@server:~$ sudo conntrack -E -o timestamp,extended
[1707052741.122334] [NEW] tcp      6 120 SYN_SENT src=192.0.2.20 dst=203.0.113.10 sport=43122 dport=443 [UNREPLIED] src=203.0.113.10 dst=192.0.2.20 sport=443 dport=43122
[1707052744.127991] [DESTROY] tcp  6 120 src=192.0.2.20 dst=203.0.113.10 sport=43122 dport=443 [UNREPLIED] src=203.0.113.10 dst=192.0.2.20 sport=443 dport=43122

Qué significa: El SYN salió, pero no se vio respuesta (UNREPLIED). Eso apunta a problemas en la ruta de retorno o filtrado del SYN-ACK.

Decisión: Captura en la interfaz del servidor y en el firewall/LB aguas arriba para localizar dónde muere el SYN-ACK.

Task 7: Capturar el flujo que falla en el cliente (tcpdump)

cr0x@server:~$ sudo tcpdump -ni eth0 host 203.0.113.10 and tcp port 443
14:13:01.000001 IP 192.0.2.20.43122 > 203.0.113.10.443: Flags [S], seq 1000, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0], length 0
14:13:02.000314 IP 192.0.2.20.43122 > 203.0.113.10.443: Flags [S], seq 1000, win 64240, options [mss 1460,sackOK,TS val 2 ecr 0], length 0

Qué significa: Retransmisiones de SYN. No llega ningún SYN-ACK a esta interfaz.

Decisión: O el SYN no llegó, o el SYN-ACK vuelve por otro camino. Ahora captura también en el lado del servidor.

Task 8: Capturar en el servidor: ¿recibió SYN y envió SYN-ACK?

cr0x@server:~$ sudo tcpdump -ni eth0 host 192.0.2.20 and tcp port 443
14:13:01.010010 IP 192.0.2.20.43122 > 203.0.113.10.443: Flags [S], seq 1000, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0], length 0
14:13:01.010200 IP 203.0.113.10.443 > 192.0.2.20.43122: Flags [S.], seq 2000, ack 1001, win 65160, options [mss 1460,sackOK,TS val 9 ecr 1], length 0

Qué significa: El servidor está respondiendo. La respuesta sale por la interfaz del servidor.

Decisión: El drop está entre servidor y cliente en la ruta de retorno. Revisa ruteo, firewalls, NAT y ECMP entre esos dos puntos.

Task 9: Validar la ruta de retorno desde el servidor a la IP del cliente

cr0x@server:~$ ip route get 192.0.2.20
192.0.2.20 via 203.0.113.1 dev eth1 src 203.0.113.10 uid 0
    cache

Qué significa: El servidor enruta las respuestas al cliente vía eth1, no eth0. Eso es asimetría por diseño o accidente.

Decisión: Si tu firewall/NAT/LB espera que ambas direcciones pasen por eth0, corrige el ruteo del servidor (policy route, default route, o ruteo basado en origen) o adapta el intermedio para tolerar asimetría (state sync, diseño DSR, etc.).

Task 10: Comprobar next-hops ECMP en un router (ejemplo con FRR/vtysh)

cr0x@server:~$ sudo vtysh -c "show ip route 203.0.113.0/24"
Routing entry for 203.0.113.0/24
  Known via "bgp", distance 20, metric 0
  * 198.51.100.2, via swp1, weight 1
  * 198.51.100.3, via swp2, weight 1

Qué significa: Existen dos next-hops con costo igual. Diferentes flujos pueden salir por dispositivos upstream distintos, que pueden no compartir estado/NAT.

Decisión: Si los dispositivos upstream son stateful y no están en un clúster con sincronización de estado, haz que compartan estado o elimina ECMP para el prefijo/clase de tráfico afectada.

Task 11: Confirmar drops “no session” del firewall (host Linux actuando como firewall)

cr0x@server:~$ sudo journalctl -k -g "IN=.*OUT=.*STATE=INVALID" -n 5
Feb 04 14:12:59 fw1 kernel: [UFW BLOCK] IN=eth2 OUT= MAC=... SRC=203.0.113.10 DST=192.0.2.20 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=0 DF PROTO=TCP SPT=443 DPT=43122 WINDOW=65160 RES=0x00 ACK SYN URGP=0 STATE=INVALID

Qué significa: Un SYN-ACK (ACK SYN) llegó pero fue considerado INVALID por conntrack, y fue bloqueado.

Decisión: Trátalo como asimetría hasta demostrar lo contrario. Encuentra dónde fue el SYN correspondiente (otra interfaz o nodo de firewall diferente), luego aplica ruteo simétrico o habilita sincronización de estado adecuada.

Task 12: Comparar ruta de ida vs vuelta con traceroute desde ambos extremos

cr0x@server:~$ traceroute -n 203.0.113.10
 1  192.0.2.1  0.312 ms
 2  198.51.100.9  1.102 ms
 3  203.0.113.10  2.004 ms

cr0x@server:~$ traceroute -n 192.0.2.20
 1  203.0.113.1  0.401 ms
 2  198.51.100.10  1.220 ms
 3  192.0.2.20  2.331 ms

Qué significa: Las rutas son diferentes incluso en el salto 2. Si el salto 2 incluye dispositivos stateful (pares de firewall, gateways NAT), tienes un desajuste en la ruta de retorno.

Decisión: Identifica qué salto es el límite de estado y corrige la política de ruteo para que ambas direcciones atraviesen el mismo miembro del clúster stateful (o comparte estado).

Task 13: Comprobar ARP/neighbor y adyacencia L2 (la asimetría también puede ser L2)

cr0x@server:~$ ip neigh show dev eth0 | head
192.0.2.1 lladdr 00:11:22:33:44:55 REACHABLE
192.0.2.254 lladdr 00:aa:bb:cc:dd:ee STALE

Qué significa: Podrías tener múltiples gateways, VRRP o HSRP. Si la MAC del gateway cambia o hay múltiples routers activos inesperadamente, los flujos pueden regresar por un L3 hop distinto.

Decisión: Valida la configuración FHRP y asegúrate de que sólo el gateway previsto responda por la IP virtual, o garantiza hashing/pinning consistente en el par redundante.

Task 14: Validar MSS/MTU para descartar “no es asimetría”

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

--- 203.0.113.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss

Qué significa: Este host no puede enviar paquetes de 1500 bytes con DF activado. Eso es MTU local, no necesariamente path MTU, pero es una señal rápida para verificar MTU end-to-end.

Decisión: Si MTU difiere a través de rutas asimétricas, verás stalls “aleatorios” en cargas grandes. Normaliza MTU, aplica MSS clamping en bordes cuando haga falta, y no culpes sólo a la asimetría.

Tres micro-historias corporativas desde el campo

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

Tenían un diseño “simple”: dos firewalls en HA, dos routers core y ECMP en todas partes porque el ancho de banda es caro y los diagramas son baratos. El equipo de aplicaciones se quejaba de fallos esporádicos de login. No era un fallo total. Suficiente para que los clientes cuestionaran si la empresa era solvente.

La suposición del equipo de red era razonable en el papel: “Ambos firewalls están en el mismo clúster, así que el estado se comparte”. En realidad, la sincronización de estado estaba habilitada sólo para algunas clases de tráfico, y ciertas zonas no estaban incluidas por una vieja preocupación de rendimiento. Nadie lo recordaba porque el ingeniero que lo configuró ya se había ido, como suele pasar.

El modo de fallo fue brutal: el SYN salió por Firewall A, el SYN-ACK volvió por Firewall B, y B no tenía estado para esa zona. Lo descartó. TCP retransmitió. A veces el hash caía en el miembro “correcto” y funcionaba, lo que hacía que pareciera un bug de la aplicación.

La solución no fue heroica. Restringieron ECMP para mantener ambas direcciones ancladas en el mismo miembro del firewall para ese prefijo, y luego corrigieron la cobertura de state-sync. La lección real del postmortem no fue “habilitar state sync”. Fue “deja de asumir que HA significa estado compartido para cada camino”. HA sin estado compartido son sólo dos dispositivos que se turnan para decepcionarte.

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

Otra empresa quería reducir latencia para una API interna consumida por miles de servicios. Alguien propuso un cambio de “ruteo inteligente”: enviar tráfico este-oeste por el router de salida más cercano y dejar que el tráfico de retorno tome el camino más corto de regreso. La propuesta sonaba moderna: menos saltos, mejor utilización, más “resiliencia”.

El problema: entre esos routers vivía un appliance IDS configurado en modo inline solo para una dirección del camino, porque el diseño original asumía simetría y lo colocó en consecuencia. Tras el cambio, la mitad de los flujos eran inspeccionados en una dirección, mientras que el tráfico de retorno evitaba la inspección y llegaba a un ACL stateful en un dispositivo distinto. Ese ACL descartaba paquetes que no esperaba porque nunca vio el setup inicial de la sesión.

Los síntomas fueron el clásico “azar”: solo fallaban algunos microservicios, algunos pods, algunas veces. El equipo pasó días persiguiendo throttling de CPU y garbage collection. El cambio de red fue “demasiado pequeño para importar”, que es exactamente cómo se generan outages.

Revirtieron la optimización y la reintrodujeron después con un diseño adecuado: o bien asegurar que los dispositivos de inspección vean ambas direcciones, o convertir la inspección en observacional/estatalmente inofensiva en vez de inline. La latencia mejoró eventualmente. La lección: no optimices caminos en una red stateful sin mapear todas las dependencias stateful. Tus paquetes no son solo datos; son una narrativa y los middleboxes son editores entrometidos.

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

Una tercera organización operaba un setup multiregión con frontales anycast y firewalls regionales. Tenían una política: cualquier cambio que pudiera influir en el ruteo requería dos artefactos—un diagrama de ruta anotado y una “lista de límites de estado” nombrando cada punto NAT/firewall/LB/conntrack.

Sonaba burocrático. Los ingenieros se quejaban. Pero durante un incidente del proveedor, el tráfico a una región cambió y las rutas de retorno empezaron a comportarse de forma extraña. El on-call sacó la lista de límites de estado y preguntó inmediatamente la pregunta correcta: “¿Qué dispositivo espera ver tanto SYN como SYN-ACK?”.

Ya tenían contadores exportados de los firewalls para drops “no session”, además de drops INVALID de conntrack en ciertos gateways Linux. Esos dashboards se iluminaron en minutos. En vez de debatir teorías, fijaron rutas para los prefijos afectados de modo que ambas direcciones atravesaran el mismo miembro del clúster firewall y deshabilitaron temporalmente una política uRPF estricta para un segmento asimétrico conocido.

Sin heroísmos. Sin magia. Solo un equipo que había decidido por adelantado qué importaba y lo instrumentó. El incidente todavía ocurrió—las redes son redes—pero terminó rápido, con daño colateral mínimo. Lo aburrido es bueno cuando la producción está en llamas.

Errores comunes: síntomas → causa raíz → arreglo

Esta sección es intencionalmente específica. Si reconoces el síntoma, actúa como si fuera culpable hasta demostrar lo contrario.

1) “Algunos clientes no se conectan, pero otros sí”

Síntoma: misma IP/puerto del servicio; ciertas subredes origen fallan más.

Causa raíz: diferente política de ruteo de ingreso/egreso por origen; el tráfico de retorno cruza un firewall/NAT distinto.

Arreglo: aplica ruteo simétrico para ese servicio (PBR, alineación de VRF o pinning de rutas); si usas ECMP, asegúrate de que los dispositivos stateful compartan estado o evita ECMP a través de ellos.

2) “Los reintentos funcionan” (especialmente tras unos segundos)

Síntoma: primer intento de conexión falla, el segundo tiene éxito; el usuario percibe lentitud.

Causa raíz: el hash ECMP selecciona un next-hop distinto; un camino golpea un dispositivo que descarta paquetes fuera de estado.

Arreglo: elimina el camino roto del set ECMP; corrige la sincronización de estado; añade hashing consistente sobre la tupla correcta; verifica la simetría de la ruta de retorno.

3) “El firewall muestra drops por invalid state”

Síntoma: logs como “no session”, “invalid state”, “SYN-ACK out of state”.

Causa raíz: asimetría entre miembros del clúster de firewall; o bypass asimétrico del firewall en una dirección.

Arreglo: asegura que ambas direcciones pasen por el mismo miembro del firewall (afinidad de sesión / ruteo simétrico) o usa un clúster con state-sharing correctamente configurado. Deja de repartir flujos entre nodos stateful independientes.

4) “Solo un host está roto; el resto funciona”

Síntoma: una única VM/nodo tiene conectividad intermitente; mover la carga la arregla.

Causa raíz: rp_filter en modo estricto con multihoming/túneles; mismatch en policy routing local; selección incorrecta de IP origen.

Arreglo: configura rp_filter=2 (loose) en las interfaces relevantes; corrige ip rules/routes; fuerza la selección de IP fuente con política de ruteo; valida que las respuestas salgan por la interfaz prevista.

5) “Los health checks están verdes, los usuarios no”

Síntoma: el balanceador dice que los backends están bien; el tráfico real falla de forma intermitente.

Causa raíz: los health checks originan desde una subred/camino diferente (simétrico) al tráfico de usuario (asimétrico); o DSR hace que la ruta de retorno evite dispositivos críticos.

Arreglo: haz que los health checks sean representativos (misma IP origen, mismas características de camino, MTU); alinea el modo del LB (SNAT vs DSR) con las expectativas de ruteo/seguridad; asegura la corrección de la ruta de retorno.

6) “Huele a MTU, pero solo a veces”

Síntoma: transferencias grandes se quedan; peticiones pequeñas están bien; intermitente según el cliente o el momento.

Causa raíz: rutas asimétricas con MTUs distintas o políticas ICMP distintas; PMTUD falla en un camino pero no en otro.

Arreglo: normaliza MTU entre rutas; permite ICMP necesario; aplica MSS clamping en los bordes cuando sea necesario; valida con pings con DF y capturas.

7) “Habilitamos anti-spoofing estricto y ahora está inestable”

Síntoma: nuevos drops tras habilitar uRPF o rp_filter del kernel; segmentos asimétricos se rompen.

Causa raíz: las comprobaciones inversas asumen ruteo simétrico.

Arreglo: usa modo loose donde la asimetría es legítima; rediseña el ruteo para ser simétrico en los límites stateful/seguridad; documenta excepciones en lugar de ignorarlas.

Listas de verificación / plan paso a paso

Pasos: diagnosticar un incidente sospechoso de ruteo asimétrico

Elige un flujo que falle. Registra IP/puertos origen/destino, protocolo, ventana temporal.
Revisa tcpdump del cliente. ¿Ves el SYN salir? ¿Ves el SYN-ACK volver?
Revisa tcpdump del servidor. ¿Llegó el SYN? ¿Respondió el servidor?
Compara ip route get en ambos extremos. Confirma interfaz de egress y gateway esperados para cada dirección.
Revisa policy routing (ip rule) en ambos extremos. Especialmente si hay multihoming, túneles o múltiples VRFs.
Inspecciona la configuración rp_filter. Si es estricta, considérala culpable hasta demostrar lo contrario.
Inspecciona contadores/logs de conntrack INVALID. En firewalls, gateways NAT y middleboxes Linux.
Identifica conjuntos ECMP para prefijos afectados. Si hay múltiples next-hops, prueba fijando temporalmente la ruta.
Valida la sincronización de estado en clusters de firewall/NAT. Verifica que cubra las zonas/VRFs correctas y no esté “mayormente habilitada”.
Vuelve a probar con simetría forzada. Fija la ruta, desactiva un camino o ajusta la política para un experimento controlado.
Corrige permanentemente. Decide: imponer simetría o garantizar compartición de estado / diseño sin estado.
Instrumenta. Exporta contadores/logs para que la próxima vez lo detectes en minutos, no en horas.

Lista de prevención: evitar que la asimetría provoque outages

Inventaría dispositivos stateful en cada camino crítico (firewall, NAT, LB, IDS/IPS, hosts con conntrack).
Decide dónde se requiere simetría y aplícala con política y diseño, no por esperanza.
No hagas ECMP a través de nodos stateful independientes a menos que hayas demostrado state-sharing a escala.
Estandariza la política rp_filter y documenta excepciones para nodos multihomed/túneles.
Haz health checks realistas (misma red origen, mismas características de camino y MTU).
Exporta las señales correctas: drops INVALID, contadores “no session”, uso de la tabla conntrack y eventos de cambio de ruta.

Preguntas frecuentes

1) ¿El ruteo asimétrico es siempre un problema?

No. Es normal en muchas redes. Se convierte en problema cuando un dispositivo stateful espera ver ambas direcciones de un flujo (firewall, NAT, conntrack, algunos LB/IDS).

2) ¿Por qué falla sólo para algunas conexiones?

ECMP y la distribución de carga son por flujo. Una 5-tupla puede hashear a un camino “bueno”; otra, a uno “malo”. Los reintentos cambian los puertos origen y con ello el hash, lo que parece aleatoriedad.

3) ¿Cómo puedo probar que el tráfico de retorno toma un camino distinto?

Usa captura de paquetes en ambos extremos y compara traceroutes desde los dos lados. Si el servidor envía SYN-ACK y el cliente nunca lo ve, la ruta de retorno es la escena del crimen.

4) ¿TCP maneja automáticamente el ruteo asimétrico?

TCP no se preocupa por la simetría. TCP necesita que los paquetes lleguen. Los middleboxes se preocupan por la simetría porque se han insertado en la historia de la sesión.

5) ¿Cuál es la diferencia entre ruteo asimétrico y blackholing por MTU?

El blackholing por MTU generalmente se correlaciona con el tamaño de los paquetes (los pequeños funcionan, los grandes fallan). La asimetría se correlaciona con límites de estado en el camino y a menudo muestra “invalid state” o ausencia de SYN-ACK.

6) ¿Cómo se relaciona rp_filter con la asimetría?

rp_filter realiza una búsqueda de ruta inversa y descarta paquetes si llegan por una interfaz que el kernel no usaría para alcanzar la fuente. El modo estricto rompe multihoming legítimo y rutas de retorno asimétricas.

7) Tenemos un par de firewall HA. ¿Por qué la asimetría sigue causando problemas?

HA no garantiza estado de sesión compartido para cada clase de tráfico, VRF o zona. Además, ECMP puede dispersar flujos entre miembros de formas que el diseño del clúster no anticipó.

8) ¿Cuál es la solución más limpia: imponer simetría o hacer que los dispositivos toleren la asimetría?

Imponer simetría suele ser más simple y predecible. Tolerar asimetría requiere intercambio robusto de estado o eliminar dependencias stateful inline (más difícil, pero a veces la solución a largo plazo correcta).

9) ¿Kubernetes puede causar ruteo asimétrico?

Sí. SNAT a nivel de nodo, redes overlay, múltiples interfaces CNI y externalTrafficPolicy/local pueden influir en las rutas de retorno. El enfoque de diagnóstico es el mismo: elige un flujo, captura ambos extremos, revisa policy routing y puntos SNAT.

10) ¿Sobre qué debo alertar para detectar esto temprano?

Alerta sobre contadores de firewall “no session/invalid state”, drops INVALID de conntrack, aumentos súbitos de retransmisiones TCP y churn de rutas/next-hops para prefijos críticos.

Conclusión: pasos prácticos siguientes

El ruteo asimétrico no es espeluznante. Es invisible hasta que lo fuerzas a mostrarse. El truco es dejar de tratar las “caídas aleatorias” como una propiedad del universo y empezar a tratarlas como una propiedad del estado.

Si quieres una red fiable:

Mapea tus límites de estado y asume que son frágiles hasta demostrar lo contrario.
Haz explícita la política de ruteo donde se requiera simetría. No dejes que ECMP y “defaults inteligentes” decidan por ti.
Instrumenta las señales aburridas (drops INVALID, no-session, comportamiento de conntrack) para diagnosticar en minutos.
Prueba cambios con flujos realistas, no solo con pings y health checks.

Una idea guía, atribuida ampliamente en cultura de operaciones, es esta: “La esperanza no es una estrategia” — (idea parafraseada, citada a menudo en contextos de ingeniería/ops). El ruteo asimétrico es donde la esperanza va a morir. Sé explícito. Sé medible. Y cuando el outage llegue, depura un solo flujo como si te hubiera insultado personalmente.