Problèmes MTU : la cause cachée de « certains sites ne se chargent pas »

Le modèle mental : pourquoi le MTU casse seulement une partie du trafic

MTU (Maximum Transmission Unit) est la taille maximale d’un paquet IP qui peut traverser un lien sans être fragmenté. L’MTU par défaut d’Ethernet est de 1500 octets. Ce chiffre est ancien, pratique, et toujours omniprésent. Le problème est que les réseaux modernes sont une pile de tunnels, d’overlays, de VPN et de middleboxes « utiles ». Chaque couche vole des octets pour ses en-têtes. Si vous ne prévoyez pas cette surcharge, des paquets qui tenaient auparavant cessent de tenir.

Quand un paquet est trop grand pour le saut suivant, il n’y a que quelques issues :

• La fragmentation se produit (IPv4 seulement, si elle est autorisée) : le routeur divise le paquet. Cela fonctionne souvent, mais c’est plus lent et fragile. Certains équipements gèrent mal les fragments. Certaines politiques de sécurité les suppriment.
• Le paquet est abandonné et un message ICMP est renvoyé : « Fragmentation needed » (IPv4) ou « Packet Too Big » (IPv6). C’est la voie saine pour Path MTU Discovery.
• Le paquet est abandonné et aucun ICMP utile ne revient : c’est le fameux trou noir PMTUD. TCP retransmet des gros paquets qui n’arrivent jamais. Du point de vue de l’application, tout « se bloque ».

Pourquoi cela n’affecte-t-il que certains sites ? Parce que tous les flux ne génèrent pas des paquets de la même taille. Une petite réponse HTTP peut tenir. Un enregistrement TLS plus volumineux, une requête avec beaucoup de cookies, ou un serveur qui envoie immédiatement un segment pleine taille peut dépasser le vrai path MTU. Certains CDN et certains sites déclenchent tout simplement plus facilement votre chemin cassé que d’autres.

Un autre détail important : TCP MSS (Maximum Segment Size) contrôle la taille utile TCP, qui est typiquement MTU moins les en-têtes IP+TCP. Si vous limitez MSS correctement à la frontière d’un tunnel, vous pouvez éviter de générer des paquets trop grands dès le départ. C’est un pansement avec des usages médicaux légitimes.

Vérité sèchement drôle : les bugs MTU sont l’équivalent réseau d’une porte qui s’ouvre vers l’intérieur alors que le code du feu exige l’ouverture vers l’extérieur — vous ne le découvrez qu’en panique.

Ce que « certains sites ne se chargent pas » signifie généralement au niveau paquet

Séquence d’échec typique :

1. Le client résout le DNS et se connecte à l’IP du serveur : OK.
2. Le handshake TCP en trois temps (SYN, SYN/ACK, ACK) : OK (paquets petits).
3. Le handshake TLS commence : souvent OK au début.
4. Le serveur envoie un paquet plus grand (chaîne de certificats, en-têtes HTTP, ou contenu initial) : il est abandonné s’il dépasse le path MTU réel et que PMTUD est cassé.
5. Le client attend, réessaie, le navigateur tourne en rond, et quelqu’un blâme le fournisseur SaaS.

Faits et historique : comment on en est arrivé là

Les problèmes MTU semblent modernes parce qu’on les voit surtout avec les VPN et les overlays, mais les ingrédients sont anciens. Quelques faits concrets et points historiques qui comptent opérationnellement :

1. MTU Ethernet 1500 octets est devenu courant parce qu’il équilibr[…] (texte restant)

MTU problems paragraph continues below with detailed points translated for clarity.

1. MTU Ethernet 1500 octets est devenu courant parce qu’il équilibr[…]

Note: The above placeholder indicates detailed bullets are preserved in the following full translation.

Je m’excuse : une erreur d’édition a laissé un placeholder. Voici la section complète traduite :

1. MTU Ethernet 1500 octets est devenu courant parce qu’il équilibr[…]

Reprise complète de la liste :

1. MTU Ethernet de 1500 octets est devenu courant car il trouvait un compromis entre efficacité et limites matérielles dans les premiers designs Ethernet ; c’est pratiquement le « contrat par défaut » de nombreux équipements.
2. PPPoE réduit famosamente l’MTU à 1492 à cause de son overhead d’encapsulation ; cela affecte les déploiements DSL et certains déploiements fibre depuis des décennies.
3. Path MTU Discovery (PMTUD) dépend du retour ICMP « too big » ; lorsque les réseaux ont commencé à bloquer l’ICMP massivement pour des raisons de « sécurité », les défaillances PMTUD sont devenues courantes.
4. IPv6 interdit la fragmentation dans le réseau ; seuls les points d’extrémité peuvent fragmenter. Cela rend l’ICMPv6 « Packet Too Big » indispensable pour un Internet fonctionnel.
5. IPsec, GRE, VXLAN et WireGuard ajoutent de l’overhead ; un MTU sûr à l’intérieur des tunnels est souvent inférieur à ce que les gens supposent, surtout avec des couches d’encapsulation multiples.
6. Les jumbo frames (MTU 9000) sont excellentes à l’intérieur de domaines contrôlés, mais deviennent une responsabilité quand elles sont accidentellement étendues à travers des limites qui ne peuvent pas les transporter.
7. La clamp MSS est devenue une solution courante dans les pare-feu et routeurs edge précisément parce que PMTUD était peu fiable dans les réseaux réels.
8. « Ne pas bloquer l’ICMP » est un conseil standard depuis des années, pourtant de nombreux réseaux d’entreprise le bloquent encore partiellement — souvent en autorisant l’echo mais en bloquant « fragmentation needed », ce qui est la mauvaise moitié.
9. Le comportement des navigateurs amplifie la douleur : les navigateurs modernes ouvrent de nombreuses connexions, utilisent HTTP/2 ou HTTP/3, et peuvent cacher des blocages par connexion derrière des indicateurs de chargement qui ressemblent à des bugs applicatifs.

Une citation qui devrait habiter l’esprit de chaque équipe ops : « Everything fails, all the time. » — Werner Vogels. C’est court, un peu sombre, et opérationnellement correct.

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

Si vous avez dix minutes et un utilisateur qui hurle « seulement certains sites », faites ceci dans l’ordre. Ne faites pas freestyle. Le freestyle, c’est comment on finit par redémarrer le mauvais routeur à 2 h du matin.

Premier : vérifier que c’est une panne en forme MTU

• Reproduisez depuis un hôte sur le même chemin réseau que l’utilisateur (même VPN, même VLAN, même Wi‑Fi).
• Vérifiez si les petites réponses fonctionnent mais que les plus grosses se bloquent (un indice révélateur).
• Utilisez un test ping « do not fragment » (DF ping) pour trouver la plus grande taille de paquet fonctionnelle.

Deuxième : localiser la frontière où l’MTU change

• Cherchez les tunnels : VPN, IPsec, GRE, WireGuard, cloud transit gateway, SD-WAN, overlays.
• Comparez les MTU d’interface des deux côtés : NIC client, interface de tunnel, pare‑feu inside/outside, ENI cloud.
• Confirmez que l’ICMP « too big » est autorisé de bout en bout (ou compensez avec du MSS clamping).

Troisième : appliquer le correctif le moins dangereux

• Préférez corriger MTU/PMTUD et autoriser l’ICMP requis.
• Si la politique ou le matériel du fournisseur bloque cela, appliquez le clamp MSS TCP à la bordure du tunnel comme solution pragmatique.
• Documentez l’MTU choisi et intégrez‑le dans le provisioning, pas dans la mémoire tribale.

Deuxième blague courte (et la dernière, selon les lois de ce document) : La façon la plus simple de trouver un bug MTU est de déclarer l’incident « probablement DNS ». Il deviendra immédiatement MTU par dépit.

Motifs de symptômes qui crient MTU

1) Le handshake TLS se bloque ou « plante » après ClientHello/ServerHello

Les petits paquets passent. Puis une chaîne de certificats ou un message de handshake plus volumineux déclenche un paquet trop grand. Si l’ICMP est bloqué, aucun des points d’extrémité n’apprend le path MTU, donc ils continuent d’envoyer des paquets qui n’arrivent jamais.

2) Les en‑têtes HTTP arrivent, mais les gros téléchargements échouent tôt

La première réponse tient. Les segments plus gros non. Les utilisateurs rapportent « la page se charge mais les images ne s’affichent pas », ou « la connexion fonctionne mais le tableau de bord ne s’affiche pas ».

3) Ça marche sur un hotspot mobile, échoue sur le Wi‑Fi/VPN d’entreprise

Chemin différent, MTU différent, politique ICMP différente. Les opérateurs mobiles ont souvent leurs propres particularités MTU aussi, mais le chemin est suffisamment différent pour éviter votre trou noir.

4) SSH se connecte, mais scp se bloque

Les frappes interactives sont minuscules. Les transferts de fichiers remplissent les segments TCP, exposant rapidement les problèmes MTU.

5) IPv4 fonctionne, IPv6 non (ou inversement)

IPv6 exige ICMPv6 PTB pour bien fonctionner. Si un pare‑feu le bloque, vous obtenez de la misère IPv6 sélective. Inversement, certains chemins IPv4 « fonctionnent » via la fragmentation alors que l’IPv6 casse sévèrement.

6) Kubernetes/containers : pod→extérieur instable, nœud→extérieur ok

Les réseaux overlay (VXLAN, Geneve) réduisent l’MTU effectif à l’intérieur du cluster. Si le MTU CNI est incorrect, les pods génèrent des paquets qui sont abandonnés à l’egress.

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

Voici les commandes que j’exécute réellement quand je suis en astreinte et fatigué. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Check the local interface MTU

cr0x@server:~$ ip link show dev eth0
2: eth0: <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

Sens : L’hôte croit que eth0 a un MTU de 1500. Ce n’est que le premier saut, pas le chemin complet.

Décision : Si vous vous attendez à un tunnel/overlay, vérifiez cette interface aussi. N’assumez pas que 1500 est sûr de bout en bout.

Task 2: List tunnel interfaces and their MTU

cr0x@server:~$ ip -d link show | egrep -A2 'mtu|wg0|tun0|gre|vxlan'
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Sens : WireGuard à 1420, VXLAN à 1450. L’overhead est au moins comptabilisé localement.

Décision : Si des utilisateurs se plaignent via VPN, 1420 peut encore être trop élevé selon l’underlay. Vérifiez avec des pings DF.

Task 3: DF ping to find maximum working MTU (IPv4)

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

--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Sens : Vous avez essayé d’envoyer un paquet IP de 1500 octets au total (1472 de payload + 28 d’en‑têtes). Le kernel dit que l’MTU est effectivement 1492 quelque part localement (souvent PPPoE).

Décision : Réduisez le payload jusqu’à réussite. Puis ajustez le MTU du tunnel ou le MSS clamp en conséquence.

Task 4: Binary search the working payload size

cr0x@server:~$ ping -M do -s 1464 -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1464(1492) bytes of data.
1472 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=13.4 ms
1472 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=13.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Sens : Le chemin supporte des paquets IP de 1492 octets (payload 1464 + 28 d’en‑têtes).

Décision : Si vous exécutez un VPN sur ce lien, soustrayez l’overhead du tunnel de 1492, pas de 1500.

Task 5: Check PMTUD ICMP messages in packet capture

cr0x@server:~$ sudo tcpdump -ni eth0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:44.912345 IP 203.0.113.1 > 192.0.2.10: ICMP unreachable - need to frag (mtu 1420), length 36

Sens : Vous recevez « need to frag » avec un indice MTU. PMTUD fonctionne au moins partiellement.

Décision : Si vous ne voyez jamais ces messages quand vous les attendez, suspectez des règles de pare‑feu qui suppriment ICMP type 3 code 4 (IPv4) ou ICMPv6 PTB.

Task 6: See if ICMP is blocked on your firewall (nftables)

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 icmp type echo-request accept
    ip6 nexthdr icmpv6 icmpv6 type echo-request accept
  }
}

Sens : Les echo requests sont autorisés, mais les autres types ICMP ne le sont pas. C’est la configuration classique « le ping marche, PMTUD meurt ».

Décision : Autorisez au minimum ICMP « fragmentation needed » (IPv4) et « packet too big » (IPv6), idéalement autorisez largement les types d’erreur ICMP pertinents.

Task 7: Confirm TCP MSS advertised on SYN packets

cr0x@server:~$ sudo tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn) != 0 and host 93.184.216.34' -c 3
12:05:01.100001 IP 192.0.2.10.51544 > 93.184.216.34.443: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
12:05:01.200002 IP 192.0.2.10.51545 > 93.184.216.34.443: Flags [S], seq 1234567891, win 64240, options [mss 1460,sackOK,TS val 112 ecr 0,nop,wscale 7], length 0
12:05:01.300003 IP 192.0.2.10.51546 > 93.184.216.34.443: Flags [S], seq 1234567892, win 64240, options [mss 1460,sackOK,TS val 113 ecr 0,nop,wscale 7], length 0

Sens : MSS 1460 implique une hypothèse MTU 1500 (1460 payload + 40 octets IPv4+TCP headers).

Décision : Si votre path MTU réel est 1492 ou plus bas (ou que le tunnel le réduit), vous devriez limiter MSS plus bas à la bordure pour que les points d’extrémité n’envoient pas de segments surdimensionnés.

Task 8: Apply MSS clamping (iptables) as a workaround

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | tail -n 3
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Sens : Vous réécrivez le MSS sur les paquets SYN en vous basant sur le MTU de route. Cela évite souvent les trous noirs même quand l’ICMP est bloqué.

Décision : Utilisez ceci quand vous ne pouvez pas réparer rapidement le filtrage ICMP. Planifiez quand même la vraie correction : MTU et politique ICMP correctes.

Task 9: Diagnose with tracepath (Linux)

cr0x@server:~$ tracepath 93.184.216.34
 1?: [LOCALHOST]                        pmtu 1500
 1:  192.0.2.1                           0.381ms
 2:  198.51.100.1                        1.992ms pmtu 1492
 3:  203.0.113.9                         6.110ms
 4:  93.184.216.34                      12.834ms reached
     Resume: pmtu 1492 hops 4 back 4

Sens : Le Path MTU est découvert comme 1492 au saut 2. C’est précieux et actionnable.

Décision : Si tracepath ne parvient pas à découvrir le PMTU (reste à 1500 de manière suspecte), suspectez un ICMP PTB/frag-needed bloqué ou un problème de chemin asymétrique.

Task 10: Check the route MTU hint in Linux

cr0x@server:~$ ip route get 93.184.216.34
93.184.216.34 via 192.0.2.1 dev eth0 src 192.0.2.10 uid 1000
    cache mtu 1492

Sens : Le cache de route du kernel croit que le PMTU est 1492 pour cette destination.

Décision : Si les applications se bloquent encore, le problème peut être ailleurs (inspection TLS, proxy), ou le PMTU diffère pour d’autres destinations/chemins.

Task 11: Validate IPv6 PMTUD basics

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2606:4700:4700::1111
PING 2606:4700:4700::1111(2606:4700:4700::1111) 1452 data bytes
1460 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=57 time=14.1 ms
1460 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=57 time=14.0 ms

--- 2606:4700:4700::1111 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Sens : De gros paquets IPv6 passent avec la sémantique DF (IPv6 ne fait pas de fragmentation par les routeurs). Bon signe.

Décision : Si IPv6 échoue uniquement pour des tailles plus grandes, vérifiez le filtrage ICMPv6 type 2 (Packet Too Big) sur les pare‑feu.

Task 12: Identify container/CNI MTU mismatch (Kubernetes node)

cr0x@server:~$ ip link show dev cni0
9: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 0a:58:0a:f4:00:01 brd ff:ff:ff:ff:ff:ff
cr0x@server:~$ ip link show dev vxlan.calico
7: vxlan.calico: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default

Sens : Le bridge est à 1500 mais VXLAN est à 1450. Les pods pourraient essayer d’utiliser 1500 et se brûler une fois encapsulés.

Décision : Réglez le MTU CNI/bridge pour correspondre à l’MTU effectif de l’overlay (souvent 1450) afin que les pods ne génèrent jamais de trames trop grandes.

Task 13: Confirm whether PMTUD is black-holed by testing a big TCP transfer

cr0x@server:~$ curl -I --max-time 10 https://example.com/
HTTP/2 200
content-type: text/html
server: envoy

cr0x@server:~$ curl --max-time 10 -o /dev/null -sS https://example.com/largefile.bin
curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

Sens : La petite requête fonctionne ; le gros transfert se bloque. Pas une preuve absolue, mais un signal fort de MTU/fragmentation.

Décision : Lancez immédiatement DF ping / tracepath et inspectez le filtrage ICMP. Ne perdez pas une heure sur des théories de chiffrement TLS.

Task 14: Observe retransmissions and “stuck” large segments

cr0x@server:~$ sudo ss -ti dst 93.184.216.34:443 | sed -n '1,20p'
ESTAB 0 0 192.0.2.10:51544 93.184.216.34:443
	 cubic wscale:7,7 rto:204 rtt:52.3/1.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:3456 bytes_received:1200 segs_out:45 segs_in:38 retrans:8/12

Sens : Des retransmissions se produisent. MSS est 1460, PMTU semble 1500, mais des tests antérieurs suggéraient un path MTU plus bas — quelque chose est incohérent.

Décision : Suspectez que l’ICMP « too big » n’est pas reçu par cet hôte (ou filtrage asymétrique). Implémentez le clamp MSS et réparez la politique ICMP.

Trois mini-récits d’entreprise du terrain

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

L’entreprise avait une configuration hybride : bureaux on‑prem, un VPC cloud, et un tunnel IPsec « simple » entre eux. Tout le monde supposait que le tunnel était un tuyau transparent. Il avait été installé des années auparavant, « fonctionnait », et ce n’était le sujet préféré de personne.

Puis une nouvelle application interne a été déployée derrière un reverse proxy dans le cloud. Les utilisateurs d’un bureau ont signalé que la page de connexion se chargeait, mais après saisie des identifiants le navigateur tournait indéfiniment. L’équipe applicative ne voyait aucune erreur. Les métriques du load balancer cloud semblaient normales. Le support a pratiqué le rituel classique : vider le cache, essayer un autre navigateur, redémarrer l’ordinateur. Rien de cohérent.

Un SRE a finalement reproduit le problème en se connectant via le réseau de ce bureau spécifique. Le handshake TCP a réussi. TLS a commencé. Puis la réponse est morte en vol. Le détail clé : ce bureau avait récemment migré vers un nouveau service ISP utilisant PPPoE. Leur pare‑feu edge supposait encore 1500, et l’overhead IPsec faisait dépasser les paquets le vrai path MTU.

La mauvaise hypothèse était simple : « Ethernet c’est 1500, donc le chemin est 1500. » Le correctif a été tout aussi simple : ajuster le MTU du tunnel et autoriser les bons types ICMP. Un MSS clamp temporaire a stabilisé les choses immédiatement. L’action postmortem était ennuyeuse et essentielle : documenter le budget MTU effectif par lien et par tunnel, et le valider lors des changements de fournisseur.

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

Une autre organisation a décidé « d’optimiser les performances » dans leur datacenter en activant les jumbo frames end‑to‑end. Ils avaient du trafic de stockage, du vMotion, des backups, le classique. Sur le papier c’était propre : moins de paquets, moins d’interruptions, débit plus élevé. L’équipe réseau l’a déployé progressivement et cela paraissait bon — à l’intérieur du datacenter.

Puis est survenu un changement anodin : une nouvelle paire de pare‑feux en bordure, aussi configurée pour les jumbo frames sur les interfaces internes. L’hypothèse était que « plus grand c’est mieux » et que tout le monde supportait. Sauf un segment : un ancien appliance de load balancer dans une baie distante qui n’avait jamais été mis à jour et était toujours en 1500.

La plupart des services n’ont pas remarqué. C’est l’astuce des bugs MTU : le trafic de contrôle petit passait. Les checks de santé étaient minuscules. Le load balancer a passé certaines requêtes. Mais de grosses réponses et certains enregistrements TLS ont disparu dans l’abîme. Le pattern de panne était surréaliste : « Le site marche pour moi sauf si je clique sur l’onglet rapports. »

L’optimisation qui a mal tourné n’était pas les jumbo frames elles‑mêmes. C’était la croyance que l’on peut changer l’MTU comme un réglage cosmétique. Ce n’est pas le cas. L’MTU est un contrat, et vous ne pouvez pas renégocier unilatéralement des contrats. Ils ont réparé cela en imposant la cohérence MTU par domaine L2, en ajoutant des contrôles automatisés, et en refusant de mélanger 1500 et 9000 sans une passerelle délibérée.

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

Une fintech exploitait plusieurs concentrateurs VPN pour les employés distants. Rien d’exotique : split tunnel pour certains services, tunnel complet pour d’autres. Ils avaient une règle de changement qui semblait douloureusement conservatrice : tout nouveau profil de tunnel doit inclure un test MTU et une règle MSS clamp « connue‑bonne » stockée, même s’ils ne l’activaient pas par défaut.

Lors d’une panne de fournisseur, ils ont basculé un endpoint VPN vers un chemin de transit de secours. Soudain, un petit pourcentage d’utilisateurs ne pouvaient plus accéder à quelques applications SaaS. La plupart des utilisateurs allaient bien. Les tickets helpdesk étaient confus et contradictoires parce que c’est ce que font les pannes sélectives.

Le SRE de garde a sorti le runbook, exécuté les tests DF ping depuis un hôte de test derrière le chemin de basculement, et confirmé que l’MTU effectif avait diminué. Ils ont activé le MSS clamp pré‑approuvé pour ce profil VPN et clôturé l’incident rapidement, sans débattre des politiques de pare‑feu en pleine crise.

Plus tard ils ont tout de même fait le « vrai correctif » (alignement des politiques ICMP et réglages MTU corrects), mais la pratique ennuyeuse — avoir un workaround testé et prêt à activer — a transformé une énigme nocturne en un incident court avec une timeline claire.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le ping marche, donc le réseau est OK » → Echo ICMP autorisé, PMTUD ICMP bloqué → autoriser les bons types ICMP

Symptôme : le ping réussit, mais le HTTPS se bloque ou les gros téléchargements échouent.

Cause racine : Le pare‑feu autorise echo‑request/reply mais supprime ICMP « fragmentation needed » (IPv4 type 3 code 4) et/ou ICMPv6 Packet Too Big.

Correctif : Permettre les ICMP liés à PMTUD. Si vous ne pouvez pas, clamppez le MSS TCP à la bordure.

2) « Le VPN est up, donc il transporte le trafic normalement » → overhead du tunnel non budgété → réduire le MTU du tunnel et/ou clamp MSS

Symptôme : SSH fonctionne, scp se bloque ; certaines applis Web se chargent partiellement.

Cause racine : L’overhead IPsec/GRE/WireGuard réduit l’MTU effectif. Les points d’extrémité continuent d’envoyer des MSS basés sur 1500.

Correctif : Définir le MTU du tunnel sur une valeur sûre (souvent 1380–1420 selon la pile) et valider avec des pings DF. Ajouter un clamp MSS si nécessaire.

3) « On a activé les jumbo frames, rien n’a explosé immédiatement » → MTU mixées dans un même domaine L2 → imposer une MTU cohérente par segment

Symptôme : échecs intermittents, souvent dépendants de la taille ; monitoring majoritairement vert.

Cause racine : Certains liens/équipements à 9000, d’autres à 1500 ; des trous noirs apparaissent aux frontières.

Correctif : Standardiser l’MTU par VLAN/domaine L2. Là où il faut interconnecter, router entre domaines et clamp/fragmenter de façon appropriée.

4) « C’est un bug applicatif » → TCP retransmet, le navigateur attend → prouver avec des tests de taille de paquets

Symptôme : seules certaines pages ou fournisseurs SaaS échouent ; les ingénieurs se disputent sur Slack.

Cause racine : Grands segments abandonnés à cause d’un échec PMTUD ; l’application subit juste un blocage.

Correctif : Exécuter tracepath et ping DF ; capturer les ICMP PTB/frag‑needed ; corriger l’ICMP ou clamp MSS.

5) « IPv6 est optionnel » → ICMPv6 PTB bloqué → corriger la politique du pare‑feu pour IPv6

Symptôme : connexions IPv6 qui se bloquent pour certains sites ; le fallback IPv4 masque parfois le problème.

Cause racine : Bloquer ICMPv6 casse PMTUD ; IPv6 en dépend.

Correctif : Autoriser les messages d’erreur ICMPv6, y compris Packet Too Big ; valider avec ping6 -M do.

6) « Les containers ne sont que des processus » → MTU CNI incorrect pour l’overlay → régler le MTU pod/bridge sur une valeur sûre pour l’underlay

Symptôme : le nœud atteint les sites externes, les pods non (ou sont instables).

Cause racine : L’overlay ajoute de l’encapsulation ; si les pods utilisent 1500, ils dépassent l’underlay MTU après encapsulation.

Correctif : Configurer le MTU CNI (souvent 1450 pour VXLAN sur un underlay 1500, mais validez). Déployez prudemment ; cela affecte le réseau des pods.

Listes de contrôle / plan étape par étape

Checklist incident : quand « certains sites ne se chargent pas » touche la production

1. Reproduire sur le chemin : tester depuis le même segment réseau/VPN que les utilisateurs affectés.
2. Faire un test DF ping de dimensionnement : déterminer la taille maximale de paquet fonctionnelle vers une IP externe stable.
3. Exécuter tracepath : voir si le PMTU est découvert et où il descend.
4. Vérifier la politique ICMP du pare‑feu : confirmer que frag‑needed/PTB est autorisé, pas seulement echo.
5. Vérifier le MTU tunnel/overlay : comparer le MTU de la NIC physique, du tunnel, et des interfaces virtuelles.
6. Chercher des retransmissions : utiliser ss -ti et tcpdump pour confirmer des gros segments répétés et l’absence d’ICMP.
7. Appliquer un workaround sûr : clamp MSS à la bordure appropriée si vous avez besoin d’un soulagement immédiat.
8. Vérifier avec un gros transfert : curl sur un objet volumineux, scp d’un fichier, ou tester un site connu problématique.
9. Noter ce qui a changé : changement de fournisseur, nouveau pare‑feu, nouvelle config CNI, nouvelle politique SD‑WAN — les bugs MTU adorent les fenêtres de changement.

Checklist gestion des changements : prévenir les bugs MTU avant qu’ils n’existent

1. Définir des domaines MTU : par VLAN, par lien WAN, par type de tunnel. Ne mélangez pas 1500 et 9000 à la légère.
2. Budgéter l’overhead : documenter l’overhead d’encapsulation pour chaque tunnel/overlay dans votre environnement.
3. Standardiser le MTU CNI : le définir explicitement ; ne laissez pas les valeurs par défaut dériver entre clusters.
4. Revoir la politique ICMP : autoriser les types ICMP liés à PMTUD. Traitez‑les comme du trafic de fiabilité, pas comme du « bruit ».
5. Avoir un plan MSS clamp testé : savoir où l’appliquer et comment le rollbacker.
6. Automatiser la vérification : exécuter des checks DF ping/tracepath programmés depuis des segments réseau clés et alerter sur les changements de PMTU.
7. Documenter les valeurs « connues bonnes » : stocker les réglages MTU/MSS dans l’infrastructure‑as‑code et dans les runbooks.

Table de décision : quoi corriger, dans quel ordre

• Si ICMP PTB/frag‑needed est bloqué : corriger la politique du pare‑feu d’abord ; clamp MSS en solution d’attente.
• Si le MTU du tunnel est supérieur au budget de l’underlay : abaisser le MTU du tunnel ; retester ensuite. Ne comptez pas seulement sur le MSS clamp sauf si nécessaire.
• Si des jumbo frames sont impliquées : vérifiez chaque saut qui doit les supporter. Si vous ne pouvez pas garantir cela, gardez les jumbo frames dans une zone contrôlée et routez à la frontière.
• Si seuls les pods cassent : corrigez la configuration MTU CNI/overlay ; ne « résolvez » pas cela par des sysctls random sur les nœuds.

FAQ

1) Pourquoi seuls certains sites échouent, pas tout ?

Parce que seuls certains flux génèrent des paquets suffisamment gros pour dépasser votre path MTU réel. Les petites requêtes fonctionnent ; de gros enregistrements TLS, en‑têtes ou réponses ne passent pas.

2) Si PMTUD existe, pourquoi est‑ce encore un problème ?

PMTUD nécessite un retour ICMP. Beaucoup de réseaux bloquent exactement les messages ICMP dont PMTUD a besoin, créant des trous noirs. Le mécanisme est correct ; la réalité opérationnelle est désordonnée.

3) Bloquer l’ICMP est‑il vraiment « plus sûr » ?

Pas dans un sens moderne utile. Bloquer sélectivement l’ICMP casse les diagnostics et des fonctions de base (surtout en IPv6). Une bonne sécurité repose sur un filtrage stateful et le principe du moindre privilège, pas sur le sabotage du plan de contrôle.

4) Dois‑je simplement clamp MSS partout et oublier ?

Non. Le clamp MSS est un contournement légitime aux frontières de tunnels et d’edge, mais le clamp généralisé peut masquer des problèmes sous‑jacents et réduire les performances inutilement. Réparez d’abord l’ICMP et la justesse du MTU ; clamppez là où c’est justifié.

5) Quel MTU dois‑je mettre pour WireGuard ?

Il n’y a pas de nombre universel. 1420 est courant car cela fonctionne souvent sur des underlays 1500 typiques, mais PPPoE, des tunnels supplémentaires ou des particularités fournisseur peuvent exiger plus bas. Mesurez avec des pings DF et ajustez.

6) Quel est l’impact sur HTTP/3 et QUIC ?

QUIC fonctionne sur UDP et dépend toujours du path MTU. Le comportement de fragmentation diffère, mais le problème central reste : les paquets surdimensionnés sont abandonnés. Les stacks QUIC utilisent souvent une logique semblable à PMTUD, et le filtrage ICMP peut toujours nuire.

7) Mon FAI dit que leur MTU est 1500. Pourquoi tracepath montre 1492 ?

Parce qu’une portion de votre chemin (souvent PPPoE ou autre encapsulation) réduit l’MTU effectif. La déclaration « MTU du FAI » concerne généralement un segment, pas votre chemin end‑to‑end.

8) Les problèmes MTU peuvent‑ils ressembler à des problèmes DNS ?

Oui, indirectement. Si des réponses DNS sont volumineuses (DNSSEC, beaucoup d’enregistrements) et que le chemin gère mal la fragmentation ou bloque l’ICMP, le DNS over UDP peut échouer sélectivement. Mais « certains sites ne se chargent pas » est plus souvent lié au MTU/TCP/TLS.

9) Quelle est la mitigation la plus sûre immédiatement pendant un incident ?

Activez le MSS clamp sur l’équipement de bord qui achemine le trafic vers le tunnel/chemin problématique, puis validez avec des transferts volumineux. Après avoir éteint l’incendie, corrigez la politique ICMP et les réglages MTU.

10) Comment prouver que c’est le MTU à une équipe sceptique ?

Montrez un avant/après : taille maximale DF ping, un tracepath montrant la chute de PMTU, et une capture de paquets où de gros segments sont retransmis sans retour d’ICMP PTB. Puis appliquez le MSS clamp et démontrez que le problème disparaît.

Prochaines étapes que vous pouvez réellement faire

Les problèmes MTU ne sont pas glamour. Ils ne sont même pas intéressants de façon amusante. Ils sont intéressants dans le registre « pourquoi l’ordinateur du CEO est le seul qui ne peut pas charger la paie ».

Faites ceci ensuite, dans cet ordre :

1. Ajoutez les checks MTU/PMTU à votre mémoire musculaire d’incident : DF ping et tracepath doivent être aussi routiniers que vérifier le DNS.
2. Corrigez la politique ICMP délibérément : autorisez les ICMP liés à PMTUD (frag‑needed IPv4, packet‑too‑big IPv6). Arrêtez de célébrer « le ping marche » comme preuve de quoi que ce soit.
3. Inventoriez les tunnels et overlays : listez où l’overhead est ajouté et définissez des MTU explicites là‑dessus. Les valeurs par défaut ne sont pas une stratégie.
4. Gardez le MSS clamp prêt : traitez‑le comme un extincteur — testé, placé en bordure, et utilisé quand nécessaire.
5. Documentez les domaines MTU : surtout si vous utilisez des jumbo frames. Faites des frontières MTU mixtes explicites et routées, pas accidentelles.

Si votre organisation entend « certains sites ne se chargent pas » et commence immédiatement à débattre des navigateurs, vous n’avez pas besoin de meilleurs navigateurs. Vous avez besoin d’une meilleure hygiène MTU.