Réseau : problèmes de MTU qui ressemblent à « Internet lent » (résoudre en 15 minutes)

MTU en termes clairs (et pourquoi ça vous trompe)

MTU est le Maximum Transmission Unit : la taille maximale d’un paquet (en octets) qu’un lien transporte sans fragmentation.
Sur un réseau Ethernet typique, c’est 1500 octets. Si vous utilisez PPPoE, c’est souvent 1492. Si vous vivez le rêve des jumbo frames, ça peut être 9000.
Si vous encapsulez dans un tunnel à l’intérieur d’un autre tunnel au‑dessus d’un overlay, soustrayez les en‑têtes jusqu’à revenir à la réalité.

Le piège est que TCP n’envoie pas des « paquets » isolés. Il envoie un flux. Le système d’exploitation segmente ce flux, et le réseau segmente ces segments en trames. Quand le MTU est faux, vous ne voyez pas « erreur MTU ». Vous voyez des retransmissions, des blocages,
des échecs asymétriques et des timeouts qui ressemblent à de la congestion. Parfois vous pouvez charger du texte mais pas des images. Parfois la page de login s’affiche mais la requête POST se bloque. Parfois une seule direction est cassée parce qu’un seul pare‑feu
a supprimé le message ICMP dont vous aviez besoin.

Une défaillance MTU nette est évidente : les gros paquets ne passent jamais. Mais dans la nature, les échecs MTU deviennent souvent des « PMTUD black holes », où le réseau devrait signaler à l’émetteur de réduire la taille des paquets (via ICMP « Fragmentation Needed »),
mais un appareil bloque ces messages ICMP. L’émetteur continue d’essayer des gros paquets, ils sont rejetés, TCP retransmet et votre utilisateur continue de dire « lent ».

Une citation à garder en tête pendant le dépannage : idée paraphrasée — Richard Cook (chercheur en sécurité/opérations) :
Les systèmes ont tendance à sembler corrects jusqu’à ce qu’ils ne le soient plus, parce que le succès cache la complexité qui rend la défaillance possible.
Les problèmes de MTU sont exactement ce type d’échec : tout semble OK jusqu’à ce qu’une taille de charge utile dépasse la ligne invisible.

Petite blague #1 : les bugs MTU sont comme des paquets en « quiet quitting » — ils arrivent, font le minimum, puis disparaissent quand le travail devient sérieux.

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

Quand vous avez 15 minutes et un pager, il vous faut une séquence qui restreint rapidement le périmètre. Ne « tunez » pas d’abord.
Ne redémarrez pas d’abord. Prouvez où ça casse.

Premier : confirmer que c’est dépendant de la taille

• Le trafic petit fonctionne‑t‑il de façon fiable (DNS, petites réponses HTTP, bannière SSH) tandis que les gros transferts se bloquent ?
• Est‑ce que ping avec DF (don’t fragment) échoue à certaines tailles ?
• Voyez‑vous des retransmissions TCP et des connexions « coincées » pendant des uploads/downloads ?

Deuxième : identifier le segment de chemin qui change le MTU

• VPN, GRE, IPsec, WireGuard, réseaux overlay, MPLS, PPPoE, transit gateways cloud, load balancers.
• Trouvez où l’encapsulation se produit. L’overhead réduit le MTU effectif.
• Vérifiez si un pare‑feu bloque ICMP type 3 code 4 (« fragmentation needed »). C’est un classique.

Troisième : appliquer la mitigation la moins risquée

• Clamp TCP MSS à la périphérie (pansement temporaire, souvent sûr).
• Définir le MTU de l’interface correctement sur les extrémités du tunnel (correctif permanent si vous contrôlez les deux côtés).
• Autoriser les bons ICMP pour PMTUD (correctif permanent, mais à coordonner avec les équipes sécurité).

L’objectif n’est pas un « MTU parfait ». L’objectif est « arrêter l’hémorragie sans créer un nouvel incident ».

Faits intéressants & contexte historique

• Le MTU 1500 d’Ethernet est devenu le défaut quasi universel tôt, en partie à cause des compromis matériel et mémoire dans les années 1980–1990.
• IPv4 permet aux routeurs de fragmenter les paquets (sauf si DF est positionné), mais la fragmentation a un coût en performance et fiabilité, donc les piles modernes évitent autant que possible.
• Les routeurs IPv6 ne fragmentent pas en transit ; l’émetteur doit utiliser PMTUD. Cela rend les messages ICMPv6 « Packet Too Big » critiques pour le fonctionnement.
• PPPoE utilise communément MTU 1492 à cause de son overhead d’encapsulation ; ces « 8 octets manquants » suffisent à casser des chemins si PMTUD est bloqué.
• Les jumbo frames (souvent MTU 9000) peuvent réduire la charge CPU et augmenter le débit sur des LANs de confiance, mais un seul saut non‑jumbo peut créer des échecs partiels bizarres.
• Les PMTUD black holes ont été largement documentés dans les années 1990–2000 quand les pare‑feux ont commencé à bloquer ICMP sans comprendre son usage.
• TCP MSS n’est pas MTU : MSS est la taille de charge utile, MTU inclut les en‑têtes. Les gens confondent et « corrigent » le mauvais chiffre.
• Les piles d’encapsulation s’additionnent vite : VXLAN/Geneve, plus IPsec, plus en‑têtes fournisseur cloud peuvent grignoter des centaines d’octets du MTU effectif.
• Les datacenters standardisent sur 1500 pour une raison : l’interopérabilité bat la performance théorique. La plupart des incidents naissent d’un « on va juste changer le MTU ».

À quoi ressemble la douleur MTU en production

Symptômes classiques

• Certaines pages web se chargent, d’autres se bloquent (souvent pendant le handshake TLS ou pour de grosses réponses).
• Le VPN se connecte, mais partages de fichiers et appels API lourds s’arrêtent.
• SSH interactif fonctionne, mais scp est terriblement lent ou gèle.
• Noeuds Kubernetes Ready, mais pull d’images conteneur timeoutent.
• HTTP fonctionne, HTTPS instable (tailles d’enregistrements TLS, messages de handshake plus volumineux, ou chemin différent via un CDN).
• Les tests de débit montrent beaucoup de retransmissions ; la latence semble correcte.

Pourquoi c’est trompeur

Avec des problèmes de MTU, vous pouvez avoir une latence parfaite et de bonnes performances pour les petits paquets. Un monitoring qui vérifie « ping fonctionne » passera au vert.
Vos contrôles synthétiques peuvent toucher un petit endpoint et le déclarer sain. Pendant ce temps, les vrais utilisateurs tentent d’uploader un PDF ou de récupérer une couche de conteneur et obtiennent un timeout.

La manière la plus rapide de vous perdre est de traiter cela comme un problème générique de « réseau lent » et de commencer à tuner la congestion TCP,
les buffers ou le QoS. Les échecs MTU ne sont pas un problème d’optimisation de débit. Ce sont des problèmes de correction.

Tâches pratiques (commandes, ce que signifie la sortie, décisions)

Ce sont des tâches adaptées à la production que vous pouvez lancer depuis un hôte Linux. Utilisez un hôte de test de chaque côté du point de rupture suspecté (client et serveur, ou deux pods, ou deux VM).
Le but est de mesurer, pas de deviner.

Tâche 1 : Vérifier le MTU des interfaces et repérer les décalages évidents

cr0x@server:~$ ip -d link show
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
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : eth0 est à 1500, wg0 est à 1420 (choix courant pour WireGuard). Ce n’est pas faux en soi.

Décision : Si vous voyez une interface de tunnel avec un MTU plus grand que ce que l’underlay peut supporter, c’est suspect. Confirmez avec des pings DF ensuite.

Tâche 2 : Confirmer le comportement PMTUD avec un ping DF (IPv4)

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.
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492
ping: local error: message too long, mtu=1492

--- 203.0.113.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2044ms

Signification : Votre hôte sait déjà que le MTU sortant est 1492 sur ce chemin/interface. Il a refusé d’envoyer des paquets de 1500 octets.

Décision : Si l’application attend 1500 mais que le chemin est à 1492, il vous faut clamp MSS ou corriger le MTU sur le bord du tunnel/PPPoE.

Tâche 3 : Recherche binaire de la plus grande taille de paquet fonctionnelle

cr0x@server:~$ for s in 1472 1464 1452 1440 1432; do echo "size=$s"; ping -M do -s $s -c 1 203.0.113.10 | tail -n 2; done
size=1472
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
size=1464
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1452
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1440
1 packets transmitted, 1 received, 0% packet loss, time 0ms
size=1432
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Signification : 1464 fonctionne, 1472 ne fonctionne pas. Cela suggère un MTU effectif de 1492 (parce que 1464 + 28 octets d’en‑têtes ICMP/IP ≈ 1492).

Décision : Arrêtez de débattre de la théorie. Définissez MTU/MSS pour correspondre à ce qui fonctionne réellement.

Tâche 4 : Vérifier la route MTU / indices du cache PMTU

cr0x@server:~$ ip route get 203.0.113.10
203.0.113.10 via 198.51.100.1 dev ppp0 src 198.51.100.20 uid 1000
    cache mtu 1492

Signification : Linux a un PMTU mis en cache de 1492 pour cette destination sur ppp0.

Décision : Si le PMTU est anormalement bas, cherchez où l’encapsulation intervient (PPPoE, VPN, overlay). Si le PMTU est élevé mais que les paquets se bloquent, ICMP peut être bloqué et le cache ne se met pas à jour.

Tâche 5 : Rechercher retransmissions et « blocages » sur une connexion réelle

cr0x@server:~$ ss -ti dst 203.0.113.10:443
ESTAB 0 0 198.51.100.20:53124 203.0.113.10:443
	 cubic wscale:7,7 rto:204 rtt:38.5/4.2 ato:40 mss:1460 pmtu:1500 rcvmss:536 advmss:1460 cwnd:10 bytes_acked:1543 bytes_received:2010 segs_out:35 segs_in:33 retrans:7/18

Signification : Les retransmissions sont non nulles et augmentent. pmtu:1500 peut être faux s’il y a un black hole. rcvmss:536 suggère aussi des bizarreries de chemin.

Décision : Si les retransmissions grimpent lors d’un transfert massif alors que le petit trafic est OK, suspectez MTU/PMTUD. Passez à la capture de paquets ou au clamp MSS.

Tâche 6 : Capturer les ICMP « fragmentation needed » (ou leur absence)

cr0x@server:~$ sudo tcpdump -ni any '(icmp and (icmp[0]=3 and icmp[1]=4)) or (icmp6 and ip6[40]=2)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

Signification : Pour IPv4 vous surveillez ICMP type 3 code 4. Pour IPv6 vous surveillez ICMPv6 type 2 (Packet Too Big).

Décision : Si vous reproduisez le problème et ne voyez aucun message ICMP PTB/frag-needed nulle part, un pare‑feu ou un middlebox peut les supprimer. Si vous en voyez, PMTUD fonctionne et vous devez plutôt vous concentrer sur un MTU/MSS local incorrect.

Tâche 7 : Reproduire avec curl et surveiller les blocages après « upload completely sent off »

cr0x@server:~$ curl -v --max-time 10 -o /dev/null https://203.0.113.10/large-object
*   Trying 203.0.113.10:443...
* Connected to 203.0.113.10 (203.0.113.10) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
> GET /large-object HTTP/1.1
> Host: 203.0.113.10
> User-Agent: curl/8.5.0
> Accept: */*
* Operation timed out after 10001 milliseconds with 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 10001 milliseconds with 0 bytes received

Signification : La connexion TCP et le handshake TLS peuvent réussir, puis le chemin de requête/réponse se bloque sur des paquets plus volumineux ou des tailles d’enregistrement spécifiques.

Décision : Confirmez avec un ping DF puis atténuez (clamp MSS ou corriger le MTU). Ne perdez pas une heure à « optimiser TLS ».

Tâche 8 : Mesurer le débit réel et la perte avec iperf3

cr0x@server:~$ iperf3 -c 203.0.113.10 -t 10 -i 1
Connecting to host 203.0.113.10, port 5201
[  5] local 198.51.100.20 port 45436 connected to 203.0.113.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.12 MBytes  26.2 Mbits/sec   28   61.5 KBytes
[  5]   1.00-2.00   sec  2.50 MBytes  21.0 Mbits/sec   31   52.3 KBytes
[  5]   2.00-3.00   sec  1.75 MBytes  14.7 Mbits/sec   44   43.1 KBytes
[  5]   3.00-4.00   sec  1.12 MBytes  9.40 Mbits/sec   56   32.8 KBytes
[  5]   4.00-5.00   sec  0.88 MBytes  7.38 Mbits/sec   61   26.9 KBytes
[  5]   0.00-10.00  sec  15.2 MBytes  12.8 Mbits/sec  472             sender
[  5]   0.00-10.00  sec  14.5 MBytes  12.1 Mbits/sec                  receiver

Signification : Les retransmissions sont élevées et la fenêtre de congestion s’effondre. Ce n’est pas normal pour un chemin stable.

Décision : Si les retransmissions corrèlent avec un MSS/MTU plus grand, clampez MSS et retestez. Si le chemin est réellement bruyant, le tuning MTU ne vous sauvera pas.

Tâche 9 : Vérifier les NIC offloads qui peuvent fausser les captures

cr0x@server:~$ ethtool -k eth0 | egrep 'tso|gso|gro|lro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off

Signification : Les offloads sont activés. C’est normal, mais cela peut faire apparaître dans tcpdump des paquets « géants » qui ne sont pas réellement envoyés sur le fil.

Décision : Ne « corrigez » pas le MTU sur la base d’une capture trompeuse. Si vous avez besoin de tailles de paquets propres pour le débogage, désactivez temporairement les offloads sur un hôte de test.

Tâche 10 : Désactiver temporairement les offloads sur un hôte de test (pour clarifier)

cr0x@server:~$ sudo ethtool -K eth0 tso off gso off gro off

Signification : Le noyau ne coalisera plus/segmentera plus de manières qui embrouillent vos outils de capture.

Décision : Ne faites cela que sur une machine de test ou pendant une fenêtre contrôlée. Les offloads peuvent être critiques pour la performance sur des hôtes chargés.

Tâche 11 : Vérifier que PMTUD IPv6 (ICMPv6 Packet Too Big) n’est pas bloqué

cr0x@server:~$ ping6 -c 2 -s 1452 -M do 2001:db8::10
PING 2001:db8::10(2001:db8::10) 1452 data bytes
ping: local error: message too long, mtu=1280
ping: local error: message too long, mtu=1280

--- 2001:db8::10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1023ms

Signification : Quelque chose sur le chemin (ou local) impose un MTU de 1280 (le minimum IPv6). C’est réel, mais aussi catastrophique pour la performance si inattendu.

Décision : Si le PMTU IPv6 s’effondre de façon inattendue, trouvez le tunnel/segment en cause. Ne désactivez pas IPv6 juste pour le plaisir des incidents récurrents.

Tâche 12 : Clamper TCP MSS avec iptables (mitigation rapide)

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

Signification : Pour les connexions TCP transférées, les paquets SYN seront réécrits pour que les pairs négocient un MSS qui correspond au PMTU découvert.

Décision : Utilisez ceci aux bordures (passerelles VPN, routeurs, pare‑feux) quand vous ne pouvez pas réparer rapidement le blocage ICMP ou le décalage MTU. Puis planifiez la correction réelle.

Tâche 13 : Clamper TCP MSS avec nftables (systèmes modernes)

cr0x@server:~$ sudo nft add table inet mangle
cr0x@server:~$ sudo nft 'add chain inet mangle forward { type filter hook forward priority mangle; policy accept; }'
cr0x@server:~$ sudo nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt mtu

Signification : Même idée : ajuster MSS basé sur le MTU de la route. La syntaxe varie selon la distro/noyau ; testez attentivement.

Décision : Préférez un jeu de règles connu et revu. Ne faites pas du freestyle nftables en production sauf si vous aimez aussi les outages de style freestyle.

Tâche 14 : Définir le MTU sur une interface (permanent quand correct)

cr0x@server:~$ sudo ip link set dev wg0 mtu 1380
cr0x@server:~$ ip link show wg0 | head -n 1
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1380 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

Signification : Vous réduisez le MTU du tunnel pour éviter de dépasser les limites de l’underlay après overhead.

Décision : Si vous contrôlez les deux extrémités, c’est souvent la correction la plus propre. Validez avec des pings DF à travers le tunnel et un transfert d’application réel.

Tâche 15 : Vérifier les compteurs du noyau pour la fragmentation et le stress de réassemblage

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl'
    0 fragments received ok
    0 fragments created
    12 packets reassembled ok
    3 packet reassembly failures

Signification : Les échecs de réassemblage peuvent montrer des problèmes de fragmentation sur le chemin ou des pertes de paquets interagissant avec des fragments.

Décision : La fragmentation est un signal d’alarme. Évitez‑la en définissant le MTU/MSS correct. Si vous voyez des échecs de réassemblage pendant la fenêtre d’incident, MTU est un suspect sérieux.

Tâche 16 : Valider le MTU de bout en bout depuis Kubernetes (réalité des overlays)

cr0x@server:~$ kubectl run -it --rm netdebug --image=busybox:1.36 -- sh
/ # ip link show eth0 | head -n 1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default
/ # ping -M do -s 1422 -c 1 10.96.0.1
PING 10.96.0.1 (10.96.0.1): 1422 data bytes
1430 bytes from 10.96.0.1: seq=0 ttl=64 time=0.632 ms

--- 10.96.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

Signification : Le MTU du pod est 1450 (courant dans les configurations VXLAN). Votre hypothèse « normal 1500 » est déjà fausse à l’intérieur du cluster.

Décision : Si les pods communiquent avec des services externes via des tunnels ou des gateways, tenez compte de l’overhead additionnel. Corrigez dans la config CNI ou utilisez un clamp MSS sur la gateway.

Modèles de correction qui fonctionnent (et pourquoi)

Modèle 1 : Rétablir PMTUD (la solution adulte)

PMTUD existe pour que les points d’extrémité s’adaptent. Quand ça fonctionne, vous obtenez des tailles de paquets maximales sans réglages manuels.
Quand c’est cassé, les gens commencent à coder en dur des MTU partout comme si c’était 1997.

La rupture typique est le filtrage d’ICMP. Pour IPv4, vous voulez autoriser ICMP type 3 code 4 vers l’émetteur.
Pour IPv6, ICMPv6 Packet Too Big est indispensable pour l’opération de base. Le bloquer n’est pas de la « sécurité ». C’est s’automutiler.

Que faire : autorisez les messages ICMP spécifiques, rate‑limitez raisonnablement et journalisez les suppressions. Si votre outil de sécurité impose des suppressions générales d’ICMP, négociez une exception avec des preuves : captures, retransmissions et un test clair avant/après.

Modèle 2 : Clamper TCP MSS aux frontières (le correctif pragmatique)

Le clamp MSS réécrit le SYN TCP pour que les deux côtés conviennent d’une taille de segment plus petite. C’est un palliatif pour les chemins où PMTUD est peu fiable, souvent à cause de middleboxes que vous ne contrôlez pas (réseau partenaire, opérateur, pare‑feu d’entreprise).

C’est aussi votre « fix en 15 minutes » le plus rapide car vous pouvez l’appliquer au bord sans toucher chaque hôte.
Inconvénients : n’aide que TCP, pas UDP. Cela peut aussi masquer le vrai problème assez longtemps pour qu’il réapparaisse lors du prochain changement topologique.

Modèle 3 : Définir le MTU correct sur tunnels et overlays (la correction structurelle)

Les tunnels réduisent le MTU effectif car ils ajoutent des en‑têtes. Si votre underlay est 1500 et que votre tunnel ajoute 60 octets d’overhead,
votre MTU de tunnel doit être 1440 ou moins si vous voulez éviter fragmentation/black holes.

La bonne valeur dépend du type d’encapsulation et des options (l’overhead IPsec ESP varie ; WireGuard a un overhead typique ; VXLAN ajoute le sien).
Ne mémorisez pas des nombres. Mesurez avec un ping DF à travers le tunnel, puis choisissez une valeur avec une petite marge de sécurité.

Modèle 4 : Arrêter de traiter les jumbo frames comme un trait de personnalité

Les jumbo frames peuvent être excellentes sur un domaine L2 contrôlé : réseaux de stockage, HPC, certains trafics est‑ouest.
Mais les jumbo frames à travers une infrastructure mixte, c’est là où les rêves deviennent des réunions CAB.

Si vous activez MTU 9000 sur certains switches et oubliez un hyperviseur vSwitch ou une interface de pare‑feu, vous avez créé
un mode d’échec qui ressemblera à « lenteur intermittente » pour toujours. Soit rendez les jumbo frames universelles sur ce segment,
soit ne le faites pas du tout.

Petite blague #2 : si vous activez les jumbo frames sans plan bout‑en‑bout, vous n’« optimisez pas le réseau », vous venez d’inventer un nouveau passe‑temps pour votre équipe d’astreinte.

Trois mini‑histoires d’entreprise (anonymisées, plausibles, techniquement exactes)

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

Une entreprise SaaS de taille moyenne avait une configuration hybride : utilisateurs au bureau sur une ligne ISP gérée, workloads dans le cloud public.
Ils ont déployé un nouvel appareil « secure web gateway ». Le plan de déploiement était simple : router le trafic corporate via l’appliance,
vérifier la navigation web, puis élargir le périmètre.

Le premier jour, le helpdesk a reçu un mélange de tickets étranges. Certains employés disaient « tout est lent ».
D’autres disaient « seuls les uploads sont cassés ». Quelques‑uns rapportaient que Slack allait bien, mais le CRM interne (derrière un VPN)
se bloquait au login. Les graphiques réseau semblaient normaux. Le CPU de la gateway était normal. Le vendor suggérait d’augmenter les buffers TCP. Classique.

La mauvaise hypothèse était subtile : l’équipe supposait que l’appliance était un simple forwarder L3/L4, et donc « MTU reste 1500 ».
En réalité, l’appliance établissait un tunnel IPsec vers un POP cloud pour inspection. Cela ajoutait de l’overhead. L’appliance acceptait toujours des paquets 1500 sur le LAN mais ne pouvait pas les forwarder sans fragmentation sur le côté tunnel.
Et le chemin du tunnel avait ICMP frag‑needed filtrés par un edge provider.

La correction n’a pas été héroïque. Ils ont reproduit le blocage avec des pings DF, ont vu que le MTU effectif était autour de 1410 à travers le nouveau chemin,
et ont appliqué un clamp MSS sur la gateway pour le trafic sortant. Immédiatement, les logins CRM ont cessé de timeouter. Puis ils ont planifié la
vraie correction : ajuster le MTU du tunnel et coordonner les autorisations ICMP avec le provider.

La leçon : « Ethernet c’est 1500 » n’est pas un fait ; c’est une valeur par défaut. Dès que vous tunnelisez, encapsulez ou traversez des équipements de sécurité managés,
le MTU devient un paramètre de conception, pas un détail.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une équipe plateforme de données voulait augmenter le débit de réplication entre deux datacenters. Ils poussaient de gros objets et voyaient une pression CPU
sur les hôtes aux pics. Quelqu’un a proposé les jumbo frames : monter MTU à 9000 sur le VLAN de stockage, réduire l’overhead par paquet, gagner.

Ils ont fait le changement sur les ToR et les serveurs de stockage. Les tests initiaux sur quelques hôtes étaient excellents. Le débit et la CPU s’amélioraient.
Ils ont célébré discrètement, car les célébrations bruyantes fâchent les dieux du réseau.

Deux semaines plus tard, une autre équipe a déplacé un cluster d’hyperviseurs dans ce même VLAN. Leur vSwitch était resté en MTU 1500.
Rien n’a explosé immédiatement. À la place, ils ont obtenu un bazar : certains VMs pouvaient monter le stockage mais gelaient intermittemment lors de gros reads.
Les backups ont commencé à timeouter. Quelques clients NFS se bloquaient sur des listings contenant de gros blobs de métadonnées.

Parce que beaucoup de petits paquets fonctionnaient encore, les équipes ont chassé des problèmes fantômes : « tuning NFS », « ZFS arc », « bug ESXi », « peut‑être le baies sont surchargées ».
Il a fallu un ping DF brutal depuis une VM pour révéler la vérité : la VM ne pouvait pas passer de paquets supérieurs à 1500, mais les serveurs de stockage émettaient des jumbo frames.
Quelque part au milieu, la fragmentation ou les drops se produisaient de façon incohérente selon le chemin et le comportement des offloads.

La correction a été ennuyeuse : soit rendre les jumbo frames réellement bout‑en‑bout (switches, hyperviseurs, vSwitches, NICs, endpoints de stockage),
soit revenir le VLAN à 1500 et accepter une CPU légèrement supérieure. Ils ont choisi un compromis : un segment de stockage jumbo dédié et isolé pour les hôtes capables,
et un segment MTU standard pour l’environnement mixte.

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

Une fintech gérait des dizaines de VPN site‑à‑site avec des partenaires. Ils avaient déjà été brûlés par des PMTUD black holes, donc leur politique était :
chaque nouveau tunnel doit être livré avec un test MTU effectif documenté et une règle MSS clamp explicite au bord VPN, validée par un transfert applicatif.
Pas « on pense que c’est OK ». Des preuves.

Un vendredi, un partenaire a changé de modèle de pare‑feu. Sans préavis. Soudain, les transferts de fichiers de règlements ont commencé à échouer de façon intermittente.
Le partenaire insistait sur le fait que rien n’avait changé « dans le VPN ». Leur monitoring disait que le tunnel était up. Tout le monde était techniquement correct mais opérationnellement inutile.

L’équipe fintech avait deux avantages. D’abord, ils avaient déjà un MSS clamp au bord, donc la plupart du trafic TCP continuait de fonctionner.
Ensuite, ils avaient un runbook standard : pings DF dans les deux sens, tcpdump pour ICMP, et une vérification rapide des MSS négociés sur une session TCP de test.
En une heure, ils avaient la preuve que ICMP frag‑needed ne revenait plus du côté partenaire.

Ils n’avaient pas besoin de redesigner le réseau pendant l’incident. Le workaround était déjà en place. Ils ont simplement resserré légèrement le MSS clamp
(en se basant sur le MTU effectif mesuré), rétabli la fiabilité des transferts, et envoyé au partenaire un court rapport appuyé par une capture.
Le partenaire a ensuite corrigé sa politique de pare‑feu pour autoriser les bons ICMP, et la fintech a levé la conservatisme additionnel.

La leçon : des contrôles ennuyeux—tests MTU documentés, MSS clamp par défaut aux bordures VPN, et comportements « connus bons » capturés—transforment des outages mystérieuses en maintenance de routine.

Erreurs courantes : symptôme → cause → correctif

1) « Certaines sites se chargent, d’autres se bloquent » → PMTUD black hole → autoriser ICMP / clamp MSS

Symptôme : Navigation web inconsistante ; grosses pages qui bloquent ; les petites fonctionnent.
Cause : Le path MTU est inférieur à l’hypothèse, et ICMP frag‑needed / packet‑too‑big est bloqué.
Correctif : Autoriser les messages ICMP spécifiques sur les pare‑feux ; en mitigation rapide, clampez TCP MSS à la gateway egress.

2) « Le VPN est up mais les transferts de fichiers stallent » → overhead de tunnel non pris en compte → réduire le MTU du tunnel

Symptôme : Petits pings et RDP/SSH fonctionnent ; SMB/NFS/HTTPS uploads gelés.
Cause : Overhead IPsec/WireGuard/GRE réduit le MTU effectif ; les endpoints essaient encore des paquets proches de 1500.
Correctif : Définir le MTU de l’interface tunnel à une valeur mesurée sûre ; clamp MSS sur la gateway VPN.

3) « Pull d’images Kubernetes timeout » → MTU d’overlay trop élevé → corriger le MTU CNI et la cohérence des nœuds

Symptôme : Les pods résolvent le DNS et atteignent de petits endpoints, mais le pull de grosses couches échoue.
Cause : MTU d’overlay CNI mal réglé par rapport à l’underlay, ou MTU mixte entre nœuds.
Correctif : Configurer le MTU CNI correctement (ex. 1450/1440 selon encapsulation) ; assurer la cohérence MTU des nœuds et vSwitches.

4) « Jumbo frames activées, freezes aléatoires » → pas end‑to‑end jumbo → soit universaliser soit revenir en arrière

Symptôme : Seuls certains hôtes/VM ont des problèmes ; souvent lors de gros transferts ; le monitoring indique « up ».
Cause : Un saut reste à 1500 (vSwitch, pare‑feu, NIC, switch intermédiaire).
Correctif : Valider le MTU à chaque saut ; si vous ne pouvez pas garantir cela, maintenez le segment à 1500.

5) « Captures montrent des trames énormes » → artefacts d’offload → désactiver les offloads pour le debug

Symptôme : tcpdump montre des paquets géants qui ne devraient pas exister ; les conclusions deviennent étranges vite.
Cause : TSO/GSO/GRO rendent les captures hôtes apparentées à des paquets surdimensionnés.
Correctif : Désactivez temporairement les offloads sur un hôte de test, ou capturez sur un switch/mirror port à la place.

6) « L’application UDP est cassée ; TCP OK après clamp MSS » → le clamp n’aide que TCP → tuner l’app ou abaisser le MTU

Symptôme : VoIP, jeu ou protocole UDP perso échouent alors que le web revient.
Cause : Le clamp MSS n’affecte pas UDP ; des datagrammes UDP peuvent dépasser le path MTU et être perdus.
Correctif : Réduire la taille des payloads UDP dans l’application, activer la fragmentation avec précaution (rarement idéal), ou abaisser le MTU sur l’interface/tunnel.

7) « IPv6 est instable ; IPv4 OK » → ICMPv6 PTB bloqué → autoriser ICMPv6 correctement

Symptôme : Hôtes dual‑stack montrent des blocages intermittents en IPv6 ; IPv4 fonctionne.
Cause : ICMPv6 Packet Too Big bloqué ; IPv6 ne peut pas compter sur la fragmentation routeur.
Correctif : Permettre les types ICMPv6 requis ; valider avec ping6 DF et tcpdump.

Listes de contrôle / plan pas à pas

Plan « arrêter l’hémorragie » en 15 minutes

1. Prouver la dépendance à la taille : lancer des pings DF avec tailles croissantes vers la destination en échec (Tâches 2–3).
2. Vérifier les MTU d’interface : underlay et interfaces tunnel (Tâche 1).
3. Vérifier le PMTU de route : ip route get pour un indice (Tâche 4).
4. Confirmer les retransmissions : ss -ti sur un flux actif (Tâche 5) et optionnellement iperf3 (Tâche 8).
5. Capturer ICMP PTB/frag‑needed : confirmer si les messages PMTUD existent ou disparaissent (Tâche 6).
6. Atténuer rapidement : clamper MSS à la bordure (Tâche 12 ou 13).
7. Vérifier avec du trafic réel : curl un gros objet, scp un fichier, pull une image conteneur (Tâche 7 + votre workload).
8. Noter le MTU mesuré qui fonctionne : ne comptez pas sur la mémoire ; votre futur vous est déjà fatigué.

Plan de correction permanent (celui qui prévient la récurrence)

1. Cartographier l’encapsulation : lister chaque segment tunnel/overlay et son overhead (VPN, VXLAN, Geneve, GRE, IP‑in‑IP).
2. Définir le MTU là où il doit être : interfaces tunnel et CNI à des valeurs qui tiennent l’underlay avec marge (Tâche 14).
3. Rétablir les signaux PMTUD : ajuster les politiques de pare‑feu pour autoriser ICMP type 3/4 (IPv4) et ICMPv6 PTB (IPv6).
4. Standardiser le clamp MSS aux bordures : garder cela comme défense en profondeur pour les réseaux partenaires que vous ne contrôlez pas.
5. Ajouter un contrôle synthétique qui transfère de vrais octets : pas seulement un ping ; quelque chose qui échoue quand le MTU échoue.
6. Documenter le MTU « connu bon » par segment : incluant qui le possède et quel processus de changement s’applique.

Ce qu’il faut éviter pendant un incident

• Ne pas « augmenter le MTU pour la performance » au hasard pour réparer une lenteur. C’est ainsi que vous transformez un incident partiel en panne totale.
• Ne pas désactiver l’ICMP de manière large. Si vous devez filtrer, faites‑le avec intention et autorisez les messages critiques pour PMTUD.
• Ne pas traiter un ping réussi comme preuve que le chemin est sain. Les bugs MTU adorent votre monitoring simpliste.

FAQ

1) Quelle est la différence entre MTU et MSS ?

MTU est la taille maximale d’un paquet IP sur un lien. MSS (Maximum Segment Size) est la taille maximale de la charge utile TCP.
MSS vaut approximativement MTU moins les en‑têtes IP+TCP. Corriger le MTU corrige tout ; clamp MSS ne corrige que TCP.

2) Pourquoi un décalage MTU ressemble‑t‑il à « internet lent » plutôt qu’à une panne ?

Parce que seules les tranches de paquets au‑dessus d’une certaine taille échouent. Les petites requêtes, ACKs, DNS et certains éléments de page fonctionnent.
Les grosses réponses, uploads ou messages protocolaires spécifiques se bloquent et retransmettent. Les humains interprètent les « retransmissions » comme « lent ».

3) Pourquoi bloquer l’ICMP est‑il un problème ? L’ICMP n’est‑il pas dangereux ?

Le blocage général est le problème. PMTUD dépend des erreurs ICMP pour informer les émetteurs des limites MTU.
Pour IPv6, ICMPv6 Packet Too Big est essentiel. Vous pouvez rate‑limiter et filtrer des types spécifiques, mais
« pas d’ICMP » casse le trafic réel de façon non évidente.

4) Comment choisir le bon MTU pour un tunnel VPN ?

Mesurez. Commencez par le MTU de l’underlay (souvent 1500), soustrayez l’overhead d’encapsulation, puis validez avec des pings DF à travers le tunnel.
Ajoutez une marge de sécurité si le chemin inclut du matériel fournisseur inconnu. Si vous ne pouvez pas mesurer de façon fiable, clamp MSS au bord.

5) Le clamp MSS réduit‑il la performance ?

Cela peut légèrement augmenter la charge CPU et le nombre de paquets car vous envoyez plus de segments plus petits. Mais cela améliore généralement le débit réel
comparé à une situation de black hole où vous retransmettez des segments larges à répétition. Pensez « moins élégant, plus fonctionnel ».

6) Les problèmes MTU peuvent‑ils affecter une seule direction ?

Oui. Un côté peut renvoyer ICMP PTB tandis que l’autre le bloque. Ou une seule direction traverse un tunnel.
L’asymétrie est courante dans les réseaux d’entreprise avec plusieurs chemins de sortie et des appliances de sécurité « aidantes ».

7) Pourquoi IPv6 échoue parfois alors qu’IPv4 fonctionne ?

IPv6 s’appuie sur PMTUD parce que les routeurs ne fragmentent pas en transit. Si ICMPv6 PTB est bloqué, les flux IPv6 peuvent se bloquer
sur de plus gros paquets. IPv4 peut parfois s’en sortir grâce à la fragmentation sur certains chemins, masquant le problème.

8) Les jumbo frames valent‑elles le coup ?

Elles valent le coup sur des segments strictement contrôlés où chaque saut est vérifié (réseaux de stockage, domaines est‑ouest spécifiques).
Elles ne valent pas le coup à travers une infrastructure hétérogène ou des réseaux partenaires. Si vous ne pouvez pas garantir le MTU bout‑en‑bout, restez à 1500.

9) Comment tester le MTU sans casser la production ?

Utilisez des pings DF vers une cible connue, lancez‑les hors‑pic, et ne changez pas le MTU sur des interfaces chargées sans précaution.
Pour les captures, désactivez les offloads seulement sur un hôte de test. Préférez le clamp MSS en bordure comme mitigation réversible.

10) Quel est le signe le plus rapide que c’est le MTU et non la congestion ?

Un ping DF qui échoue à un seuil de taille constant, plus des retransmissions TCP pendant des gros transferts alors que les petites requêtes réussissent.
La congestion ne crée pas habituellement une falaise nette liée à la taille. Les problèmes MTU le font.

Conclusion : prochaines étapes à effectuer aujourd’hui

Les incidents MTU ne se présentent pas avec un panneau. Ils se déguisent en « le réseau est lent » et gaspillent votre après‑midi.
La correction est rarement compliquée, mais elle est spécifique : mesurez la vraie taille de paquet qui passe, identifiez où le chemin a rétréci,
puis restaurez PMTUD ou clampez MSS jusqu’à ce que vous puissiez.

Prochaines étapes qui rapportent tout de suite :

• Ajoutez une étape de runbook : test de taille DF ping + vérification ss -ti des retransmissions avant que quiconque touche au « tuning de performance ».
• Standardisez le clamp MSS sur les passerelles VPN/edge comme filet de sécurité pour les réseaux partenaires.
• Auditez les règles de pare‑feu pour ICMP frag‑needed (IPv4) et Packet Too Big (IPv6). Autorisez‑les avec des limites de taux et du logging raisonnables.
• Documentez le MTU par segment (underlay, tunnels, overlays). Traitez‑le comme une dépendance SLO, pas comme une trivia.

Faites cela, et la prochaine fois que quelqu’un dira « internet est lent », vous aurez une réponse concrète en quelques minutes—plutôt qu’un vague ressenti et un café grandissant.