Ubuntu 24.04 « No route to host » : checklist ARP/passarelle/ACL qui met fin aux conjectures (cas n°32)

décembre 8, 2025 • février 3, 2026 • Lecture : 25 min • Views: 8

Cet article vous a aidé ?

« No route to host » est le type d’erreur qui pousse les gens intelligents à faire des choses stupides — comme redémarrer le réseau sur une machine de production parce que « ça marche généralement ».
Parfois ça marche. Souvent, cela ajoute juste un second incident au premier.

Sur Ubuntu 24.04, ce message signifie généralement que le noyau n’a pas su déterminer comment livrer les paquets à la destination du tout, ou qu’il a essayé et reçu un échec franc en retour (souvent lié à ARP ou au routage).
Ce guide est la checklist que j’aimerais que tout le monde utilise : ARP, passerelle, routes, VLAN, ACL, et la poignée de commandes qui arrêtent rapidement les conjectures.

Ce que « No route to host » signifie réellement sous Linux

Sous Linux, « No route to host » correspond généralement à une erreur comme EHOSTUNREACH ou ENETUNREACH. Ce n’est pas une application qui dramatise ; c’est le noyau qui dit :
« Je ne peux pas livrer ce paquet, et j’ai une raison précise qui n’est pas un ‘timeout’. »

La partie délicate est que plusieurs modes de défaillance peuvent se manifester par la même erreur visible pour l’utilisateur :

Pas de route correspondante dans la table de routage (pas de route par défaut, route de préfixe erronée, mauvais VRF/table).
Échec de résolution du voisin (ARP pour IPv4, NDP pour IPv6) — la route existe, mais vous ne trouvez pas l’adresse MAC du next-hop.
ICMP unreachable immédiat renvoyé par un routeur, un pare-feu ou un hôte (blocage par politique qui choisit « unreachable » au lieu de « drop »).
La politique locale dit « ne pas » (nftables, policy routing, rp_filter, ou une route locale pointant vers le vide).

Implication pratique : si vous traitez chaque « No route to host » comme un problème de routage, vous perdrez du temps. Parfois le routage est correct ; la passerelle est vivante ; c’est juste que vous ne recevez pas de réponses ARP parce qu’un VLAN est mal configuré ou qu’un contrôle de sécurité vous sépare silencieusement du next-hop.

Une citation que je garde pour ce genre d’incident : idée paraphrasée de W. Edwards Deming : « Sans données, vous n’êtes qu’une autre personne avec une opinion. »
Cette checklist est axée sur les données : lancez une commande, lisez la sortie, prenez une décision.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Vous voulez le chemin le plus rapide vers le goulot d’étranglement. Pas le plus élégant. Pas celui qui rendra l’équipe réseau la plus heureuse. Le plus rapide.

Premier : prouver l’intention de routage locale (savons-nous où envoyer les paquets ?)

Vérifier la route que le noyau utilisera : ip route get <dest>
Confirmer que vous avez une route par défaut si la destination est hors sous‑réseau.
Confirmer que la sélection d’adresse source correspond à ce que vous pensez (les hôtes multi‑homés aiment les surprises).

Deuxième : prouver l’adjacence L2 vers votre next-hop (pouvons‑nous ARP pour la passerelle ?)

Pinger la passerelle par défaut (ou au moins tenter ARP) : vérifier l’état avec ip neigh.
Si ARP est bloqué en INCOMPLETE/FAILED, vous n’atteignez pas votre passerelle au niveau L2. Arrêtez de blâmer les routes.

Troisième : prouver que la politique ne vous bloque pas (ACL/pare‑feu/groupe de sécurité/RPF)

Vérifier les règles locales nftables/ufw.
Capturer sur l’interface egress : les requêtes ARP sortent‑elles ? Les réponses arrivent‑elles ?
Si les paquets sortent et ne reviennent jamais, c’est en amont (switch/VLAN/ACL) ou la passerelle elle‑même.

Blague n°1 : Le moyen le plus rapide de « réparer » un problème réseau est de redémarrer quelque chose — jusqu’à ce que vous découvriez que vous avez redémarré la seule machine qui contenait les logs.

Faits intéressants et contexte (parce que les systèmes ont de l’histoire)

ARP est antérieur à l’explosion moderne d’Internet. Il a été spécifié en 1982 (RFC 826). Nous déboguons toujours le même mécanisme de base en 2025.
Les états voisins Linux forment une machine à états finis. Ces étiquettes REACHABLE, STALE, DELAY, PROBE, FAILED ne sont pas décoratives ; ce sont des indices de comportement du noyau.
ICMP « host unreachable » est parfois une courtoisie. Beaucoup de pare‑feu laissent tomber silencieusement ; certains rejettent explicitement avec ICMP, ce qui fait apparaître « No route to host » instantanément au lieu d’un timeout.
Le filtrage par chemin inverse (rp_filter) est plus ancien que la plupart des VPC cloud. Il existe pour réduire l’usurpation, mais il casse encore le routage asymétrique dans des systèmes réels.
La pile réseau d’Ubuntu a changé culturellement plus que techniquement. Netplan (YAML → renderer) a rendu la gestion des configs plus conviviale, mais a aussi ajouté une couche où « a l’air correct » peut rendre quelque chose de faux.
« No route to host » n’est pas la même chose que « Connection timed out ». « No route » signifie généralement un échec franc immédiat ; « timeout » signifie souvent que les paquets disparaissent (drop/blackhole).
L’ARP gratuit existe pour réduire les temps d’indisponibilité. Les hôtes annoncent « cette IP est à cette MAC » pour actualiser les caches — utile lors d’un basculement, dangereux en cas de mauvaise config.
Le policy routing existe dans Linux depuis des décennies. Plusieurs tables de routage + règles sont puissantes, et aussi un moyen fiable de créer des pannes de connectivité invisibles.

Modèle mental : L2 vs L3 vs politique

Quand Ubuntu dit « No route to host », vous devez immédiatement catégoriser la défaillance. Pas selon des impressions — selon les couches et les décisions que prend le noyau.

Couche 3 : « Quel next hop ? »

Le noyau consulte les tables de routage (éventuellement multiples via des règles de politique). S’il ne trouve pas de route, vous obtenez une erreur rapide. S’il trouve une route, il choisit :
préfixe de destination → next-hop (passerelle ou on-link) → interface de sortie → IP source.

Couche 2 : « Quelle adresse MAC ? »

Si le next hop est on‑link (y compris votre passerelle par défaut), Linux doit résoudre l’adresse MAC via ARP (IPv4) ou NDP (IPv6).
Si ARP échoue, le routage peut être parfait et vous n’atteindrez rien. Voilà pourquoi les partisans du « la route a l’air correcte » perdent les débats en incident.

Politique et contrôles de sécurité : « Avons‑nous le droit ? »

Le paquet peut être bloqué localement (nftables/ufw), rejeté en amont (ACL, security group, pare‑feu), ou abandonné à cause de contrôles anti‑usurpation (rp_filter).
Ces échecs peuvent se présenter comme un unreachable immédiat ou comme du silence. « No route to host » signifie souvent qu’un rejet explicite a eu lieu quelque part.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute en production. Chacune inclut : la commande, ce que la sortie signifie, et la décision suivante.
Exécutez‑les dans l’ordre si vous voulez un récit propre, ou sautez des étapes si vous suspectez déjà une couche particulière.

Task 1: Reproduce the failure with a deterministic tool

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

Signification : Il s’agit d’une erreur au niveau noyau, pas d’un caprice du client SSH. Si vous voyez « No route to host » ici, arrêtez de bidouiller les configs SSH.

Décision : Passez à la sélection de route (ip route get) et aux vérifications des voisins.

Task 2: Ask the kernel which route it would use

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

Signification : Linux pense qu’il doit envoyer le trafic vers la passerelle 10.40.12.1 via ens192, en utilisant l’IP source 10.40.12.20.

Décision : Si c’est incorrect (mauvaise passerelle, mauvaise interface, mauvaise source), corrigez le routage/netplan. S’il est correct, testez le next hop avec ARP/ping.

Task 3: Confirm you actually have the expected routes

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

Signification : La route par défaut existe. La route de sous‑réseau existe. Ce n’est pas un cas de « pas de route dans la table ».

Décision : Descendez la pile vers la résolution ARP/voisin pour 10.40.12.1.

Task 4: Check link state and carrier (don’t skip this)

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

Signification : LOWER_UP vous indique que la NIC a du carrier. Si c’est NO-CARRIER ou state DOWN, votre problème est au niveau lien physique/virtuel.

Décision : Si pas de LOWER_UP, arrêtez et corrigez le lien (portgroup vSwitch, câble, bond, pilote). Si c’est OK, continuez.

Task 5: Check the neighbor (ARP) entry for your 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

Signification : INCOMPLETE pour la passerelle signifie que des requêtes ARP ont été émises (ou tentées) mais qu’aucune réponse n’a été apprise. C’est un indice majeur.

Décision : C’est probablement un mauvais VLAN, une isolation de port switch, une ACL en amont, un masque de sous‑réseau erroné, ou la passerelle hors service. Validez le trafic ARP avec tcpdump.

Task 6: Force ARP activity by pinging the 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

Signification : Le ping n’a pas reçu de réponses. Cela seul ne prouve pas une défaillance ARP — l’ICMP peut être bloqué — mais combiné avec un voisin INCOMPLETE, c’est un fort indice.

Décision : Capturez ARP. Si vous ne voyez pas de réponses, arrêtez d’assumer « routage ». C’est l’adjacence.

Task 7: Capture ARP on the egress interface

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

Signification : Les requêtes quittent votre hôte. Aucune réponse n’arrive. Ce n’est pas un problème de pare‑feu local ; l’ARP n’est pas filtré par nftables dans les chaînes IP habituelles.

Décision : Escaladez vers switching/VLAN/portgroup/VRF/santé de la passerelle. Si vous voyez une réponse, votre hôte devrait l’apprendre ; alors regardez rp_filter, policy routing, ou les ACL en amont.

Task 8: Verify IP addressing and prefix are what you think

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

Signification : Vous êtes configuré en /24. Si votre réseau est en réalité en /25 ou /23, vous pouvez ARP pour quelque chose qui n’est pas on‑link ou manquer une route on‑link pour la passerelle.

Décision : Si vous suspectez un décalage de préfixe, confirmez avec la conception réseau/source de vérité et corrigez netplan ou le scope DHCP. N’« essayez pas /16 pour voir si ça marche ». C’est ainsi qu’on crée un second incident.

Task 9: Check policy routing rules (the silent saboteur)

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

Signification : Le trafic source 10.40.12.20 utilise la table de routage 100. Si la table 100 manque de routes, vous pouvez avoir « no route » malgré une table main parfaite.

Décision : Inspectez la table 100. Si elle est erronée, corrigez la règle ou populationnez correctement les routes.

Task 10: Inspect the alternate routing table (if rules exist)

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

Signification : La table 100 envoie le trafic par défaut vers 10.40.12.254. Si votre vraie passerelle est 10.40.12.1, vous avez trouvé une mauvaise route. Si .254 n’existe pas, ARP échouera et vous verrez un comportement unreachable.

Décision : Corrigez la règle de policy routing ou la route par défaut de la table. Puis retestez ip route get et ip neigh.

Task 11: Check reverse path filtering (rp_filter) for asymmetric routes

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

Signification : rp_filter=1 est « strict ». Dans des environnements multi‑homés ou de routage asymétrique, le RPF strict peut jeter les réponses et produire des unreachable/timeouts déroutants.

Décision : Si vous avez un routage asymétrique par conception, envisagez rp_filter=2 (mode loose) ou un changement d’architecture. Ne désactivez pas globalement sauf si vous maîtrisez les modèles de menace.

Task 12: Check local firewall (nftables/ufw) for 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;
        }
}

Signification : Cet hôte ne bloque rien avec nftables. Si vous voyez reject with icmpx type host-unreachable, cela peut expliquer le « No route to host » immédiat.

Décision : Si la chaîne output rejette le trafic vers la destination ou le sous‑réseau, corrigez les règles. Si le ruleset est vide/accept, regardez en amont.

Task 13: Verify UFW status (because someone always enabled it “temporarily”)

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

Signification : UFW ne participe pas. Si actif, vérifiez les refus sortants ou les blocs de route (moins courant, mais réel).

Décision : Si UFW est actif et suspect, ajustez la politique ou autorisez temporairement pour le diagnostic — documentez le changement et restaurez ensuite.

Task 14: Check for a stale/wrong ARP entry (rare, but quick)

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

Signification : Vous avez une MAC pour la passerelle. Si elle est incorrecte (basculement de passerelle, mouvement VRRP), vous pouvez brièvement blackholer le trafic.

Décision : Videz l’entrée et réapprenez. Si elle se réapprend immédiatement avec la même MAC et que ça échoue encore, le problème est au‑delà de votre hôte.

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

Task 15: Validate netplan rendered config (Ubuntu 24.04 reality)

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

Signification : Netplan utilise DHCP ici. Si vous attendez des routes/passarelle statiques, soit vous n’appliquez pas la bonne config, soit DHCP écrase votre intention.

Décision : Confirmez le YAML netplan dans /etc/netplan/, puis netplan try (prudemment) ou coordonnez une fenêtre de maintenance pour les changements disruptifs.

Task 16: Check systemd-networkd or NetworkManager depending on 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

Signification : Le renderer considère que vous êtes routable et a une passerelle. Cela ne prouve pas qu’ARP fonctionne, mais cela prouve que la config est présente.

Décision : Si networkctl n’affiche pas de passerelle, corrigez la configuration. S’il affiche une passerelle mais qu’ARP échoue, investiguez sur L2/ACL en amont.

Task 17: Trace the path and see where “unreachable” appears

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

Signification : Vous pouvez atteindre le saut 1 (la passerelle). Si votre ARP échouait auparavant, ceci ne se produirait pas. Vous êtes donc passé au‑delà du L2.

Décision : Si le saut 1 est atteignable mais que la destination ne l’est pas, investiguez le routage/ACL au‑delà du premier saut : règles pare‑feu, ACL inter‑VLAN, security groups, ou routes de retour manquantes.

Task 18: Capture ICMP unreachable to prove an ACL reject

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

Signification : La passerelle vous dit explicitement que l’hôte est unreachable. Ce n’est pas votre machine Ubuntu qui est confuse. C’est une décision de routage/ACL en amont.

Décision : Escaladez avec des preuves : incluez horodatage, type/code ICMP, et l’IP du routeur qui l’a envoyé. Demandez : existe‑t‑il une route pour 10.40.12.50 ? Y a‑t‑il une ACL qui bloque ?

Blague n°2 : L’ARP, c’est comme le commérage au bureau — si personne ne répond, ce n’est pas que vous avez tort ; c’est que vous parlez dans la mauvaise pièce.

Trois mini-histoires d’entreprise tirées du terrain

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait une séparation claire entre les réseaux « apps » et « bases de données ». Une nouvelle VM Ubuntu 24.04 a été déployée dans le sous‑réseau apps.
L’ingénieur a supposé « la passerelle par défaut peut router vers tout », parce que c’est comme cela que fonctionnait l’environnement précédent.

La nouvelle VM a affiché « No route to host » en tentant de se connecter à une base de données. La table de routage semblait correcte. La route par défaut était présente. L’équipe a passé une heure à débattre de la syntaxe netplan et d’un éventuel bug de systemd‑networkd.
Pendant ce temps, l’équipe base de données affirmait que rien n’avait changé.

La percée est venue de tcpdump : un ICMP « host unreachable » renvoyé instantanément par la passerelle. Cela signifiait que ce n’était pas un drop silencieux, et que ce n’était pas local.
La passerelle refusait activement de forwarder.

La mauvaise hypothèse : le routage interne était universel. En réalité, l’équipe réseau avait mis en place des ACL inter‑VLAN quelques mois plus tôt, n’autorisant que certains sous‑réseaux apps à atteindre le VLAN base de données.
Cette VM avait atterri dans un VLAN « apps général » qui n’était pas sur la liste d’autorisation.

La correction fut ennuyeuse : mettre à jour l’ACL pour autoriser le bon sous‑réseau et ajuster le workflow de provisioning pour que les VMs destinées à la base de données soient placées dans le segment correct.
La leçon clé : « route par défaut existe » ne veut pas dire « la politique autorise ».

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation voulait un basculement plus rapide pour une paire de routeurs assurant la redondance du premier saut.
Ils ont ajusté les timers ARP et voisin sur les serveurs « pour accélérer la convergence », et aussi réduit certains comportements de retry/backoff.

Ça a fonctionné en labo. En production, cela a créé une tempête intermittente : pendant un basculement de passerelle, certains hôtes Linux marquaient l’entrée voisin comme FAILED rapidement,
puis refusaient de parler à la passerelle jusqu’à la prochaine fenêtre de résolution. Les clients voyaient des rafales de « No route to host », ce qui est une excellente façon de déclencher un désaccord entre SRE et ingénierie réseau.

Les captures montraient des requêtes ARP sortant pendant le basculement, mais les réponses arrivaient un battement plus tard — trop tard pour le seuil de patience raccourci.
L’« optimisation » a retiré des millisecondes sur le chemin heureux et ajouté des secondes sur le chemin malheureux.

Le rollback fut immédiat. Puis ils ont fait l’optimisation correcte : améliorer le signalement de basculement de la passerelle (gratuitous ARP/ND), valider le comportement des switches, et tester avec de la latence/jitter réalistes.
Laissez les timers voisins proches des valeurs par défaut sauf si vous pouvez modéliser les conséquences et êtes prêts à les assumer.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers avait une règle peu glamour : chaque rapport d’incident doit inclure ip route get, ip neigh, et un extrait tcpdump de 30 secondes.
L’équipe grognait. Ça ressemblait à de la paperasserie. Jusqu’au jour où ça ne l’était plus.

Un après‑midi, plusieurs nœuds Ubuntu 24.04 ont commencé à échouer à joindre une API interne avec « No route to host ». L’astreint a lancé le bundle de triage standard.
Les routes étaient correctes. Les passerelles atteignables. Mais tcpdump montrait des messages ICMP host‑unreachable émis par un VIP de pare‑feu.

Cela a immédiatement réduit le périmètre : l’appareil en amont rejetait, pas dropait. L’équipe pare‑feu a pu chercher dans les logs à partir du VIP et de l’horodatage.
Il s’est avéré qu’un template ACL récemment déployé avait un « deny any any » placé au‑dessus d’un allow spécifique, mais uniquement pour une paire de zones.

La correction a pris quelques minutes une fois que les bonnes preuves ont été fournies. La pratique ennuyeuse — artefacts de diagnostic cohérents — a évité une spirale de blâme de plusieurs heures.
Personne n’a eu à « essayer un reboot ». Personne n’a touché netplan. L’incident est resté un incident.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement directe. Ce sont les pièges qui maintiennent « No route to host » en vie bien après qu’il aurait dû être résolu.

1) Symptom: “No route to host” to anything off-subnet

Cause racine : Route par défaut manquante ou passerelle erronée.

Correction : Vérifiez ip route. Corrigez netplan ou DHCP. Confirmez avec ip route get 8.8.8.8 (ou une IP interne hors‑subnet).

2) Symptom: Route exists, but gateway is `INCOMPLETE` in `ip neigh`

Cause racine : Les réponses ARP n’atteignent pas l’hôte : VLAN erroné, tag de port switch incorrect, port security, passerelle down, ou isolation L2.

Correction : tcpdump -ni <if> arp. Si les requêtes sortent mais pas de réponses, escaladez vers l’équipe L2/réseau avec preuve. Validez le portgroup/VLAN de la VM.

3) Symptom: Immediate “No route to host” but ARP is fine and gateway pings

Cause racine : Un dispositif en amont envoie ICMP unreachable (reject ACL, route manquante vers la destination, ou policy routing sur la passerelle).

Correction : Capturez ICMP avec tcpdump. Identifiez l’émetteur (souvent la passerelle/pare‑feu). Corrigez l’ACL/route en amont.

4) Symptom: Only one source IP fails on a multi-IP host

Cause racine : Une règle de policy routing envoie cette source vers une table de routage vide/incorrecte.

Correction : ip rule show et ip route show table X. Alignez les règles avec l’egress/passarelle voulu(e).

5) Symptom: Works one direction, fails the other; errors vary between timeout and unreachable

Cause racine : Routage asymétrique combiné à un RPF strict d’un côté.

Correction : Vérifiez rp_filter et les contrôles anti‑usurpation en amont. Utilisez le mode loose si justifié, ou corrigez la symétrie du routage.

6) Symptom: After a gateway failover, some hosts get “No route to host” for minutes

Cause racine : Cache voisin obsolète + annonces gratuitous ARP/ND retardées, ou tuning agressif des timers.

Correction : Assurez‑vous que la passerelle envoie des gratuitous ARP/ND au basculement. Envisagez de vider les entrées voisin sur les hôtes impactés seulement en dernier recours.

7) Symptom: Only specific ports show “No route to host” (not “connection refused”)

Cause racine : Un pare‑feu rejette avec ICMP unreachable pour certains ports/flux, ou un middlebox classe le trafic.

Correction : Tcpdump pour les ICMP unreachables pendant la tentative de connexion échouée. Confirmez avec l’équipe réseau/sécurité ; ajustez la politique ACL.

8) Symptom: IPv6 destination fails with “No route to host,” IPv4 works

Cause racine : Route IPv6 par défaut manquante ou échec NDP ; RA désactivées ; pare‑feu bloquant ICMPv6 (ce qui casse IPv6 de façons non évidentes).

Correction : Utilisez ip -6 route et ip -6 neigh. Assurez‑vous que ICMPv6 est autorisé de façon appropriée ; confirmez les annonces de routeur si utilisées.

Checklists / plan étape par étape

Ceci est la section « à faire à chaque fois ». Imprimez‑la. Mettez‑la dans votre runbook d’incident. Faites en sorte que quelqu’un empêche la salle de partir en debugging freestyle.

Checklist A: Local host sanity (Ubuntu 24.04)

Confirmer que l’interface est up et a du carrier.
Utilisez ip link show. Si pas de carrier, corrigez la connectivité virtuelle/physique avant toute chose.
Confirmer l’adressage et le préfixe.
Utilisez ip -br addr. Si le préfixe est erroné, les routes et le comportement ARP vous tromperont.
Confirmer la route par défaut et la route spécifique.
Utilisez ip route show et ip route get <dest>.
Vérifier le policy routing.
Utilisez ip rule show. Si des règles non‑défaut existent, inspectez ces tables.
Vérifier l’entrée voisin pour le next hop (passerelle).
Utilisez ip neigh show. INCOMPLETE est votre grande flèche rouge.
Vérifier le pare‑feu local pour des rejects.
Utilisez nft list ruleset et ufw status.
Capturer le trafic pendant 30 secondes.
Utilisez tcpdump pour ARP et ICMP. C’est votre preuve et votre boussole.

Checklist B: “Is it L2, L3, or policy?” decision tree

Si ip route get échoue (pas de route) : corrigez le routage/passerelle défaut/policy routing.
Si la route existe mais la passerelle ARP est INCOMPLETE : c’est l’adjacence (VLAN/tagging/switch/passerelle down).
Si l’ARP de la passerelle se résout et que la passerelle répond mais que la destination échoue :
vérifiez le routage/les ACL en amont. Capturez les ICMP unreachables.
Si rien ne répond et rien ne rejette (timeouts) : cherchez des drops (ACL drop, security group drop, MTU blackhole, pare‑feu en amont silent drop).

Checklist C: Escalation packet (what to send to the network/security team)

Si vous avez besoin d’une autre équipe, n’envoyez pas « ça ne marche pas ». Envoyez un paquet concis :

ip route get <dest> (montre next hop, interface, IP source)
ip route show et ip rule show (prouve l’intention locale)
ip neigh show pour la passerelle et la destination (montre l’état ARP)
30 secondes de tcpdump montrant requêtes/réponses ARP et/ou ICMP unreachables (montre qui rejette)
Horodatage exact et destination/port (pour corréler les logs)

FAQ

1) Pourquoi ai‑je « No route to host » alors que la table de routage semble correcte ?

Parce que le routage n’est que la première étape. Linux peut connaître le next hop mais échouer malgré tout à ARP/NDP pour ce next hop.
Vérifiez ip neigh pour la passerelle ; INCOMPLETE ou FAILED signifie que vous n’avez pas de reachabilité L2 vers le next hop.

2) Quelle est la commande unique la plus rapide pour commencer ?

ip route get <dest>. Elle vous indique l’interface, la passerelle et l’IP source choisie. Si cette sortie vous surprend, vous avez trouvé la catégorie du problème.

3) Comment une ACL peut‑elle causer « No route to host » au lieu d’un timeout ?

Certaines ACL/pare‑feu sont configurés pour rejeter plutôt que laisser tomber. Le reject peut générer un ICMP « host unreachable » (ou similaire),
que votre noyau remonte comme « No route to host » immédiatement. Capturez l’ICMP avec tcpdump pour le prouver.

4) « No route to host » est‑ce la même chose que « Destination Host Unreachable » de ping ?

Ils sont liés mais pas identiques. « Destination Host Unreachable » est l’interprétation de ping d’un ICMP unreachable ou d’une défaillance locale de routage.
« No route to host » est une erreur de socket que voient vos applications. Les deux pointent souvent vers une inaccessibilité L2/L3, mais il faut localiser où l’unreachable est généré.

5) Pourquoi ça échoue seulement pour une IP destination, pas pour tout le sous‑réseau ?

Causes communes : une route spécifique manquante en amont, une ACL ciblant cet hôte, l’hôte destination down, ou un conflit/duplication ARP pour cette IP.
Utilisez tracepath et tcpdump pour ICMP unreachables afin d’identifier le saut qui rejette.

6) Quel rôle joue netplan d’Ubuntu 24.04 là‑dessus ?

Netplan est la couche de configuration ; le noyau prend les décisions de forwarding. Les erreurs netplan apparaissent comme de mauvaises adresses, mauvaises routes, mauvaise passerelle, ou mauvais renderer.
Vérifiez avec netplan get et networkctl status (ou les outils NetworkManager si c’est votre renderer).

7) Le DNS peut‑il provoquer « No route to host » ?

Le DNS peut vous faire connecter vers la mauvaise IP, mais l’erreur porte toujours sur l’accès à cette IP. Si vous suspectez le DNS, résolvez le nom en adresse,
puis lancez ip route get pour cette adresse et procédez normalement.

8) Que faire si l’ARP fonctionne pour la passerelle, mais que les connexions indiquent toujours « No route to host » ?

Alors l’unreachable est probablement généré en amont (passerelle/pare‑feu) ou localement par policy routing ou des rejects de pare‑feu.
Capturez l’ICMP sur l’hôte lors d’une tentative de connexion échouée ; si vous voyez un ICMP unreachable provenant d’un routeur/pare‑feu, vous avez votre coupable.

9) Comment différencier rapidement « drop » vs « reject » ?

Un reject échoue souvent immédiatement et peut montrer un ICMP unreachable dans tcpdump. Un drop se traduit généralement par un timeout. Ce n’est pas parfait, mais c’est un bon heuristique.
Confirmez toujours avec une capture sur l’interface egress.

10) Dois‑je vider le cache ARP comme solution ?

Comme coup de pouce diagnostique, parfois oui. Comme habitude, non. Vider les entrées voisin peut masquer un problème systémique (mauvaise signalisation de basculement, mauvais tagging VLAN, IP en double).
Utilisez‑le pour confirmer un comportement, puis corrigez la cause sous‑jacente.

Conclusion : étapes suivantes pour éviter la répétition

« No route to host » n’est pas une énigme. C’est une demande : montre‑moi la décision de routage, montre‑moi l’état du voisin, montre‑moi le résultat politique.
Faites ces trois choses et le problème cesse généralement d’être mystérieux en quelques minutes.

Étapes pratiques suivantes :

Standardisez votre bundle de triage : ip route get, ip neigh, ip rule, et un court tcpdump.
Apprenez à l’équipe à traiter les entrées voisin INCOMPLETE comme « stoppez et vérifiez VLAN/passerelle », pas comme « essayez une autre route ».
Documentez quels sous‑réseaux peuvent parler à quels services. « Implicitement routable » est un mythe dans les réseaux segmentés.
Dans la gestion des changements, exigez une preuve de connectivité depuis au moins un hôte dans chaque segment après des mises à jour ACL/routage.