Ubuntu 24.04 «No route to host»: lista de verificación ARP/gateway/ACL que elimina las conjeturas (caso n.º 32)

diciembre 8, 2025 • febrero 3, 2026 • Lectura: 23 min • Views: 4

¿Te fue útil?

“No route to host” es el tipo de error que hace que personas inteligentes hagan cosas tontas—como reiniciar la red en una máquina de producción porque “por lo general lo arregla”.
A veces lo hace. Con frecuencia solo añade un segundo incidente encima del primero.

En Ubuntu 24.04, este mensaje normalmente significa que el kernel no pudo averiguar cómo enviar paquetes al destino en absoluto, o que lo intentó y recibió un fallo duro de vuelta (a menudo por ARP o enrutamiento).
Esta guía es la lista de verificación que desearía que todos usaran: ARP, gateway, rutas, VLANs, ACLs y el puñado de comandos que acaban con las conjeturas rápidamente.

Qué significa realmente “No route to host” en Linux

En Linux, “No route to host” típicamente se corresponde con un error como EHOSTUNREACH o ENETUNREACH. No es que una aplicación esté dramatizando; es el kernel diciendo:
“No puedo entregar este paquete, y tengo una razón específica que no es ‘timeout’.”

Lo complicado es que múltiples modos de fallo pueden manifestarse como el mismo error visible al usuario:

No hay una ruta coincidente en la tabla de enrutamiento (sin ruta por defecto, ruta de prefijo errónea, VRF/tabla equivocada).
Fallo en la resolución de vecino (ARP para IPv4, NDP para IPv6): la ruta existe, pero no puedes encontrar la dirección MAC del siguiente salto.
ICMP unreachable inmediato devuelto por un router, firewall o host (bloqueo basado en políticas que elige “unreachable” en lugar de “drop”).
La política local dice “no” (nftables, enrutamiento por políticas, rp_filter o una ruta de host apuntando al vacío).

Implicación práctica: si tratas cada “No route to host” como “el enrutamiento está mal”, perderás tiempo. A veces el enrutamiento está bien; el gateway está vivo; simplemente no obtienes respuestas ARP porque la VLAN está mal o un control de seguridad te separa silenciosamente del siguiente salto.

Una cita que mantengo para incidentes como este: idea parafraseada de W. Edwards Deming: “Sin datos, eres solo otra persona con una opinión.”
Esta lista de verificación es orientada a datos: ejecuta un comando, lee la salida, toma una decisión.

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

Quieres la ruta más rápida hacia el cuello de botella. No la más elegante. No la que haga más feliz al equipo de red. La más rápida.

Primero: demostrar la intención de enrutamiento local (¿sabemos a dónde enviar paquetes?)

Comprueba la ruta que el kernel usaría: ip route get <dest>
Confirma que tienes una ruta por defecto si el destino está fuera de la subred.
Confirma que la selección de dirección fuente coincide con lo que crees (hosts multi-homed adoran las sorpresas).

Segundo: demostrar la adyacencia L2 hacia tu siguiente salto (¿podemos ARP al gateway?)

Pingeá al gateway por defecto (o al menos intenta ARP): revisa el estado con ip neigh.
Si ARP está atascado en INCOMPLETE/FAILED, no estás alcanzando tu gateway en Capa 2. Deja de culpar a las rutas.

Tercero: demostrar que la política no te está bloqueando (ACL/firewall/grupo de seguridad/RPF)

Revisa reglas locales nftables/ufw.
Captura en la interfaz de salida: ¿salen solicitudes ARP? ¿Llegan respuestas?
Si los paquetes salen y no vuelven, es aguas arriba (switch/VLAN/ACL) o el propio gateway.

Broma #1: La forma más rápida de “arreglar” un problema de red es reiniciar algo—hasta que descubres que reiniciaste la única caja con los logs.

Hechos y contexto interesantes (porque los sistemas tienen historia)

ARP es anterior al boom moderno de Internet. Fue especificado en 1982 (RFC 826). Seguimos depurando el mismo mecanismo básico en 2025.
Los estados de vecino en Linux son una máquina de estados finita. Esos REACHABLE, STALE, DELAY, PROBE, FAILED no son adorno; son pistas del comportamiento del kernel.
ICMP “host unreachable” a veces es una cortesía. Muchos firewalls descartan silenciosamente; algunos rechazan explícitamente con ICMP, lo que hace que “No route to host” aparezca instantáneamente en lugar de expirar.
Reverse path filtering (rp_filter) es anterior a la mayoría de las VPC en la nube. Existe para reducir spoofing, pero todavía rompe el enrutamiento asimétrico en sistemas reales.
El stack de red de Ubuntu cambió culturalmente más que técnicamente. Netplan (YAML → renderer) hizo la gestión de configuración más amigable, pero también añadió una capa donde “parece correcto” puede renderizarse mal.
“No route to host” no es lo mismo que “Connection timed out”. “No route” suele significar un fallo duro inmediato; “timeout” suele significar que los paquetes desaparecen (drop/blackhole).
El ARP gratuito (gratuitous ARP) existe para reducir tiempos de inactividad. Los hosts anuncian “esta IP está en esta MAC” para actualizar cachés—útil en failover, peligroso en mala configuración.
El enrutamiento por políticas existe en Linux desde hace décadas. Múltiples tablas de enrutamiento + reglas son poderosas, y también una forma fiable de crear fallos de conectividad invisibles.

Un modelo mental: L2 vs L3 vs políticas

Cuando Ubuntu dice “No route to host”, debes categorizar inmediatamente la falla. No por intuiciones—por capas y las decisiones que toma el kernel.

Capa 3: “¿Qué siguiente salto?”

El kernel consulta tablas de enrutamiento (posiblemente múltiples vía reglas de política). Si no puede encontrar una ruta, obtienes un error rápido. Si encuentra una ruta, elige:
prefijo de destino → siguiente salto (gateway u on-link) → interfaz de salida → IP de origen.

Capa 2: “¿Qué dirección MAC?”

Si el siguiente salto está on-link (incluido tu gateway por defecto), Linux debe resolver la dirección MAC vía ARP (IPv4) o NDP (IPv6).
Si ARP falla, el enrutamiento puede ser perfecto y aún así no alcanzarás nada. Por eso la gente que dice “la ruta se ve bien” pierde las discusiones en incidentes.

Política y controles de seguridad: “¿Se permite?”

El paquete puede ser bloqueado localmente (nftables/ufw), rechazado aguas arriba (ACL, security group, firewall), o descartado por controles anti-spoof (rp_filter).
Estas fallas pueden presentarse como unreachable inmediato o como silencio. “No route to host” a menudo significa un reject explícito en alguna parte.

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

Estas son las tareas que ejecuto en producción. Cada una incluye: comando, qué significa la salida y la decisión que tomas a continuación.
Ejecútalas en orden si quieres una narrativa limpia, o salta si ya sospechas una capa.

Task 1: Reproducir el fallo con una herramienta determinista

cr0x@server:~$ nc -vz -w 3 10.40.12.50 22
nc: connect to 10.40.12.50 port 22 (tcp) failed: No route to host

Significado: Esto es un error a nivel kernel, no un capricho del cliente SSH. Si ves “No route to host” aquí, puedes dejar de ajustar configuraciones de SSH.

Decisión: Pasa a la selección de ruta (ip route get) y comprobaciones de vecino.

Task 2: Preguntar al kernel qué ruta usaría

cr0x@server:~$ ip route get 10.40.12.50
10.40.12.50 via 10.40.12.1 dev ens192 src 10.40.12.20 uid 1000
    cache

Significado: Linux cree que debe enviar tráfico al gateway 10.40.12.1 mediante ens192, usando la IP de origen 10.40.12.20.

Decisión: Si esto es incorrecto (gateway equivocado, interfaz equivocada, origen equivocado), corrige enrutamiento/netplan. Si está bien, prueba el siguiente salto con ARP/ping.

Task 3: Confirmar que realmente tienes las rutas esperadas

cr0x@server:~$ ip route show
default via 10.40.12.1 dev ens192 proto dhcp src 10.40.12.20 metric 100
10.40.12.0/24 dev ens192 proto kernel scope link src 10.40.12.20 metric 100

Significado: Existe ruta por defecto. Existe ruta de subred. Esto no es “no hay ruta en la tabla.”

Decisión: Baja en la pila hasta ARP/resolución de vecino para 10.40.12.1.

Task 4: Comprobar estado del enlace y portadora (no lo saltes)

cr0x@server:~$ ip link show ens192
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:aa:bb:cc brd ff:ff:ff:ff:ff:ff

Significado: LOWER_UP indica que la NIC tiene carrier. Si es NO-CARRIER o el estado es DOWN, tu problema es a nivel de enlace físico/virtual.

Decisión: Si no está LOWER_UP, detente y arregla el enlace (vSwitch port group, cable, bond, driver). Si lo está, continúa.

Task 5: Comprobar la entrada vecino (ARP) para tu gateway

cr0x@server:~$ ip neigh show dev ens192
10.40.12.1 INCOMPLETE
10.40.12.77 lladdr 00:25:90:12:34:56 STALE

Significado: INCOMPLETE para el gateway significa que se intentaron solicitudes ARP pero no se aprendió respuesta. Esto es una gran pista.

Decisión: Esto probablemente sea mismatch de VLAN, aislamiento de puerto en el switch, ACL upstream, máscara de subred equivocada o gateway caído. Valida el tráfico ARP con tcpdump.

Task 6: Forzar actividad ARP haciendo ping al gateway

cr0x@server:~$ ping -c 2 -W 1 10.40.12.1
PING 10.40.12.1 (10.40.12.1) 56(84) bytes of data.

--- 10.40.12.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1010ms

Significado: El ping no obtuvo respuestas. Eso por sí solo no prueba fallo de ARP—ICMP podría estar bloqueado—pero combinado con el estado INCOMPLETE del vecino, es evidencia contundente.

Decisión: Haz una captura de ARP. Si no ves respuestas, deja de asumir “enrutamiento.” Esto es adyacencia.

Task 7: Capturar ARP en la interfaz de salida

cr0x@server:~$ sudo tcpdump -ni ens192 arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:41:05.112233 ARP, Request who-has 10.40.12.1 tell 10.40.12.20, length 28
12:41:06.113244 ARP, Request who-has 10.40.12.1 tell 10.40.12.20, length 28

Significado: Las solicitudes salen del host. No llegan respuestas. Eso no es un problema de firewall local; ARP no se filtra por nftables en las cadenas IP habituales.

Decisión: Escala a switching/VLAN/portgroup/VRF/salud del gateway. Si sí ves una respuesta, tu host debería aprenderla; entonces busca rp_filter, enrutamiento por políticas o ACLs upstream.

Task 8: Verificar que la dirección IP y el prefijo sean los esperados

cr0x@server:~$ ip -br addr show ens192
ens192           UP             10.40.12.20/24 fe80::250:56ff:feaa:bbcc/64

Significado: Estás configurado con /24. Si la red realmente es /25 o /23, puede que estés haciendo ARP por algo que no está on-link o falte una ruta on-link al gateway.

Decisión: Si sospechas desajuste de prefijo, confirma con diseño de red/fuente de verdad y corrige netplan o el ámbito DHCP. No “pruebes /16 para ver si funciona.” Así creas un segundo incidente.

Task 9: Comprobar reglas de enrutamiento por políticas (el saboteador silencioso)

cr0x@server:~$ ip rule show
0:      from all lookup local
1000:   from 10.40.12.20 lookup 100
32766:  from all lookup main
32767:  from all lookup default

Significado: El tráfico originado desde 10.40.12.20 usa la tabla de enrutamiento 100. Si la tabla 100 carece de rutas, puedes obtener “no route” a pesar de una tabla main perfecta.

Decisión: Inspecciona la tabla 100. Si está mal, arregla la regla o popula rutas correctamente.

Task 10: Inspeccionar la tabla de enrutamiento alternativa (si existen reglas)

cr0x@server:~$ ip route show table 100
default via 10.40.12.254 dev ens192

Significado: La tabla 100 envía el tráfico por defecto a 10.40.12.254. Si tu gateway real es 10.40.12.1, has encontrado una mala ruta. Si .254 no existe, ARP fallará y verás comportamiento unreachable.

Decisión: Arregla la regla de enrutamiento por políticas o la ruta por defecto de la tabla. Luego vuelve a probar ip route get y ip neigh.

Task 11: Comprobar filtro de ruta inversa (rp_filter) por rutas asimétricas

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

Significado: rp_filter=1 es “estricto.” En entornos multi-homed o con enrutamiento asimétrico, RPF estricto puede descartar respuestas y producir inalcanzables/tiempos de espera confusos.

Decisión: Si tienes enrutamiento asimétrico por diseño, considera rp_filter=2 (loose) o un cambio de arquitectura. No lo desactives globalmente a menos que te guste tener modelos de amenaza que no puedes explicar.

Task 12: Revisar firewall local (nftables/ufw) por rejects

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
        }
        chain forward {
                type filter hook forward priority filter; policy accept;
        }
        chain output {
                type filter hook output priority filter; policy accept;
        }
}

Significado: Este host no está bloqueando nada con nftables. Si ves reject with icmpx type host-unreachable, eso puede explicar un “No route to host” inmediato.

Decisión: Si la cadena de salida rechaza tráfico hacia el destino o subred, corrige las reglas. Si el ruleset está vacío/accept, busca aguas arriba.

Task 13: Verificar estado de UFW (porque siempre alguien lo activó “temporalmente”)

cr0x@server:~$ sudo ufw status verbose
Status: inactive

Significado: UFW no está participando. Si está activo, comprueba denegaciones de salida o bloqueos de rutas (menos comunes, pero reales).

Decisión: Si UFW está activo y es sospechoso, ajusta la política o permite temporalmente para diagnóstico—documenta el cambio y revierte.

Task 14: Buscar entrada ARP obsoleta/incorrecta (raro, pero rápido)

cr0x@server:~$ ip neigh show 10.40.12.1
10.40.12.1 lladdr 00:11:22:33:44:55 STALE

Significado: Tienes una MAC para el gateway. Si es incorrecta (failover del gateway, movimiento VRRP), puedes temporalmente hacer blackhole del tráfico.

Decisión: Vacía la entrada y vuelve a aprender. Si se relearn immediatamente la misma MAC y aún falla, el problema está más allá de tu host.

cr0x@server:~$ sudo ip neigh flush 10.40.12.1 dev ens192
10.40.12.1 dev ens192 flushed

Task 15: Validar la configuración renderizada por netplan (realidad Ubuntu 24.04)

cr0x@server:~$ sudo netplan get
network:
  version: 2
  ethernets:
    ens192:
      dhcp4: true

Significado: Netplan está usando DHCP aquí. Si esperas rutas/ gateway estáticos, o no estás aplicando la configuración correcta o DHCP está sobreescribiendo tu intención.

Decisión: Confirma el YAML de netplan en /etc/netplan/, luego netplan try (con cuidado) o coordina una ventana de mantenimiento para cambios disruptivos.

Task 16: Comprobar systemd-networkd o NetworkManager según el renderer

cr0x@server:~$ networkctl status ens192
● 2: ens192
                     Link File: /usr/lib/systemd/network/99-default.link
                  Network File: /run/systemd/network/10-netplan-ens192.network
                          State: routable (configured)
                   Online state: online
                          Address: 10.40.12.20
                                   fe80::250:56ff:feaa:bbcc
                          Gateway: 10.40.12.1

Significado: El renderer cree que eres enrutable y tiene un gateway. Eso no prueba que ARP funcione, pero sí prueba que la configuración está presente.

Decisión: Si networkctl no muestra gateway, arregla la configuración. Si muestra gateway pero ARP falla, investiga L2/ACL aguas arriba.

Task 17: Rastrear la ruta y ver dónde aparece “unreachable”

cr0x@server:~$ tracepath -n 10.40.12.50
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.40.12.1                                            0.314ms
 2:  no reply
 3:  no reply
     Too many hops: pmtu 1500

Significado: Puedes alcanzar el salto 1 (gateway). Si tu ARP anterior estuviera fallando, esto no sucedería. Así que ahora estás más allá de L2.

Decisión: Si el salto 1 es alcanzable pero el destino no, investiga enrutamiento/ACL más allá del primer salto: reglas de firewall, ACLs inter-VLAN, security groups o rutas de retorno faltantes.

Task 18: Capturar ICMP unreachable para probar un reject por ACL

cr0x@server:~$ sudo tcpdump -ni ens192 icmp or icmp6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:55:22.443322 IP 10.40.12.1 > 10.40.12.20: ICMP host 10.40.12.50 unreachable, length 68

Significado: El gateway te está diciendo explícitamente que el host es inalcanzable. Eso no es que tu máquina Ubuntu esté confundida. Es una decisión de enrutamiento/ACL aguas arriba.

Decisión: Escala con evidencia: incluye marca temporal, tipo/código ICMP y la IP del router que lo envió. Pregunta: ¿hay una ruta a 10.40.12.50? ¿Hay una ACL bloqueando?

Broma #2: ARP es como el chisme de oficina—si nadie responde, no significa que estés equivocado; significa que estás hablando con la sala equivocada.

Tres mini-historias corporativas desde el frente

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

Una empresa mediana tenía una separación clara entre redes “apps” y “databases”. Se desplegó una nueva VM Ubuntu 24.04 en la subred de apps.
El ingeniero supuso “el gateway por defecto puede enrutar a todo lo interno”, porque así funcionaba el entorno anterior.

La nueva VM lanzó “No route to host” al conectarse a una base de datos. La tabla de rutas se veía bien. La ruta por defecto estaba presente. El equipo pasó una hora debatiendo la sintaxis de netplan y si systemd-networkd tenía un bug.
Mientras tanto, el equipo de base de datos insistía en que nada había cambiado.

El avance vino de tcpdump: un ICMP “host unreachable” devuelto instantáneamente desde el gateway. Eso significaba que esto no era un drop silencioso, y no era local.
El gateway estaba rechazando activamente el reenvío.

La suposición equivocada: el enrutamiento interno era universal. En realidad, el equipo de red había implementado ACLs inter-VLAN meses antes, permitiendo solo subredes de apps específicas alcanzar la VLAN de la base de datos.
Esta VM cayó en una VLAN de “apps generales” que no estaba en la lista permitida.

La solución fue aburrida: actualizar la ACL para permitir la subred y puertos correctos, y ajustar el workflow de aprovisionamiento para que las VMs dirigidas a la base de datos se coloquen en el segmento correcto.
La lección clave: “existe ruta por defecto” no significa “la política lo permite.”

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

Otra organización quería failover más rápido para un par de routers que hacían redundancia de primer salto.
Ajustaron temporizadores ARP y de vecino en servidores “para acelerar la convergencia”, y también redujeron ciertos reintentos/comportamientos de backoff.

Funcionó en laboratorio. En producción, creó una tormenta intermitente: durante un failover de gateway, algunos hosts Linux marcarían la entrada de vecino como FAILED con rapidez,
y luego se negarían a hablar con el gateway hasta la siguiente ventana de resolución. Los clientes vieron ráfagas de “No route to host”, que es una gran forma de empezar una discusión entre SRE y Network Engineering.

Las capturas mostraron solicitudes ARP saliendo durante el failover, pero las respuestas llegaban un latido después—tarde como para perder el umbral de paciencia recién acortado.
La “optimización” recortó milisegundos del camino feliz y añadió segundos al camino infeliz.

El rollback fue inmediato. Luego hicieron la optimización correcta: mejorar la señalización de failover del gateway (gratuitous ARP/ND), validar el comportamiento del switch y probar con latencia/jitter realistas.
Deja los temporizadores de vecino cerca de los valores por defecto a menos que puedas modelar las consecuencias y estés dispuesto a hacerte responsable.

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

Una firma de servicios financieros tenía una regla poco glamorosa: cada reporte de incidente debía incluir ip route get, ip neigh y un fragmento de tcpdump de 30 segundos.
El equipo se quejaba. Parecía papeleo. Hasta que dejó de serlo.

Una tarde, múltiples nodos Ubuntu 24.04 empezaron a fallar al alcanzar una API interna con “No route to host.” El on-call sacó el paquete de triage estándar.
Las rutas eran correctas. Los gateways eran alcanzables. Pero tcpdump mostró mensajes ICMP host-unreachable provenientes de un VIP de firewall.

Eso lo estrechó inmediatamente: el dispositivo aguas arriba estaba rechazando, no descartando. El equipo de firewall pudo buscar en logs por el VIP y la marca temporal.
Resultó que una plantilla de ACL recién desplegada tenía un “deny any any” colocado por encima de un allow específico, pero solo para un par de zonas.

La solución tomó minutos una vez presentada la evidencia adecuada. La práctica aburrida—artefactos de diagnóstico consistentes—evitó una espiral de culpas de varias horas.
Nadie tuvo que “probar un reinicio.” Nadie tuvo que tocar netplan. El incidente se mantuvo como un único incidente.

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

Esta sección es directa a propósito. Estas son las trampas que mantienen vivo “No route to host” mucho después de que debería estar muerto.

1) Síntoma: “No route to host” hacia cualquier destino fuera de la subred

Causa raíz: Falta de ruta por defecto o gateway equivocado.

Solución: Verifica ip route. Arregla netplan o DHCP. Confirma con ip route get 8.8.8.8 (o una IP interna fuera de subred).

2) Síntoma: La ruta existe, pero el gateway está `INCOMPLETE` en `ip neigh`

Causa raíz: Respuestas ARP que no llegan al host: VLAN equivocada, etiquetado erróneo del puerto del switch, port security, gateway caído o aislamiento L2.

Solución: tcpdump -ni <if> arp. Si las solicitudes salen pero no hay respuestas, escala al equipo L2/red con evidencia. Valida portgroup/VLAN de la VM.

3) Síntoma: “No route to host” inmediato pero ARP está bien y el gateway responde

Causa raíz: Dispositivo aguas arriba está enviando ICMP unreachable (reject de ACL, ruta faltante al destino o enrutamiento por políticas en el gateway).

Solución: Captura ICMP con tcpdump. Identifica la IP emisora (a menudo gateway/firewall). Arregla ACL/ruta aguas arriba.

4) Síntoma: Solo una IP de origen falla en un host con múltiples IPs

Causa raíz: Una regla de enrutamiento por políticas envía esa fuente a una tabla de enrutamiento vacía/incorrecta.

Solución: ip rule show y ip route show table X. Alinea reglas con el egress/gateway previsto.

5) Síntoma: Funciona en una dirección, falla en la otra; errores varían entre timeout y unreachable

Causa raíz: Enrutamiento asimétrico combinado con RPF estricto en un lado.

Solución: Revisa rp_filter y controles anti-spoof aguas arriba. Usa modo loose donde esté justificado, o arregla la simetría de enrutamiento.

6) Síntoma: Tras un failover del gateway, algunos hosts obtienen “No route to host” durante minutos

Causa raíz: Caché de vecinos obsoleta + anuncios gratuitous ARP/ND tardíos, o ajuste agresivo de temporizadores.

Solución: Asegura que el gateway envíe gratuitous ARP/ND en failover. Considera vaciar entradas de vecino en hosts impactados solo como último recurso.

7) Síntoma: Solo puertos específicos muestran “No route to host” (no “connection refused”)

Causa raíz: Un firewall está rechazando con ICMP unreachable ciertos puertos/flows, o un middlebox clasifica el tráfico.

Solución: Tcpdump para ICMP unreachables durante el intento fallido de conexión. Confirma con el equipo de red/seguridad; ajusta la política ACL.

8) Síntoma: Destino IPv6 falla con “No route to host”, IPv4 funciona

Causa raíz: Falta ruta por defecto IPv6 o fallo de NDP; RA deshabilitado; firewall bloquea ICMPv6 (lo que rompe IPv6 de formas no obvias).

Solución: Usa ip -6 route y ip -6 neigh. Asegura que ICMPv6 esté permitido adecuadamente; confirma anuncios del router si se usan.

Listas de verificación / plan paso a paso

Esta es la sección “hazlo cada vez”. Imprímela. Ponla en tu runbook de incidentes. Haz que alguien se encargue de evitar que la sala depure a la deriva.

Checklist A: Sanidad del host local (Ubuntu 24.04)

Confirma que la interfaz esté arriba y tenga carrier.
Usa ip link show. Si no hay carrier, arregla la conectividad virtual/física antes de cualquier otra cosa.
Confirma direccionamiento y prefijo.
Usa ip -br addr. Si el prefijo está mal, rutas y comportamiento ARP te mentirán.
Confirma la ruta por defecto y la ruta específica.
Usa ip route show y ip route get <dest>.
Revisa enrutamiento por políticas.
Usa ip rule show. Si existen reglas no por defecto, inspecciona esas tablas.
Comprueba la entrada vecino para el siguiente salto (gateway).
Usa ip neigh show. INCOMPLETE es tu gran flecha roja.
Revisa el firewall local por rejects.
Usa nft list ruleset y ufw status.
Captura tráfico durante 30 segundos.
Usa tcpdump para ARP e ICMP. Esto es tu evidencia y tu brújula.

Checklist B: ¿Es L2, L3 o política? árbol de decisiones

Si ip route get falla (sin ruta): arregla enrutamiento/gateway por defecto/enrutamiento por políticas.
Si la ruta existe pero ARP del gateway está INCOMPLETE: es adyacencia (VLAN/etiquetado/switch/gateway caído).
Si ARP del gateway se resuelve y el gateway responde pero el destino falla:
revisa enrutamiento/ACLs upstream. Captura ICMP unreachables.
Si nada responde y nadie rechaza (timeouts): busca drops (ACL drop, security group drop, MTU blackhole, firewall upstream que descarta).

Checklist C: Paquete de escalamiento (qué enviar al equipo de red/seguridad)

Si necesitas otro equipo, no envíes “no funciona.” Envía un paquete ajustado:

ip route get <dest> salida (muestra siguiente salto, interfaz, IP de origen)
ip route show y ip rule show (prueban intención local)
ip neigh show para el gateway y el destino (muestra estado ARP)
30 segundos de tcpdump mostrando solicitudes/respuestas ARP y/o ICMP unreachables (muestra quién rechaza)
Marca temporal exacta y destino/puerto (para correlacionar logs)

Preguntas frecuentes

1) ¿Por qué obtengo “No route to host” cuando la tabla de rutas parece correcta?

Porque el enrutamiento es solo el primer paso. Linux puede conocer el siguiente salto pero aún así fallar ARP/NDP para ese siguiente salto.
Revisa ip neigh para el gateway; INCOMPLETE o FAILED significa que no tienes reachability de Capa 2 hacia el siguiente salto.

2) ¿Cuál es el comando único más rápido para empezar?

ip route get <dest>. Te dice interfaz, gateway e IP de origen elegida. Si esa salida te sorprende, has encontrado la categoría del problema.

3) ¿Cómo puede una ACL causar “No route to host” en lugar de un timeout?

Algunas ACLs/firewalls están configurados para rechazar en lugar de descartar. Reject puede generar ICMP “host unreachable” (o similar),
que tu kernel muestra como “No route to host” de inmediato. Captura ICMP con tcpdump para probarlo.

4) ¿Es “No route to host” lo mismo que “Destination Host Unreachable” de ping?

Están relacionados pero no son idénticos. “Destination Host Unreachable” es la interpretación de ping de ICMP unreachable o fallo de enrutamiento local.
“No route to host” es un error de socket que ven las aplicaciones. Ambos suelen apuntar a inalcanzabilidad en L2/L3, pero aún debes localizar dónde se genera el unreachable.

5) ¿Por qué falla solo para una IP de destino, no para toda la subred?

Causas comunes: una ruta específica faltante aguas arriba, una ACL que apunta a ese host, el host destino caído, o conflicto/duplicado de ARP para esa IP.
Usa tracepath y tcpdump para ICMP unreachables y así identificar el salto que rechaza.

6) ¿Cómo afecta netplan de Ubuntu 24.04 a esto?

Netplan es la capa de configuración; el kernel toma las decisiones de forwarding. Errores en netplan se traducen en direcciones erróneas, rutas equivocadas, gateways equivocados o renderer incorrecto.
Verifica con netplan get y networkctl status (o herramientas de NetworkManager si ese es tu renderer).

7) ¿Puede DNS causar “No route to host”?

DNS puede hacer que te conectes a la IP equivocada, pero el error sigue siendo sobre alcanzar esa IP. Si sospechas DNS, resuelve el nombre a una dirección,
luego ejecuta ip route get para esa dirección y procede normalmente.

8) ¿Qué pasa si ARP funciona para el gateway, pero las conexiones siguen diciendo “No route to host”?

Entonces lo inalcanzable probablemente se genera aguas arriba (gateway/firewall) o localmente por enrutamiento por políticas o rejects del firewall.
Captura ICMP en el host durante un intento fallido; si ves ICMP unreachable desde un router/firewall, ya tienes al culpable.

9) ¿Cómo diferencio rápidamente “drop” vs “reject”?

Un reject suele fallar de inmediato y puede mostrar ICMP unreachable en tcpdump. Un drop normalmente expira. No es perfecto, pero es una heurística sólida.
Confirma siempre con una captura en la interfaz de salida.

10) ¿Debo vaciar la caché ARP como solución?

Como empujón diagnóstico, a veces. Como hábito, no. Vaciar entradas de vecino puede enmascarar un problema sistémico (mala señalización de failover, etiquetado VLAN erróneo, IPs duplicadas).
Úsalo para confirmar comportamiento, luego arregla la causa subyacente.

Conclusión: siguientes pasos para evitar repeticiones

“No route to host” no es un acertijo. Es una petición: muéstrame la decisión de ruta, muéstrame el estado de vecino, muéstrame el resultado de la política.
Haz esas tres cosas y el problema suele dejar de ser misterioso en minutos.

Siguientes pasos prácticos:

Estandariza tu paquete de triage: ip route get, ip neigh, ip rule y un breve tcpdump.
Enseña al equipo a tratar las entradas de vecino INCOMPLETE como “detente y revisa VLAN/gateway”, no como “prueba otra ruta”.
Documenta qué subredes pueden hablar con qué servicios. “Rutable implícitamente” es un mito en redes segmentadas.
En la gestión de cambios, exige prueba de conectividad desde al menos un host en cada segmento después de actualizaciones de ACL/enrutamiento.