Timeouts aléatoires Debian/Ubuntu : tracer le chemin réseau avec mtr et tcpdump (Cas n°4)

octobre 24, 2025 • février 3, 2026 • Lecture : 30 min • Views: 13

Cet article vous a aidé ?

Les timeouts aléatoires sont le pire type d’incident : trop petits pour produire un pic clair sur un graphe, trop fréquents pour être ignorés,
et parfaitement synchronisés pour toucher la personne en astreinte ou celle qui fait une démo. Votre supervision indique « latence élevée », votre
application dit « upstream timed out », et vos utilisateurs déclarent « c’est cassé », avec la confiance de quelqu’un qui n’a jamais dû traquer
un paquet à travers trois réseaux et un load balancer.

Ce cas concerne la chose ennuyeuse mais fiable : tracer le chemin avec mtr, capturer la vérité avec tcpdump,
puis corriger la cause réelle — pas la dernière chose que vous avez touchée. Nous traiterons Debian/Ubuntu comme la salle d’opération,
et le réseau comme le patient qui « oublie » de mentionner qu’il fume aussi.

Procédure de diagnostic rapide

Lorsque les timeouts sont « aléatoires », le vrai motif est généralement masqué par les moyennes. Votre travail est de forcer le système à montrer sa main.
Voici l’ordre qui permet de trouver rapidement les goulots d’étranglement, sans passer une journée à discuter des tableaux de bord.

1) Confirmez l’étendue en 5 minutes

Un hôte ou plusieurs ? Si c’est une VM, pensez NIC de l’hôte, driver, MTU, firewall local/conntrack. Si c’est tout un niveau de service, pensez chemin, LB, DNS, upstream.
Une destination ou plusieurs ? Si ce n’est qu’un upstream, focalisez-vous sur ce chemin. Si c’est plusieurs, suspectez la pile réseau locale, le résolveur ou l’egress.
TCP, UDP ou les deux ? Le cas TCP seulement sent souvent le MSS/MTU, firewall stateful, conntrack, ou des tempêtes de retransmissions. UDP seul pointe vers DNS, QUIC ou des limitations de débit.

2) Reproduire depuis la machine qui subit les timeouts

Exécutez une sonde au niveau applicatif (curl avec timing) et une sonde au niveau paquet (tcpdump) en même temps.
Collectez une petite capture (30–60 secondes) pendant une fenêtre de panne. Ne « capturez pas toute la journée » à moins d’aimer expliquer l’usage disque.

3) Tracer le chemin avec mtr, mais utilisez le bon protocole

Utilisez mtr -T (TCP) vers le port réel de votre appli lorsque ICMP est filtré ou dépriorisé.
Comparez depuis deux points de vue : l’hôte en échec et un pair sain dans le même sous-réseau/VPC.

4) Identifiez dans quelle catégorie vous vous trouvez

Perte sur le dernier saut (destination) : problème réel ou limitation de débit côté destination.
La perte commence en milieu de chemin et persiste : perte réelle de transit ou congestion.
Perte uniquement sur un saut intermédiaire : en général limitation d’ICMP ; ignorer sauf si latence/perte apparaissent en aval.
Pas de perte, mais pics de latence : bufferbloat, mise en file, problèmes d’interrupts CPU, ou retransmissions cachées par ICMP.
Semble propre, mais l’appli timeout : blackhole MTU, routage asymétrique, drops conntrack, ou bizarreries DNS/Happy Eyeballs.

5) Faites le plus petit changement qui prouve la causalité

Serrez le MSS, ajustez le MTU, changez de résolveur, épinglez une interface, changez la préférence de route, ou désactivez les offloads (temporairement) pour prouver une hypothèse.
Ne déployez pas une « refonte réseau » pour corriger un timeout. Ce n’est pas de l’ingénierie ; c’est de l’art performance.

Un modèle mental opérationnel des timeouts aléatoires

Un timeout n’est pas une défaillance unique. C’est le symptôme final de quelque chose qui met trop de temps : un SYN sans réponse, une requête DNS bloquée,
une requête retransmise, un ACK retardé derrière une file encombrée, une découverte PMTU qui ne se termine jamais, ou un firewall stateful qui
ignore silencieusement des paquets « bizarres » parce qu’il le peut.

Les timeouts aléatoires prennent généralement une des quatre formes :

Micro-pertes avec retries : vous ne remarquez pas tant que le trafic n’augmente pas ou que les timeouts ne se resserrent.
Mise en file par rafales : un lien ou une NIC virtuelle devient congestionné, les paquets attendent dans des buffers, latence spike, puis « récupère ».
Incohérence de chemin : ECMP, routage asymétrique ou routes instables envoient certains flux sur une voie dégradée.
Mésentente de protocole : MTU/MSS, bugs de checksum/offload, ou comportements firewall/conntrack qui n’apparaissent qu’avec certaines tailles ou débits de paquets.

L’essentiel est d’arrêter de penser « le réseau » et de commencer à penser en termes de flux. Un flux peut être cassé alors que d’autres semblent corrects,
surtout quand des load balancers, NAT ou ECMP sont impliqués. C’est pourquoi vous capturez des paquets et cherchez retransmissions, resets et blocages.

Faits et contexte qui vous rendent meilleur

Traceroute précède la plupart des équipes SRE de production. Il a été créé à la fin des années 1980 pour déboguer le routage et la connectivité en exploitant l’expiration TTL.
mtr est essentiellement « traceroute avec mémoire ». Il échantillonne en continu et montre les tendances — parfait pour les problèmes intermittents.
ICMP est souvent traité comme un trafic de seconde zone. De nombreux routeurs limitent ICMP, donc un mtr basé sur ICMP peut montrer une « perte » qui n’est pas une perte réelle pour TCP.
La découverte de PMTU repose sur ICMP « Fragmentation Needed ». Si ces messages ICMP sont bloqués, vous pouvez obtenir un blackhole PMTU : petits paquets fonctionnent, gros paquets stagnent.
Les retransmissions TCP sont normales — jusqu’à un certain point. Quelques retransmissions arrivent sur des réseaux sains ; des retransmissions soutenues indiquent perte ou réordonnancement sévère.
conntrack Linux a des tables finies. Quand les tables se remplissent, vous n’obtenez pas une belle erreur. Vous obtenez des drops qui semblent « aléatoires ».
ECMP peut rendre le débogage déconcertant. Deux sondes consécutives peuvent emprunter des chemins différents ; un chemin peut être sain, l’autre pathologique.
Les offloads peuvent tromper les captures de paquets. GRO/TSO peuvent faire apparaître des segments géants dans tcpdump qui ne sortent pas réellement sur le lien de cette façon, sauf si vous en tenez compte.
Les timeouts DNS peuvent se faire passer pour des « timeouts réseau ». Votre appli peut signaler des timeouts upstream alors qu’elle est coincée sur une résolution de noms.

Tâches pratiques : commandes, sorties et décisions

Ce sont des tâches de terrain. Chacune inclut : une commande exécutable, ce que signifie la sortie, et la décision suivante.
Exécutez-les depuis l’hôte qui subit les timeouts. Si possible, exécutez le même jeu depuis un hôte « connu bon » sur le même réseau pour comparaison.

Task 1: Confirm interface, IP, and default route

cr0x@server:~$ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128
ens5             UP             10.20.4.17/24 fe80::5054:ff:fe12:3456/64

cr0x@server:~$ ip route show default
default via 10.20.4.1 dev ens5 proto dhcp src 10.20.4.17 metric 100

Signification : Vous savez quelle interface importe et où le trafic sort. Si vous avez plusieurs routes par défaut, vous avez trouvé une cause probable.
Décision : Si le routage est ambigu (plusieurs defaults, routage par politique), capturez la sélection de route avec ip route get (Task 2) et cherchez un routage asymétrique.

Task 2: Verify route selection to the failing destination

cr0x@server:~$ ip route get 203.0.113.10
203.0.113.10 via 10.20.4.1 dev ens5 src 10.20.4.17 uid 1000
    cache

Signification : Confirme l’interface d’egress et la gateway pour cette IP.
Décision : Si cela varie entre exécutions, suspectez routage par politique, tables multiples, ou ECMP à la frontière. Si l’IP source est inattendue, corrigez le routage basé sur la source.

Task 3: Check link-level counters for drops and errors

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

Signification : Des drops au niveau NIC peuvent provoquer retransmissions et timeouts. Les erreurs sont pires.
Décision : Si les RX drops augmentent pendant l’incident, suspectez congestion de l’hôte, limites de ring buffer, ou problèmes de NIC virtuelle. Passez à la Task 11 (stats interrupt/softnet) et Task 12 (qdisc/queue).

Task 4: Validate DNS quickly (because it lies quietly)

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

cr0x@server:~$ getent ahostsv4 api.example.internal
10.60.8.21      STREAM api.example.internal
10.60.8.21      DGRAM
10.60.8.21      RAW

Signification : Le résolveur est systemd-resolved et vous avez deux serveurs DNS. Le nom se résout rapidement.
Décision : Si getent bloque ou échoue de façon intermittente, corrigez le DNS avant de toucher le chemin réseau. Si le DNS est solide, continuez.

Task 5: Application-level timing with curl (pinpoint which phase stalls)

cr0x@server:~$ curl -sS -o /dev/null -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://203.0.113.10:443/health
dns:0.000 connect:0.214 tls:0.000 ttfb:2.997 total:3.002

Signification : DNS est instantané, la connexion TCP a pris 214ms, et le time-to-first-byte est ~3s. Ce n’est pas un timeout de connexion ; c’est un blocage de réponse serveur ou une perte en aval après la connexion.
Décision : Capturez les paquets pendant cette requête exacte (Task 9) et lancez un mtr TCP vers le port 443 (Task 7).

Task 6: mtr with ICMP to get a first shape

cr0x@server:~$ mtr -n -r -c 50 203.0.113.10
Start: 2025-12-30T10:14:02+0000
HOST: server                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.20.4.1                  0.0%    50    0.3   0.4   0.2   1.8   0.3
  2.|-- 10.20.0.1                  0.0%    50    0.5   0.6   0.4   2.0   0.3
  3.|-- 192.0.2.9                  6.0%    50    1.2   1.3   0.9  12.4   1.6
  4.|-- 198.51.100.14              0.0%    50    2.1   2.4   1.8  15.6   2.1
  5.|-- 203.0.113.10               2.0%    50    2.7   3.1   2.2  48.0   6.7

Signification : Une certaine perte apparaît au saut 3 et à la destination. Mais la perte ICMP peut être due à une limitation de débit.
Décision : Répétez avec mtr TCP vers le port réel (Task 7). Si TCP montre la même perte/pics, traitez-la comme réelle. Sinon, arrêtez d’accuser le saut 3.

Task 7: mtr with TCP SYN to the real service port

cr0x@server:~$ mtr -n -T -P 443 -r -c 50 203.0.113.10
Start: 2025-12-30T10:15:31+0000
HOST: server                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.20.4.1                  0.0%    50    0.5   0.6   0.3   3.1   0.6
  2.|-- 10.20.0.1                  0.0%    50    0.7   0.8   0.5   4.8   0.8
  3.|-- 192.0.2.9                  0.0%    50    1.4   1.5   1.0   6.5   0.9
  4.|-- 198.51.100.14              0.0%    50    2.2   2.6   1.9  21.0   2.9
  5.|-- 203.0.113.10               4.0%    50    3.0   6.8   2.4  98.7  17.2

Signification : Maintenant la perte n’apparaît qu’à la destination et la latence moyenne est mauvaise avec un pire cas très élevé. Cela correspond à une vraie douleur applicative.
Décision : Passez de la « suspicion de chemin » à la « vérité du flux ». Capturez retransmissions TCP et blocages (Task 9/10). Testez aussi MTU/PMTUD (Task 8).

Task 8: Check MTU and PMTUD behavior (the blackhole classic)

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

cr0x@server:~$ ping -M do -s 1472 -c 3 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 1472(1500) bytes of data.
1472 bytes from 203.0.113.10: icmp_seq=1 ttl=54 time=3.11 ms
1472 bytes from 203.0.113.10: icmp_seq=2 ttl=54 time=3.08 ms
1472 bytes from 203.0.113.10: icmp_seq=3 ttl=54 time=3.06 ms

--- 203.0.113.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Signification : Un chemin à 1500 octets fonctionne pour ICMP. Ça ne garantit pas que PMTUD fonctionne pour TCP, mais c’est un bon signe.
Décision : Si cela échoue avec « Frag needed », réduisez la taille jusqu’à ce que ça passe et comparez à l’attendu. Si cela bloque (pas de réponses), suspectez un blocage ICMP en milieu de chemin et envisagez le clamp MSS (section Fixes).

Task 9: Capture traffic for one destination (focused tcpdump)

cr0x@server:~$ sudo tcpdump -i ens5 -nn -s 0 -w /tmp/case4_443.pcap 'host 203.0.113.10 and tcp port 443'
tcpdump: listening on ens5, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C
1458 packets captured
1492 packets received by filter
0 packets dropped by kernel

Signification : Vous avez une capture propre sans drops du noyau. C’est important : des drops dans la capture vous font accuser le réseau pour votre propre problème CPU.
Décision : Si tcpdump signale des drops du noyau, réduisez le périmètre de capture, augmentez les buffers, ou corrigez la congestion de l’hôte (Task 11). Puis analysez les retransmissions (Task 10).

Task 10: Spot retransmits and resets (quick tshark-less method)

cr0x@server:~$ sudo tcpdump -nn -tt -r /tmp/case4_443.pcap 'tcp[tcpflags] & (tcp-rst) != 0 or tcp[13] & 0x10 != 0' | head
1735553741.102134 IP 10.20.4.17.51322 > 203.0.113.10.443: Flags [S], seq 240112233, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
1735553741.316902 IP 203.0.113.10.443 > 10.20.4.17.51322: Flags [S.], seq 99112233, ack 240112234, win 65535, options [mss 1380,sackOK,TS val 222 ecr 111,nop,wscale 8], length 0
1735553741.317001 IP 10.20.4.17.51322 > 203.0.113.10.443: Flags [.], ack 1, win 502, options [nop,nop,TS val 112 ecr 222], length 0

Signification : Vous cherchez des patterns : retransmissions SYN, retransmissions de données, ACKs dupliqués, et RSTs. L’extrait ci-dessus montre une poignée de handshake normale, et le serveur annonce MSS 1380 (intéressant).
Décision : Si vous voyez des SYN répétés sans SYN-ACK, c’est atteignabilité/filtrage. Si vous voyez des retransmissions de données et des tempêtes de dup ACK, c’est perte/queueing. Si MSS est anormalement bas, investiguez MTU ou overhead de tunnel.

Task 11: Check softnet backlog drops (host can be the bottleneck)

cr0x@server:~$ awk '{print "cpu"NR-1, "processed="$1, "dropped="$2, "time_squeeze="$3}' /proc/net/softnet_stat | head
cpu0 processed=12345678 dropped=12 time_squeeze=34
cpu1 processed=12233445 dropped=0 time_squeeze=0
cpu2 processed=11999887 dropped=0 time_squeeze=2
cpu3 processed=12111222 dropped=9 time_squeeze=17

Signification : Drops/time_squeeze indiquent que le noyau n’arrive pas à suivre le traitement des paquets sur certains CPU. Cela génère des pertes « aléatoires » du point de vue de l’appli.
Décision : Si cela monte en flèche pendant les incidents, corrigez l’hôte : affinité IRQ, tailles des rings NIC, qdisc, ou réduisez le taux de paquets. N’ouvrez pas un ticket « Internet instable » tout de suite.

Task 12: Inspect qdisc and pacing (bufferbloat and queueing)

cr0x@server:~$ tc -s qdisc show dev ens5
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
 Sent 876543210 bytes 1122334 pkt (dropped 7, overlimits 0 requeues 21)
 backlog 0b 0p requeues 21
  maxpacket 1514 drop_overlimit 0 new_flow_count 1234 ecn_mark 0
  new_flows_len 0 old_flows_len 0

Signification : fq_codel est généralement bon. Un petit nombre de drops est acceptable. Overlimits et backlog massif indiqueraient de la mise en file.
Décision : Si vous voyez un backlog/overlimits massif, vous saturez l’egress ou vous shapez mal. Corrigez les limites de bande passante, politiques de shaping, ou la congestion upstream.

Task 13: Check conntrack pressure (stateful drops look random)

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

cr0x@server:~$ sudo dmesg -T | tail -n 5
[Tue Dec 30 10:12:01 2025] TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
[Tue Dec 30 10:12:07 2025] nf_conntrack: table full, dropping packet

Signification : Si conntrack est plein ou proche du max, des paquets sont dropés et les connexions stagnent. Le noyau vous le dit, discrètement, dans dmesg.
Décision : Si vous voyez « table full », soit vous augmentez la taille conntrack, soit vous réduisez le churn de connexions, soit vous arrêtez de suivre certains flux que vous n’avez pas besoin de suivre (avec précaution). Si vous voyez des SYN cookies, enquêtez sur des rafales d’inbound ou un backlog mal dimensionné.

Task 14: Validate rp_filter and asymmetric routing risk

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

Signification : Le reverse path filtering strict peut dropper du trafic légitime dans des scénarios de routage asymétrique (commun avec des hôtes multi-homed, routage par politique, certains edges cloud).
Décision : Si votre chemin est asymétrique (vérifié via tables de routage et captures), mettez rp_filter en mode loose (2) sur les interfaces concernées, mais seulement après avoir compris le rayon d’effet.

Utiliser mtr sans se tromper

mtr est une lampe torche, pas un procès-verbal. Il est excellent pour montrer où la latence et la perte semblent exister, mais il peut aussi vous conduire à accuser
à tort un saut innocent qui se contente de limiter les réponses ICMP. L’astuce est de l’interpréter comme un opérateur, pas comme un touriste.

Trois règles pour mtr qui évitent de mauvaises décisions

La perte à un saut intermédiaire est sans importance sauf si elle persiste en aval.
Si le saut 3 montre 30% de perte mais que le saut 4 et la destination montrent 0%, le saut 3 dépriorise probablement vos sondes.
Adaptez le protocole au problème.
Si votre appli utilise TCP/443, utilisez mtr -T -P 443. ICMP vous dit quelque chose, mais pas forcément ce dont vous avez besoin.
Échantillonnez assez longtemps pour attraper le « aléatoire ».
10 sondes peuvent paraître parfaites. 200 sondes peuvent révéler une perte de 3% qui ruine la latence tail.

Blague #1 : Traceroute, c’est comme les potins du bureau — parfois exact, toujours confiant, et il ne dit jamais ce qui s’est passé dans la salle de réunion.

Patrons mtr qui comptent

Changement d’étape de latence : un saut après lequel la latence reste plus élevée suggère un lien plus lent, une limite de tunnel, ou un segment congestionné.
Pire cas instable à la destination : douleur de latence tail, souvent queueing ou perte intermittente.
Perte uniquement à la destination : peut être une perte réelle de last-mile, limitation de débit côté destination, ou comportement firewall à l’extrémité. Confirmez avec tcpdump.
Comportement alterné des sauts : peut indiquer ECMP où des sondes différentes empruntent des chemins différents. mtr peut afficher une vue mélangée.

tcpdump : attraper retransmissions, MTU et blocages

tcpdump est l’endroit où les débats meurent. Il ne se soucie pas de la page d’état de votre cloud provider ni de la confiance de l’équipe réseau. Il montre ce que
votre hôte a envoyé, ce qu’il a reçu, et ce qu’il n’a jamais reçu en retour.

Comment capturer sans nuire au patient

Filtrez strictement. Capturez uniquement l’hôte/port dont vous avez besoin. Le disque et le CPU sont des ressources de production.
Capturez en courtes rafales. 30–60 secondes pendant une fenêtre mauvaise vaut mieux que 4 heures de « mostly fine ».
Consignez les drops du noyau. Si tcpdump droppe des paquets, votre capture est incomplète et vos conclusions sont suspectes.

Trois signatures TCP-level des « timeouts aléatoires »

Retransmissions SYN : la tentative de connexion n’obtient pas de SYN-ACK. Souvent firewall, route, ou surcharge upstream.
Retransmissions de données et ACKs dupliqués : perte de paquets ou réordonnancement. La perte est plus courante ; le réordonnancement est plus rare mais pénible.
Blocages après l’envoi de gros segments : problèmes MTU/MSS/PMTUD, surtout si les petites requêtes réussissent et que les plus grosses stagnent.

Cas n°4 : le chemin semble « correct » jusqu’au moment où il ne l’est plus

Ce cas apparaît dans des systèmes réels parce que le réseautage moderne est empilé couche sur couche : overlay VPC, chiffrement, load balancers,
gateways NAT, parfois un service mesh. Le chemin peut être « joignable », mais quand même incorrect d’une façon qui n’impacte que certaines tailles de paquets ou certains flux.

Les symptômes

Timeouts intermittents vers une API HTTPS upstream.
La plupart des requêtes réussissent ; certaines pendent 2–10 secondes, puis échouent.
Ping ICMP paraît propre. mtr basé ICMP montre une perte occasionnelle à un saut milieu, ce qui lance des threads Slack improductifs.
mtr basé TCP montre latence tail à la destination et un peu de perte.

Le chemin d’investigation qui fonctionne

Commencez par l’hôte. Prouvez si l’hôte droppe des paquets (softnet, drops NIC). Ensuite prouvez si le flux retransmet.
Enfin, validez MTU/MSS et les éventuelles frontières de tunnel.

Une cause racine plausible dans ce cas

L’élément révélateur est le mismatch MSS dans le handshake : le serveur annonce MSS 1380. Cela implique fortement que quelque part sur le chemin,
les paquets plus gros qu’environ 1420–1450 octets sont risqués (overhead de tunnel, IPsec, GRE/VXLAN, ou un edge provider faisant quelque chose de particulier).
Si PMTUD est bloqué ou peu fiable, certains flux vont se bloquer quand ils essaieront d’envoyer de plus grands records TLS ou réponses HTTP.

Vous verrez souvent cette combinaison :

Les petites requêtes (health checks, JSON court) passent.
Les requêtes provoquant de plus grosses réponses ou des uploads échouent de façon intermittente.
tcpdump montre des retransmissions de segments pleine taille ; l’émetteur recule, puis eventualmente timeout.

Prouver cela avec une capture ciblée

Dans la capture, cherchez des retransmissions répétées du même numéro de séquence, surtout lorsque la longueur du segment est proche de votre MSS.
Vérifiez aussi la présence de messages ICMP « fragmentation needed » ; s’ils sont absents et que le trafic se bloque sur les grosses tailles, un blackhole PMTUD est probable.

Blague #2 : Les bugs MTU sont comme le glitter — une fois entrés dans votre réseau, ils apparaissent partout et personne n’admet qui les a apportés.

Corrections qui tiennent dans le temps

Il y a deux catégories de correctifs : arrêter l’hémorragie et réparer le chemin. Faites les deux, mais dans cet ordre.
Les systèmes de production privilégient la disponibilité à l’esthétique.

Fix 1: Clamp TCP MSS à la périphérie (pragmatique, souvent immédiat)

Si vous contrôlez un firewall/router/NAT entre vos hôtes et l’upstream, imposez un MSS sûr afin que TCP n’essaie jamais d’envoyer
des paquets plus gros que ce que le chemin peut transporter. Cela contourne la dépendance à PMTUD.

cr0x@server:~$ sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ens5 -j TCPMSS --clamp-mss-to-pmtu

Signification : Les paquets SYN voient leur MSS ajusté pour correspondre au PMTU découvert (quand c’est possible).
Décision : Si PMTUD est cassé, vous devrez peut-être définir une valeur MSS explicite (par ex. 1360–1400) selon l’overhead de tunnel. Validez avec tcpdump et des timeouts réduits.

Fix 2: Définir le MTU correct sur l’interface (correct quand vous possédez l’underlay)

Dans des réseaux overlay (VXLAN, IPsec), le MTU effectif est plus petit que 1500. Si votre hôte pense pouvoir faire 1500, il va essayer. Puis le chemin fait
ce que font les chemins : il droppe ce qu’il ne peut pas transporter.

cr0x@server:~$ sudo ip link set dev ens5 mtu 1450

Signification : L’hôte n’enverra pas de trames supérieures à 1450 pour des tailles L3 compatibles avec ce MTU.
Décision : Ne faites cela que si votre environnement l’attend (VPC cloud, tunnels). Confirmez en vérifiant le MTU recommandé du provider et en mesurant avec ping -M do.

Fix 3: Arrêter de bloquer PMTUD ICMP au milieu

La correction correcte est souvent « permettre ICMP type 3 code 4 » (fragmentation needed) à travers les firewalls. Mais c’est le réseau d’entreprise,
donc « correct » peut nécessiter des réunions. Néanmoins : poussez pour cela. Cela guérit la maladie, pas seulement le symptôme.

cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }
}

Signification : ICMP est accepté ici (bon). Si vous voyez ICMP bloqué, PMTUD peut échouer.
Décision : Autorisez l’ICMP nécessaire pour votre environnement. Ne « bloquez pas tout ICMP » puis ne soyez pas surpris quand le réseau se comporte étrangement.

Fix 4: Réduire les drops de paquets sur l’hôte (hygiène softnet/IRQ)

Si la Task 11 montre des drops softnet, corrigez l’hôte. Améliorations courantes : activer RSS, répartir les IRQs, et ne pas laisser un CPU traiter tout le trafic.

cr0x@server:~$ grep -H . /proc/interrupts | grep -E 'ens5|virtio' | head
/proc/interrupts:  43:   9922331          0          0          0  IR-PCI-MSI 327680-edge      virtio0-input.0
/proc/interrupts:  44:         0    8877665          0          0  IR-PCI-MSI 327681-edge      virtio0-output.0

Signification : Les interruptions ne sont pas équilibrées (CPU0 subit l’essentiel en entrée).
Décision : Ajustez l’affinité IRQ ou activez irqbalance si approprié, puis re-vérifiez les stats softnet sous charge.

Fix 5: Rendre conntrack ennuyeux à nouveau

Si conntrack est plein ou si vous voyez des drops, corrigez l’état. Augmenter la taille de la table uniquement si vous comprenez la mémoire et les schémas de trafic.
Mieux vaut réduire le churn : garder les connexions en vie, utiliser du pooling, et ne pas suivre ce qui n’est pas nécessaire (avec prudence concernant NAT et les politiques de sécurité).

cr0x@server:~$ sudo sysctl -w net.netfilter.nf_conntrack_max=524288
net.netfilter.nf_conntrack_max = 524288

Signification : Plus d’espace pour suivre les flux.
Décision : Si le count remonte jusqu’au max encore une fois, vous n’avez pas corrigé la cause — vous lui avez juste donné un entrepôt plus grand à brûler.

Fix 6: Préférer mtr TCP et des sondes service-level dans les runbooks

C’est une correction culturelle. Mettez à jour vos runbooks pour que « tracer le chemin » signifie « tracer avec le protocole qui importe ». Cela évite les faux blâmes et accélère le triage.

Trois micro-récits du monde de l’entreprise

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe fintech exploitait un ensemble de serveurs Ubuntu API derrière un load balancer managé. Les utilisateurs ont commencé à signaler des « échecs aléatoires de paiement ».
L’astreinte a lancé un mtr ICMP depuis un nœud API vers la passerelle de paiement. Il montrait 20–30% de perte au saut 4. La conclusion s’est formée instantanément :
« Le FAI droppe des paquets. » Un ticket a été ouvert. Tout le monde a attendu.

Pendant ce temps, les retries se sont accumulés. La passerelle de paiement a vu du trafic en rafales et a commencé à limiter le débit. Les timeouts se sont empirés.
L’équipe a ajouté plus de nœuds API, ce qui a augmenté le churn de connexions, ce qui a accru la pression conntrack sur la couche NAT d’egress.
Soudain, les timeouts n’étaient plus aléatoires — ils étaient constants, et chacun avait sa théorie favorite.

Un ingénieur plus discret a fait l’impopulaire : mtr -T -P 443 vers la gateway et un tcpdump de 60 secondes pendant les échecs.
La perte au saut 4 a disparu sous mtr TCP. La destination montrait des retransmissions SYN sporadiques. tcpdump affichait des SYN répétés sans SYN-ACK pendant des rafales.

Le vrai problème était un firewall stateful au milieu avec une limite SYN agressive copiée depuis un template « hardening ». La perte ICMP au saut 4 n’était que de l’ICMP dépriorisé.
La mauvaise hypothèse était de croire que la perte mtr sur un saut intermédiaire équivalait à une perte pour votre appli.

La correction a été ennuyeuse : ajuster les seuils du firewall pour correspondre aux patterns de trafic, ajouter la réutilisation de connexions, et alerter sur les retransmissions SYN.
Le ticket vers le FAI s’est clôturé avec une réponse polie mais vague, comme souvent.

Micro-récit 2 : L’optimisation qui s’est retournée contre eux

Une entreprise média voulait des uploads plus rapides vers un object store. Quelqu’un a remarqué que les serveurs utilisaient MTU 1500 dans un datacenter qui supportait le jumbo frames.
La proposition : mettre MTU 9000 partout. Plus de grosses trames, moins de paquets, moins de CPU. Ils l’ont déployé sur une flotte de boxes Debian.

Le débit d’upload s’est amélioré dans le même rack. Puis sont arrivés les bugs : timeouts intermittents vers certains services externes, handshakes TLS instables,
et comportement étrange où les petites API fonctionnaient mais tout ce qui était « lourd » se bloquait. mtr semblait « majoritairement correct ». Ping fonctionnait. Tout le monde s’est auto-complimenté à tort.

Le coupable était prévisible : toutes les liaisons entre ces serveurs et l’extérieur ne supportaient pas le jumbo. Certains segments clampaient, d’autres dropaient,
et les messages ICMP PMTUD étaient filtrés par un appliance sécurité intermédiaire. Résultat : blackholes PMTU pour un sous-ensemble de flux.
L’optimisation avait créé un réseau à deux vitesses où le même hôte se comportait différemment selon la destination.

Le rollback a été douloureux car les services avaient été ajustés autour de l’« amélioration », et tout devait réapprendre la réalité.
Ils ont finalement standardisé le MTU par zone, documenté cela, autorisé l’ICMP nécessaire pour PMTUD, et utilisé le MSS clamping à la frontière des tunnels.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une plateforme SaaS avait une règle interne : chaque canal d’incident doit inclure une capture de paquets depuis l’hôte en échec dans les 20 minutes.
Les gens se plaignaient que c’était bureaucratique. Ils voulaient « commencer par les tableaux de bord ». Les tableaux de bord rassurent. Les paquets disent la vérité.

Un jour, des timeouts aléatoires ont touché un ensemble de workers Ubuntu qui parlaient à une base de données sur un lien privé. Les graphes de latence étaient plutôt plats.
mtr ne montrait rien de suspect. L’équipe base de données insistait sur l’absence de changement. L’équipe réseau disait pareil. La seule chose qui changeait était le blâme.

La capture montrait des rafales périodiques de retransmissions corrélées avec un job batch nocturne. Pas une grosse perte, juste assez.
Sur les workers, /proc/net/softnet_stat montrait des drops et des pics de time_squeeze sur un sous-ensemble de CPU pendant ce batch.
Le problème n’était pas le lien ; c’était la pile réseau de l’hôte qui était asphyxiée pendant que la compression CPU-intensive tournait.

Parce qu’ils avaient la pratique standardisée « capture tôt », ils n’ont pas perdu une journée à se disputer sur les routeurs. Ils ont épinglé le set CPU du job batch,
ajusté l’affinité IRQ, et les timeouts ont disparu. Personne n’a reçu de trophée. La production s’est calmée, ce qui est le seul trophée qui compte.

Erreurs courantes : symptômes → cause racine → correctif

Cette section est opinionnée parce qu’elle est écrite dans le sang d’heures gaspillées.

1) mtr montre perte sur un saut du milieu

Symptômes : mtr indique 10–50% de perte au saut N, mais la destination semble correcte ou seulement légèrement affectée.
Cause racine : Limitation ou dépriorisation d’ICMP sur ce routeur. Pas une perte réelle de forwarding.
Fix : Relancez avec mtr -T -P <port>. N’agissez que si la perte/latence persiste jusqu’à la destination.

2) Timeouts aléatoires seulement pour des réponses ou uploads « lourds »

Symptômes : Les health checks passent. Les petites requêtes passent. Les gros payloads se bloquent ou timeoutent.
Cause racine : Mismatch MTU, blackhole PMTUD, overhead de tunnel, ou ICMP fragmentation-needed filtré.
Fix : Validez PMTU avec ping -M do, vérifiez le MSS dans SYN/SYN-ACK, clamp MSS ou définissez le MTU correct, autorisez ICMP PMTUD.

3) Retransmissions SYN pendant des pics

Symptômes : tcpdump montre des SYN répétés, peu de SYN-ACK, timeouts de connexion sous charge.
Cause racine : Limitation SYN du firewall, load balancer saturé, état conntrack/NAT épuisé, ou backlog d’accept upstream sous-dimensionné.
Fix : Inspectez conntrack/dmesg, ajustez les seuils du firewall, réduisez le churn de connexions (keepalive/pooling), scalez ou tunez l’upstream.

4) Semble être « perte réseau », mais tcpdump droppe des paquets

Symptômes : tcpdump signale « packets dropped by kernel », softnet drops montent, l’appli voit des timeouts.
Cause racine : L’hôte ne peut pas traiter les paquets assez vite (contention CPU, déséquilibre IRQ, bruit de virtualisation).
Fix : Réduisez le périmètre de capture ; corrigez l’hôte : affinité IRQ, RSS, irqbalance, pinning CPU, réduisez le taux de paquets, ou déplacez la charge.

5) Timeouts seulement depuis un sous-réseau ou une AZ

Symptômes : Même code, même service, mais une zone timeout plus souvent.
Cause racine : Chemin différent (routage, gateway NAT, politique firewall), ou un segment underlay dégradé.
Fix : Comparez mtr -T et captures depuis chaque zone. Corrigez l’egress divergent ; ne « paramétrez pas l’appli » pour tolérer une voie cassée.

6) « On a activé rp_filter strict pour la sécurité » et maintenant des choses étranges arrivent

Symptômes : Certaines réponses n’arrivent jamais, drops intermittents sur hôtes multi-homed.
Cause racine : Routage asymétrique plus reverse path filtering strict qui droppe des paquets légitimes.
Fix : Utilisez rp_filter en mode loose (2) là où l’asymétrie est attendue, et documentez le design de routage pour éviter que quelqu’un « re-sécurise » cela plus tard.

Checklists / plan étape par étape

Checklist A: 30-minute triage for random timeouts

Identifiez une IP:port défaillante et une destination témoin saine.
Exécutez curl -w timing (Task 5) pour voir si c’est connect vs TTFB vs total.
Lancez mtr -T -P (Task 7) assez longtemps pour attraper les pics.
Capturez 60 secondes avec tcpdump filtré sur cette host:port (Task 9).
Vérifiez les drops NIC (Task 3) et les drops softnet (Task 11).
Vérifiez conntrack et dmesg (Task 13).
Testez rapidement PMTU avec ping -M do (Task 8).
Faites un seul changement de confinement (MSS clamp ou ajustement MTU) uniquement s’il correspond clairement aux preuves.

Checklist B: Evidence package to hand to a network/provider team

Sortie horodatée de mtr -T -P montrant perte/latence à la destination.
Extrait pcap montrant retransmissions SYN ou retransmissions de données (inclure temps de début/fin).
IP source, IP destination, port, et si NAT est impliqué.
Confirmation que l’hôte ne droppe pas les paquets (softnet, tcpdump kernel drops).
Si MSS/MTU semble clampé (options SYN, valeurs MSS observées).

Checklist C: Hardening so this doesn’t come back next month

Ajoutez des sondes synthétiques qui mesurent séparément le temps de connexion et le TTFB.
Alertez sur les retransmissions TCP et les retransmissions SYN au niveau nœud.
Standardisez le MTU par environnement et documentez les overheads de tunnel.
Conservez l’ICMP nécessaire pour PMTUD dans les frontières internes.
Surveillez l’utilisation conntrack là où NAT/firewalls stateful existent.
Mettez à jour les runbooks : utilisez mtr TCP vers le port de service, pas ICMP par défaut.

FAQ

1) Pourquoi mtr ICMP montre-t-il de la perte alors que mon appli semble aller bien ?

Beaucoup de routeurs limitent les réponses ICMP (plan de contrôle) tout en forwardant normalement le trafic (plan de données). Utilisez mtr -T -P pour tester le protocole utilisé par votre appli.

2) Pourquoi mtr TCP montre-t-il de la perte à la destination — est-ce encore « faux » ?

C’est moins probable que ce soit faux, mais les destinations peuvent limiter SYN/ACK ou déprioriser les réponses sous charge. Confirmez avec tcpdump : voyez-vous des retransmissions SYN ou des retransmissions de données ?

3) Quelle est la façon la plus rapide de détecter un blackhole MTU ?

Comparez le comportement pour petits vs gros payloads, vérifiez le MSS dans SYN/SYN-ACK, et testez avec ping -M do en augmentant les tailles. Si les gros paquets stagnent et que l’ICMP « frag needed » est absent, suspectez un échec PMTUD.

4) Dois-je désactiver TSO/GRO lors du débogage ?

Seulement si vous savez pourquoi. Les offloads peuvent rendre les captures confuses, mais les désactiver en production peut nuire aux performances. Préférez interpréter les captures en tenant compte des offloads et gardez les tests ciblés.

5) Mon tcpdump indique « packets dropped by kernel ». Le réseau est-il coupable ?

Non. C’est votre hôte qui échoue à capturer (et souvent à traiter) les paquets assez rapidement. Corrigez CPU/IRQ/softnet ou réduisez la charge de capture avant d’accuser le chemin.

6) Comment savoir si les timeouts sont liés au DNS ?

Utilisez curl -w pour voir le temps de résolution et exécutez getent ahosts en boucle. Les problèmes DNS se manifestent par des pics dans time_namelookup ou des blocages des appels au résolveur.

7) Le MSS clamping, c’est de la bidouille ?

C’est une stratégie de confinement pragmatique. Le correctif long terme est un MTU cohérent et une PMTUD fonctionnelle, mais le MSS clamping est largement utilisé aux frontières de tunnel parce que ça marche.

8) Comment les timeouts aléatoires se rapportent-ils à l’ingénierie stockage ?

Le stockage distant (iSCSI, NFS, gateways d’objets) transforme la perte de paquets en blocages applicatifs rapidement. Un petit taux de retransmission peut devenir une énorme latence tail pour des IOs synchrones.

9) Quelle phrase garder en tête pendant ces investigations ?

« L’espoir n’est pas une stratégie. » — James Cameron

Conclusion : prochaines étapes

Les timeouts aléatoires ne sont pas aléatoires. Ils sont simplement répartis sur des flux, masqués par les moyennes, et protégés par les hypothèses erronées préférées des gens.
Le flux de travail fiable est simple : reproduisez sur l’hôte en échec, tracez le chemin avec le protocole correct, capturez les paquets pendant la panne,
et prouvez si vous avez affaire à de la perte, du queueing, du MTU/PMTUD, ou des drops côté hôte.

Prochaines étapes que vous pouvez faire aujourd’hui :

Mettez à jour votre runbook pour que la valeur par défaut soit mtr -T -P pour les timeouts applicatifs.
Ajoutez une procédure tcpdump-on-demand légère avec des filtres stricts et des fenêtres de capture courtes.
Établissez des attentes MTU/MSS de référence dans votre environnement (surtout si des tunnels existent).
Instrumentez les retransmissions et la pression conntrack là où NAT/équipements stateful existent.
Quand vous trouvez le correctif, consignez les preuves — pas la théorie — pour que le prochain astreint ne revivra pas votre week-end.