Ubuntu 24.04 : les jumbo frames cassent « seulement certains » trafics — comment tester et corriger le MTU en toute sécurité

octobre 28, 2025 • février 3, 2026 • Lecture : 30 min • Views: 7

Cet article vous a aidé ?

Vous passez le MTU à 9000 parce que le stockage est « lent », et soudain le monde devient étrange : SSH reste correct, le DNS répond encore, mais « certains » sites HTTPS se bloquent,
certains appels d’API restent pendants indéfiniment, et votre trafic Ceph ou NFS se transforme en une représentation dramatique de En attente d’ACK.

C’est la signature d’une défaillance MTU partielle : les gros paquets meurent silencieusement quelque part sur le chemin, tandis que les petits paquets passent et vous font douter
de vos choix de carrière. Réglons ça comme des adultes : mesurer, isoler, changer une chose à la fois et garder un retour arrière facile.

Pourquoi les jumbo frames cassent « seulement certains » trafics

Le fait que « seulement certains trafics » soient cassés n’est pas un paradoxe. C’est ce qui arrive quand le réseau peut transporter des trames petites (comme les ACK TCP, SYN, paquets DNS, petites requêtes HTTP),
mais perd ou met en blackhole des trames plus grandes (comme les enregistrements TLS, réponses gRPC, lectures SMB, réplication de stockage, payloads d’overlay de conteneurs).

Le schéma racine ressemble généralement à l’un de ceux-ci :

Incohérence MTU entre interfaces dans un même domaine L2 (un saut bloqué à 1500, d’autres réglés sur 9000). Résultat : les grandes trames sont rejetées
à ce saut. Les petites trames survivent. Vous obtenez du « ça marche pour moi »… jusqu’à ce que la payload soit grosse.
Path MTU Discovery (PMTUD) cassé : quelque part on bloque les messages ICMP « Fragmentation nécessaire », donc les endpoints n’apprennent jamais le MTU réel.
TCP continue d’essayer des segments trop grands, qui meurent. La connexion ne tombe pas toujours immédiatement ; elle se bloque. C’est pour ça que ce bug paraît hanté.
Les tunnels/overlays réduisent le MTU effectif (VXLAN, GRE, WireGuard, IPsec, VPN cloud). Votre NIC peut être en 9000, mais le tunnel demande de l’overhead.
Si vous n’ajustez pas le MTU en conséquence, vous venez de construire un broyeur à paquets.
Interactions d’offload (TSO/GSO/GRO/LRO) qui peuvent masquer le comportement de fragmentation et rendre les captures de paquets trompeuses. Le kernel peut « faire semblant »
d’avoir envoyé d’énormes paquets tandis que la NIC les segmente réellement—jusqu’à ce que le chemin ne le permette plus.
Équipements politiques (firewalls, load balancers, gateways NAT) qui maltraitent l’ICMP, clampent MSS incorrectement ou imposent un MTU inattendu dans un seul sens.
Les chemins asymétriques sont l’endroit où les choses simples meurent.

Conclusion pratique : les jumbo frames ne sont pas un réglage isolé ; c’est un contrat de bout en bout. Si un saut n’est pas d’accord, seuls les paquets dépassant
le plus petit MTU seront punis. Tout le reste continue de fonctionner et vous fait perdre la raison.

Blague n°1 : les bugs MTU, c’est comme les micro-ondes de bureau—parfaits pour les petites choses, mais mettez quelque chose de gros et soudain il y a de la fumée et des reproches.

Faits & contexte historique (ce qui explique la douleur)

Le « MTU 1500 » d’Ethernet est une convention, pas la physique. Il est devenu la valeur par défaut en raison d’un compromis entre efficacité et limites de buffers sur le matériel ancien.
Les « jumbo frames » n’ont jamais eu une seule taille universelle. 9000 est courant, mais 9216 et 9600 existent parce que les vendeurs voulaient une marge pour les tags VLAN et le framing interne.
PMTUD dépend d’ICMP, que les réseaux d’entreprise aiment bloquer. C’est un mode de défaillance récurrent depuis les années 1990 et il mérite des prix pour « outage le plus évitable ».
RFC 4821 (Packetization Layer PMTUD) existe parce que le PMTUD classique était fragile quand ICMP est filtré ; de nombreuses piles n’implémentent que partiellement l’approche « plus robuste ».
Le tagging VLAN réduit le MTU utile si vous n’en tenez pas compte. Un tag 802.1Q ajoute 4 octets ; QinQ en ajoute 8. Certains switches compensent ; d’autres non.
VXLAN et apparentés ont rendu les calculs MTU opérationnels. Les overlays ont déplacé la responsabilité du MTU de « fonctionnalité du switch » à « chaque nœud doit être d’accord », particulièrement en Kubernetes et multi-tenant.
Les jumbo frames aident surtout l’efficacité CPU, pas forcément le débit brut. Moins de paquets pour les mêmes octets signifie moins d’interruptions et moins d’overhead par paquet—utile à haut débit.
Les réseaux de stockage ont adopté tôt les jumbo frames (iSCSI, NFS, réplication Ceph) car ils déplacent des payloads séquentiels volumineux et bénéficient de moins de paquets.

Mode d’emploi pour un diagnostic rapide

Quand le temps presse, vous n’avez pas besoin de théorie. Vous avez besoin d’un chemin rapide vers « quel est le plus petit MTU sur ce chemin, et qui n’est pas aligné. »

Première étape : confirmer que c’est le MTU et pas « l’appli »

Lancez un test ping DF depuis le client vers le serveur avec une taille de payload qui devrait passer en 1500 et échouer en jumbo (détails dans la section tâches). Si 1472 fonctionne mais
~8972 non, félicitations : c’est le MTU.
Si les petites requêtes fonctionnent mais que les gros téléchargements se bloquent, testez avec curl --http1.1 et une réponse volumineuse connue. Des blocages pendant le transfert
plus des échecs de ping DF sont classiques.

Deuxième étape : trouver le plus petit MTU sur le chemin réel

Vérifiez le MTU sur la NIC de l’hôte, le bond, la sous-interface VLAN, le bridge et les points de terminaison de tunnel. Le plus petit l’emporte, que ça vous plaise ou non.
Confirmez que le profil du port switch autorise réellement le jumbo. Ne faites pas confiance à « on l’a configuré l’année dernière. » Cette phrase a mis fin à des carrières.

Troisième étape : vérifier que PMTUD fonctionne

Recherchez des ICMP « fragmentation nécessaire » qui reviennent quand vous envoyez des paquets DF trop grands. S’ils manquent, quelque chose les bloque.
Comme mitigation temporaire, clamppez le MSS TCP aux frontières (firewall, VPN, tunnel), puis corrigez l’alignement MTU réel.

Quatrième étape : vérifier overlays et offloads

En Kubernetes/VXLAN, fixez le MTU des pods plus bas que le MTU des nœuds en tenant compte de l’overhead d’encapsulation.
Désactivez brièvement TSO/GSO pour le dépannage si les captures sont confuses, puis réactivez pour la performance une fois le chemin compris.

Un modèle mental pratique du MTU (couches, overhead et où ça foire)

Le MTU est la taille maximale du payload L3 que votre interface acceptera sans fragmentation. Sur Ethernet, on dit familièrement « MTU 1500 » en parlant
de 1500 octets de payload IP à l’intérieur d’une trame Ethernet. La trame Ethernet elle-même est plus grande (entêtes, FCS, préambule), mais le réglage MTU que vous touchez
sous Linux est généralement la taille du payload L3.

La chose la plus utile à retenir est que le MTU est par saut et par interface. Vous pouvez avoir :

NIC MTU = 9000
Bond MTU = 9000
Sous-interface VLAN MTU = 9000
Bridge Linux MTU = 1500 (oups)
Périphérique VXLAN MTU = 1450 (probablement correct pour un underlay 1500)

Et puis tout le monde discute de « le MTU », comme s’il n’y en avait qu’un. Il n’y en a pas. Il y a une chaîne, et le maillon le plus faible fixe votre MTU effectif.

Pourquoi TCP « marche à peu près » même quand le MTU est cassé

TCP peut éviter la fragmentation en choisissant des segments plus petits. Il apprend combien il peut envoyer en toute sécurité via PMTUD : il envoie des paquets avec DF (don’t fragment),
et si un saut ne peut pas les transporter, ce saut renvoie un ICMP « fragmentation nécessaire » avec le MTU du saut suivant. Alors TCP réduit sa taille de segment.

Quand l’ICMP est bloqué, TCP ne reçoit pas l’info. Il continue d’envoyer de gros segments qui sont dropés. Des retries surviennent. Du backoff survient. Les applications expirent.
Pendant ce temps, les petits paquets (ACKs, keepalives, petites requêtes) continuent de circuler, donnant l’impression que tout est « globalement OK » depuis la surveillance basique.

C’est pourquoi les bugs MTU apparaissent comme :

Des blocages intermittents (pas des pannes nettes)
Des pics de latence en longue traîne
Fonctionne sur un chemin réseau mais pas sur un autre (routage asymétrique, politiques de firewall différentes)
« Ça casse seulement quand on upload/download quelque chose de volumineux »

Overhead d’overlay : votre taxe MTU cachée

L’encapsulation ajoute des en-têtes. Ces octets doivent tenir sous le MTU de l’underlay. Si votre underlay est 1500 et que vous utilisez VXLAN, votre MTU utile sera
typiquement autour de 1450 (selon les en-têtes exacts). Si vous réglez l’overlay à 1500 quand même, vous demandez à l’underlay de transporter >1500, ce qui entraîne
fragmentation (mauvais) ou drops (pire).

Les jumbo frames peuvent aider les overlays aussi, mais uniquement si tout l’underlay les supporte. Sinon, vous devez abaisser le MTU sur l’overlay et/ou clamp MSS.

Une citation à garder près de votre calendrier de changements : L’espoir n’est pas une stratégie. — Gene Kranz

Tâches pratiques : commandes, sorties attendues et quelle décision prendre

Ce sont les tâches que j’exécute réellement quand « certains trafics » cassent après un changement MTU sur Ubuntu 24.04. Chaque tâche inclut : commande, ce que la sortie signifie,
et la décision à prendre.

Task 1: Check current MTU on all interfaces (spot the odd one out)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> mtu 65536
enp3s0           UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
bond0            UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
br-storage       UP             7a:11:22:33:44:55 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Signification : Le bridge est à 1500 tandis que tout le reste est à 9000. C’est un classique d’échec partiel : le trafic traversant le bridge est forcé
à 1500 ou dropé si DF est activé.

Décision : Aligner le MTU sur toute la chaîne (NIC → bond → VLAN → bridge → veth/tap) ou définir délibérément tout à la plus petite valeur que vous pouvez supporter de bout en bout.

Task 2: Confirm the default route and real egress interface (avoid debugging the wrong path)

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 dev bond0 src 10.50.12.10 uid 1000
    cache

Signification : Le trafic vers cette destination sort via bond0. Si vous regardiez les réglages de enp3s0, vous débogueriez de la fan fiction.

Décision : Concentrez les vérifications MTU et les captures sur l’interface egress réelle et sur le chemin inverse depuis le pair.

Task 3: Test L3 MTU to a peer with DF ping (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
1480 bytes from 10.50.12.34: icmp_seq=1 ttl=63 time=0.412 ms
1480 bytes from 10.50.12.34: icmp_seq=2 ttl=63 time=0.401 ms

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : Des paquets IP de 1500 octets fonctionnent. Ceci ne prouve pas que le jumbo fonctionne ; cela prouve seulement que vous n’avez pas cassé l’Ethernet de base.

Décision : Testez maintenant un paquet de taille jumbo qui devrait passer si le MTU 9000 est réellement bout en bout.

Task 4: Test jumbo MTU with DF ping (IPv4) and watch it fail cleanly

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.
ping: local error: message too long, mtu=1500
ping: local error: message too long, mtu=1500

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1018ms

Signification : La stack locale considère que le MTU de sortie pour cette route est 1500, malgré ce que vous pensiez avoir configuré. Ce n’est pas encore un problème de chemin ; c’est une configuration locale.

Décision : Trouver quel dispositif dans la chaîne egress a réellement MTU 1500 (souvent un bridge, VLAN, VRF ou device de tunnel).

Task 5: If it fails without a local error, you have a path blackhole (PMTUD or middle hop)

cr0x@server:~$ ping -M do -s 8972 -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 8972(9000) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1013ms

Signification : L’hôte est prêt à envoyer 9000, mais personne ne répond. Ça signifie généralement qu’un saut a dropé la grande trame. Si l’ICMP « fragmentation nécessaire »
ne revient pas, PMTUD ne peut pas se corriger.

Décision : Capturez le trafic et cherchez des erreurs ICMP ; s’ils sont absents, corrigez le filtrage ICMP ou clamppez le MSS comme mitigation.

Task 6: Test IPv6 MTU behavior (it differs; fragmentation is endpoint-only)

cr0x@server:~$ ping -6 -M do -s 1452 -c 2 2001:db8:10::34
PING 2001:db8:10::34(2001:db8:10::34) 1452 data bytes
1460 bytes from 2001:db8:10::34: icmp_seq=1 ttl=63 time=0.588 ms
1460 bytes from 2001:db8:10::34: icmp_seq=2 ttl=63 time=0.570 ms

--- 2001:db8:10::34 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Signification : Le chemin IPv6 supporte au moins des paquets autour de ~1500 ici. Avec IPv6, les routeurs ne fragmentent pas ; ils envoient des ICMPv6 « Packet Too Big ».
Si ça est bloqué, IPv6 devient fragile rapidement.

Décision : Assurez-vous que l’ICMPv6 est autorisé bout en bout. Le bloquer casse le vrai trafic, pas seulement le « ping ».

Task 7: Check TCP MSS on live sessions (detect clamping or lack of it)

cr0x@server:~$ sudo ss -ti dst 10.50.12.34 | head -n 20
ESTAB 0 0 10.50.12.10:44218 10.50.12.34:443
	 cubic wscale:7,7 rto:204 rtt:1.21/0.12 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:10 bytes_acked:12983 bytes_received:44112 segs_out:112 segs_in:98 data_segs_out:64 data_segs_in:71

Signification : Ce flux pense que le PMTU est 9000 et que MSS est 8960. Si le chemin ne peut pas réellement transporter 9000, c’est la recette d’un blocage.

Décision : Soit rendez le chemin réellement 9000 bout en bout, soit clamptez le MSS à une valeur sûre au niveau de la frontière où le MTU est plus petit.

Task 8: Watch for PMTUD ICMP messages with tcpdump

cr0x@server:~$ sudo tcpdump -ni bond0 'icmp and (icmp[0]=3 and icmp[1]=4)'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:22:31.201983 IP 10.50.12.1 > 10.50.12.10: ICMP 10.50.12.1 unreachable - need to frag (mtu 1500), length 556

Signification : Le réseau vous indique qu’un saut a un MTU à 1500. PMTUD fonctionne, mais vos endpoints peuvent encore mal se comporter si des politiques filtrent certains
ICMPs ou si seulement certains chemins renvoient l’erreur.

Décision : Corrigez la divergence : soit abaissez MTU/MSS aux valeurs sûres pour cette route, soit mettez à niveau le chemin pour le jumbo de façon cohérente.

Task 9: Check for ICMP being filtered locally (firewall rules)

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

Signification : ICMP/ICMPv6 sont acceptés. C’est bien. Si vous ne voyez pas ces accepts, PMTUD peut échouer même si le réseau envoie les bons messages.

Décision : Autorisez l’ICMP « fragmentation nécessaire » / « packet too big » et le trafic lié. Ne « sécurisez » pas votre réseau en le rendant non-fonctionnel.

Task 10: Check NIC offloads that can confuse troubleshooting (not necessarily the root cause)

cr0x@server:~$ sudo ethtool -k enp3s0 | egrep 'tcp-segmentation-offload|generic-segmentation-offload|generic-receive-offload'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Signification : Les offloads sont activés. Les captures de paquets sur l’hôte peuvent montrer de gros « super-paquets » qui n’existent pas sur le lien.

Décision : Si le dépannage est confus, désactivez temporairement TSO/GSO sur un nœud de test, validez le comportement, puis restaurez. Ne laissez pas la perf en rade indéfiniment.

Task 11: Temporarily disable TSO/GSO/GRO (diagnostic move)

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

Signification : Maintenant les captures correspondent mieux au comportement sur le fil. Le débit peut chuter ; c’est acceptable pour le diagnostic.

Décision : Refaites les pings DF et l’application réelle. Si les symptômes changent beaucoup, intégrez la compréhension des offloads dans votre correctif, puis réactivez les offloads.

Task 12: Check bridge MTU and members (common “hidden 1500” culprit)

cr0x@server:~$ ip -d link show br-storage
7: br-storage: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 7a:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 9000 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

Signification : Le bridge est explicitement à 1500 même s’il pourrait monter à 9000. Ce bridge limitera le trafic qui le traverse.

Décision : Réglez le MTU du bridge pour qu’il corresponde à l’underlay si chaque segment attaché supporte le jumbo ; sinon laissez-le à 1500 et acceptez la réalité.

Task 13: Confirm VLAN interfaces are aligned (VLANs are where assumptions go to die)

cr0x@server:~$ ip -d link show bond0.120
12: bond0.120@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0
    vlan protocol 802.1Q id 120 <REORDER_HDR>

Signification : Le device VLAN est à 9000. S’il était à 1500 alors que le parent est à 9000, vous auriez des échecs spécifiques à la route et une asymétrie étrange.

Décision : Gardez le MTU cohérent pour le parent et les sous-interfaces VLAN sauf si vous avez une raison très spécifique et un schéma prouvant cette exception.

Task 14: Measure real application behavior with curl (stall patterns matter)

cr0x@server:~$ curl -v --max-time 10 http://10.50.12.34:8080/largefile.bin -o /dev/null
*   Trying 10.50.12.34:8080...
* Connected to 10.50.12.34 (10.50.12.34) port 8080
> GET /largefile.bin HTTP/1.1
> Host: 10.50.12.34:8080
> User-Agent: curl/8.5.0
> Accept: */*
* Request completely sent off
* Operation timed out after 10000 milliseconds with 0 bytes received
curl: (28) Operation timed out after 10000 milliseconds with 0 bytes received

Signification : L’établissement de la connexion a réussi, la requête est partie, la réponse n’est jamais arrivée. Cela correspond à des paquets serveur→client volumineux dropés,
ou à un échec PMTUD dans la direction inverse.

Décision : Testez aussi la direction inverse (lancez la même commande depuis l’autre hôte) et capturez sur les deux bouts ; suspectez une asymétrie MTU/politique ICMP.

Task 15: Check kernel MTU/PMTUD related counters (are we seeing fragmentation or errors?)

cr0x@server:~$ netstat -s | egrep -i 'fragment|reassembl|MTU|icmp.*frag' | head -n 30
Ip:
    0 outgoing packets dropped
    12 fragments dropped after timeout
    0 reassemblies required
Icmp:
    4 destination unreachable messages received

Signification : Des compteurs liés à la fragmentation qui bougent peuvent indiquer une fragmentation réelle ou un blackholing. Ce n’est pas parfait, mais c’est un indice.

Décision : Si vous voyez des reassemblages ou des fragments dropés qui augmentent pendant les tests, alignez le MTU et évitez de compter sur la fragmentation pour le trafic volumineux.

Task 16: Validate persistent MTU configuration on Ubuntu 24.04 (netplan)

cr0x@server:~$ sudo cat /etc/netplan/01-bond.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      mtu: 9000
    enp4s0:
      mtu: 9000
  bonds:
    bond0:
      interfaces: [enp3s0, enp4s0]
      mtu: 9000
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100

Signification : Netplan définit explicitement le MTU. Si le MTU en cours d’exécution ne correspond pas, un autre fichier peut l’écraser ou un changement runtime peut être appliqué.

Décision : Consolidez la configuration netplan et appliquez-la avec prudence (voir le plan de déploiement sûr) pour éviter des reconfig inattendues en plein incident.

Comment corriger le MTU en toute sécurité (sans coupures « oups »)

Il y a deux grandes stratégies. Choisissez-en une et tenez-vous-y. Le demi-jumbo est le meilleur moyen d’obtenir un réseau à moitié fonctionnel.

Stratégie A : Rendre le jumbo réellement bout en bout (préférée pour les clusters de stockage)

C’est la bonne approche si vous contrôlez tout le chemin L2/L3 : NICs, bonds, bridges, switches et tous les appliances intermédiaires.

Définissez le MTU de façon cohérente sur chaque interface Linux qui transporte le trafic : NIC physiques, bonds, sous-interfaces VLAN, bridges et tout veth/tap pour VMs/containers.
Assurez-vous que les ports et trunks switch sont configurés pour accepter les jumbo frames. Surveillez les réglages « baby giant » si des tags VLAN sont impliqués.
Validez que PMTUD fonctionne encore (n’écartez pas l’ICMP), même avec le jumbo activé. Vous voulez PMTUD comme filet de sécurité, pas comme victime.
Exécutez des pings DF pour 1500 et des tailles jumbo entre tous les pairs critiques (pas seulement une paire).

Stratégie B : Garder l’underlay à 1500, ajuster les overlays et clamp MSS (préférée pour réseaux mixtes)

Si vous traversez des VPNs, gateways cloud ou boîtes noires, les jumbo frames sont souvent une discussion que la réalité gagnera.

Laissez l’underlay à 1500 (ou la valeur du saut le plus étroit).
Réglez correctement le MTU des tunnels/overlays (généralement inférieur à l’underlay par l’overhead).
Clampez le MSS TCP à la frontière pour que TCP n’essaie jamais des segments qui ne rentrent pas. Ceci atténue les blackholes PMTUD.

Mécanique de changement sûre sur Ubuntu 24.04

Ubuntu 24.04 utilise typiquement netplan avec systemd-networkd ou NetworkManager. Sur les serveurs, c’est souvent networkd. Les changements MTU peuvent faire rebondir les interfaces. Si c’est
la même interface sur laquelle vous êtes en SSH, vous avez besoin d’un harnais de sécurité.

Règles d’or pour changer le MTU en production

Ne changez jamais le MTU du seul chemin de management sans console hors bande ou rollback programmé.
Changez d’abord le domaine le plus étroit : si le switchport est à 1500, augmenter l’hôte à 9000 ne vous apporte rien sauf de la confusion.
Déployez en anneaux : un hôte, puis une paire, puis un rack/zone, puis le parc.
Mesurez avec du vrai trafic : réplication de stockage, trafic overlay de conteneurs, transferts HTTP volumineux — pas seulement des pings.

Blague n°2 : « On va juste passer le MTU à 9000 partout » est l’équivalent réseau de « Je vais juste redémarrer la production rapidement. »

Trois mini-récits d’entreprise depuis les tranchées MTU

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

Une entreprise de taille moyenne gérait un cluster de virtualisation privé : hyperviseurs sur Ubuntu, trafic de stockage sur un VLAN dédié et une pile de top-of-rack qui
« supportait le jumbo ». Quelqu’un a décidé d’activer les jumbo frames pour réduire la charge CPU sur les hyperviseurs, car les graphiques montraient des softirq élevés pendant les fenêtres de sauvegarde.

L’ingénieur a modifié le MTU à 9000 sur les bonds des hyperviseurs et sur les interfaces VLAN de stockage. Quelques pings tests ont réussi (en 1500), les VM sont restées en marche,
et tout le monde est rentré chez soi. Le lendemain matin, seules certaines VM avaient des sauvegardes cassées. Certains montages NFS allaient bien. D’autres bloquaient pendant de grosses lectures. On a d’abord accusé le système de stockage, qui est un coupable populaire.

L’hypothèse erronée : « La pile de switch supporte le jumbo, donc les ports doivent être configurés pour ça. » En réalité, le switch avait le jumbo activé globalement, mais un trunk particulier vers le réseau de stockage avait encore un profil legacy avec un maximum autour de 1500. Le trafic dans un rack restait jumbo-capable ; le trafic traversant ce trunk atteignait le MTU plus petit et commençait à être blackholé.

Le diagnostic a pris plus de temps que nécessaire car les contrôles basiques étaient verts : SSH, petits RPC, heartbeats de cluster. L’indice utile a été un ping DF qui échouait seulement entre racks et un tcpdump montrant des ICMP « frag needed » dans une direction mais pas dans l’autre (filtrage asymétrique).

La correction a été ennuyeuse : aligner le MTU du trunk switch, vérifier avec des pings DF entre nœuds représentatifs et arrêter de confondre « supporte le jumbo » avec « configuré pour le jumbo ». L’action post-incident la plus ennuyeuse a été : maintenir une matrice MTU simple par VLAN et l’enforcer par contrôles de configuration. Ça a marché.

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

Une autre organisation exécutait Kubernetes sur Ubuntu avec un CNI basé sur VXLAN. Ils avaient un réseau est-ouest rapide et voulaient « la perf maximale », donc ils ont mis le MTU NIC des nœuds à 9000 en supposant que tout en bénéficierait automatiquement. Les pods gardaient le MTU par défaut, et l’auto-détection MTU du CNI s’est trompée sur un sous-ensemble de nœuds.

Pendant une semaine, rien d’évident n’a cassé. Puis ils ont déployé un service qui streamait de grosses réponses (artefacts, blobs de modèles ML, gros JSON—choisissez votre poison).
Soudain, seuls certains pods sur certains nœuds ont connu d’énormes latences et des timeouts. Les retries ont masqué le problème, donc les graphiques montraient « plus lent mais globalement OK », exactement le genre de problème qui coûte de l’argent en silence.

L’optimisation a échoué à cause de l’overhead d’encapsulation. Certains chemins pod→pod dépassaient effectivement le MTU de l’underlay à cause des en-têtes VXLAN, et PMTUD était peu fiable à cause de règles firewall qui traitaient certains ICMP comme suspects. Donc les pods envoyaient des paquets corrects sur la machine, mais trop gros hors machine.

La correction a été de fixer un MTU CNI explicite et correct (plus bas que l’underlay du pire cas), et de garder l’underlay MTU cohérent sur toutes les interfaces pertinentes. Les jumbo frames restaient utilisées sur le réseau physique, mais le MTU de l’overlay a été choisi délibérément, pas « parce que plus grand c’est mieux ».

La leçon la plus précieuse n’était pas « ne pas utiliser le jumbo ». C’était : ne déployez pas de changements de perf que vous ne pouvez pas valider avec des tests bout à bout et un plan de rollback. Le travail de perf est du travail de production. Traitez-le avec la même discipline.

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

Une équipe financière avait pour habitude : chaque changement affectant le réseau venait avec un petit « test de contrat de chemin ». C’était un script lancé depuis un hôte canari :
pings DF à plusieurs tailles, un gros téléchargement HTTPS et un test de sanity de réplication de stockage. Il consignait les résultats dans un emplacement visible par tous.

Un trimestre, l’équipe réseau a remplacé une paire de firewalls. Le plan de migration était solide, mais au milieu d’une longue fenêtre de changement, quelqu’un a restauré une politique par défaut qui
bloquait involontairement certains messages ICMP unreachable. La connectivité est restée. La surveillance est restée verte. Le genre de vert qui ment.

Le test canari a déclenché immédiatement. Les pings DF en jumbo ont cessé d’obtenir des réponses « frag needed » ; les gros téléchargements se sont arrêtés ; le comportement PMTUD a changé. Personne
n’a attendu que les clients appellent. La décision de rollback a été prise sur la base de preuves, pas d’impressions.

Ils n’ont même pas eu à abandonner le cutover du firewall. Ils ont ajusté la politique pour autoriser l’ICMP essentiel, relancé les tests et ont poursuivi. La pratique n’était pas glamour. Elle n’a pas eu de talk en conférence. Elle a néanmoins sauvé la journée.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: SSH works, but large downloads hang or reset

Cause racine : PMTUD blackhole. Les gros segments TCP dépassent le MTU d’un saut ; ICMP « fragmentation nécessaire » est bloqué.

Correction : Autoriser l’ICMP fragmentation-needed/packet-too-big à travers les firewalls. En mitigation, clamptez le MSS TCP sur le device frontière.

2) Symptom: Only cross-subnet traffic breaks after enabling jumbo

Cause racine : Un device L3 (routeur, firewall, gateway) est encore à 1500 pendant que le L2 local est en jumbo.

Correction : Soit rendre le chemin routé jumbo-capable bout à bout, soit garder le MTU serveur à 1500 pour ce segment routé et n’utiliser le jumbo que sur des VLANs de stockage isolés.

3) Symptom: East-west pod traffic in Kubernetes is flaky; node-to-node ping is fine

Cause racine : MTU d’overlay non réduit pour l’overhead VXLAN/Geneve, ou MTU CNI incohérent entre les nœuds.

Correction : Définir un MTU CNI cohérent (ex. 1450 pour underlay 1500, ou plus si l’underlay est jumbo). Valider avec des tests DF entre pods sur différents nœuds.

4) Symptom: VMs on a Linux bridge break, but the host itself is fine

Cause racine : Bridge MTU ou devices tap/vnet à 1500 ; la NIC hôte est à 9000. Le trafic VM heurte le MTU plus petit.

Correction : Réglez le MTU sur le bridge et les interfaces face VM de manière cohérente, ou laissez tout à 1500 si le chemin physique ne peut garantir le jumbo.

5) Symptom: One direction is slow, the other is fine

Cause racine : Routage asymétrique ou filtrage ICMP asymétrique ; PMTUD fonctionne dans une direction mais pas dans l’autre.

Correction : Capturez sur les deux extrémités ; alignez les politiques MTU ; autorisez l’ICMP dans les deux sens ; vérifiez la symétrie de chemin pour les flux critiques.

6) Symptom: “We set MTU to 9000 but ping says mtu=1500”

Cause racine : La route utilise une interface différente (VRF, VLAN, bridge) encore à 1500, ou un override de config réinitialise le MTU lors du link up.

Correction : Utilisez ip route get pour confirmer le device egress ; vérifiez le MTU sur toute la pile d’interfaces ; corrigez la config netplan/systemd-networkd pour la rendre persistante.

7) Symptom: Performance got worse after enabling jumbo

Cause racine : Micro-bursts et pression sur les buffers des switches/NICs, ou problèmes de driver/offload. Le jumbo réduit le nombre de paquets, mais peut augmenter la burstiness.

Correction : Validez avec des tests de débit et latence, surveillez les drops sur switches/NICs, envisagez un jumbo légèrement plus petit (ex. 9000 vs 9600) et ajustez les queues ; n’assumez pas que « plus grand = plus rapide ».

Listes de vérification / plan étape par étape

Checklist : avant de toucher au MTU

Définir le périmètre : quel VLAN/subnet/tunnel change ?
Lister chaque saut : NICs serveurs, bonds, bridges, hypervisor vSwitch, switchports, trunks, routeurs, firewalls, VPNs, load balancers.
Décider du MTU cible par domaine : uniquement 1500, ou jumbo bout en bout.
Confirmer que vous avez un chemin de rollback : accès console, NIC mgmt alternatif, ou job timed qui restaure netplan.
Préparer les tests : pings DF aux tailles, un gros transfert HTTP et un test de vrai workload (réplication stockage, job de backup, etc.).

Étapes : déploiement jumbo sûr sur Ubuntu 24.04 (serveurs)

Choisir un hôte canari avec accès hors bande.
Mesurer le baseline :
lancer des pings DF à 1472 et 8972 vers des pairs clés ; lancer un gros transfert ; capturer un bref tcpdump pour ICMP « frag needed ».
Valider le réseau d’abord :
configurer les switchports/trunks pour le jumbo, confirmer avec l’équipe réseau via leurs outils. Ne changez pas les hôtes tant que le réseau n’est pas prêt.
Modifier le MTU sur l’hôte canari dans netplan pour toutes les interfaces pertinentes (physique + bond + VLAN + bridge).
Appliquer de façon contrôlée :
préférez une fenêtre de maintenance ; si vous êtes uniquement en remote, utilisez un mécanisme de rollback programmé (voir ci-dessous).
Relancer les tests immédiatement :
le ping DF en jumbo doit réussir bout à bout ; le transfert applicatif doit aboutir ; vérifiez ss -ti pour un MSS/PMTU cohérent.
Étendre à un petit anneau :
une paire d’hôtes qui échangent beaucoup ; puis un rack ; puis le parc.
Garder la surveillance ciblée :
surveillez retransmits, timeouts et latence stockage. Les échecs MTU apparaissent souvent comme des tempêtes de retransmission, pas des liens down.

Schéma de rollback programmé (pour dormir tranquille)

Si vous changez le MTU sur l’interface qui transporte votre session SSH, planifiez un rollback programmé avant d’appliquer netplan. Exemple : programmer un reboot ou un revert netplan
dans 5 minutes, puis annulez-le une fois la connectivité confirmée. Il y a plusieurs méthodes ; l’idée est : ne misez pas la production sur votre Wi‑Fi.

cr0x@server:~$ sudo systemd-run --on-active=5m --unit=mtu-rollback.service /usr/sbin/netplan apply
Running as unit: mtu-rollback.service

Signification : Cet exemple est volontairement simpliste et pas un rollback complet ; en pratique vous exécuterez un script qui restaure un YAML netplan connu bon et l’applique.

Décision : Utilisez un vrai script de rollback dans votre environnement. Le point est le pattern opérationnel : appliquer un changement avec un timer de sécurité, puis annuler une fois vérifié.

FAQ

1) Pourquoi ping marche mais mon appli casse ?

Le ping par défaut utilise de petits paquets. Votre appli envoie probablement des segments TCP plus grands. Les problèmes MTU n’apparaissent que quand des paquets dépassent le plus petit MTU sur le chemin,
et PMTUD peut ou non vous sauver selon les politiques ICMP.

2) Quel MTU choisir pour les jumbo frames : 9000 ou 9216 ?

Choisissez la valeur que vos switches et NICs supportent de façon cohérente. 9000 est courant pour « IP MTU ». Certains équipements annoncent 9216 comme grandeur de trame. La seule
réponse correcte est : choisissez-en une, documentez-la par VLAN et testez bout à bout en incluant le tagging VLAN et les trunks.

3) Les jumbo frames améliorent-elles toujours la performance ?

Non. Elles réduisent souvent l’overhead CPU à haut débit, mais peuvent aussi augmenter la burstiness et la pression sur les buffers. Si votre goulet d’étranglement est le disque, le chiffrement,
la sérialisation applicative ou un processus utilisateur mono-thread, les jumbo frames ne vous sauveront pas.

4) La fragmentation est-elle réellement si mauvaise ?

De la fragmentation occasionnelle pour du trafic inhabituel est survivable. Compter sur la fragmentation pour du trafic massif est une taxe : CPU supplémentaire, complexité de réassemblage,
sensibilité accrue aux drops et debug plus pénible. La plupart des designs modernes cherchent à l’éviter.

5) Quelle est la meilleure méthode pour détecter les blackholes PMTUD ?

Tests ping DF plus captures paquets pour ICMP « frag needed » / « packet too big ». Si les gros paquets DF disparaissent et que vous ne voyez jamais l’erreur ICMP, quelque chose les filtre.
Cherchez aussi des flux TCP arrêtés avec beaucoup de retransmits et pas de progrès.

6) En Kubernetes, dois-je régler le MTU des nœuds à 9000 ?

Seulement si votre underlay supporte vraiment le jumbo bout à bout et si vous réglez le MTU CNI/overlay de façon appropriée. Sinon, gardez l’underlay à 1500 et utilisez un MTU d’overlay plus bas
qui tient compte de l’encapsulation.

7) Pourquoi le problème n’apparaît-il que pour certaines destinations ?

Différentes destinations peuvent emprunter des chemins réseau différents avec des MTU différents (routeurs, firewalls, tunnels VPN, bords cloud différents). Les incohérences MTU dépendent du chemin.

8) Comment corriger rapidement si je ne peux pas changer le réseau aujourd’hui ?

Mitigez en abaissant le MTU sur les interfaces affectées à la plus petite valeur sûre, ou clamptez le MSS TCP à la frontière pour que les endpoints arrêtent d’envoyer des segments trop grands.
Ensuite planifiez la vraie correction : aligner le MTU bout à bout ou corriger la politique ICMP.

9) Ubuntu 24.04 fait-il quelque chose de « spécial » avec le MTU ?

La complexité habituelle vient de netplan qui rend en systemd-networkd ou NetworkManager, plus les interfaces empilées (bonds, bridges, VLANs, tunnels). L’OS n’est pas spécial ; votre topologie l’est.
Vérifiez le MTU à l’exécution avec ip -br link, pas seulement dans le YAML.

10) Dois-je autoriser tout l’ICMP via le firewall ?

Vous devriez autoriser les types ICMP nécessaires au fonctionnement normal, en particulier fragmentation-needed/packet-too-big et les messages unreachable liés. Bloquer tout l’ICMP est un instrument grossier
qui casse PMTUD et rend les pannes plus difficiles à diagnostiquer.

Conclusion : prochaines étapes qui ne gâchent pas votre week-end

Les jumbo frames ne « marchent pas à moitié ». Elles fonctionnent soit bout à bout, soit elles créent un champ de distorsion de la réalité où les petits paquets prospèrent et les gros disparaissent.
Voilà pourquoi vous voyez « seulement certains trafics » casser.

Faites ceci ensuite :

Exécutez des pings DF aux tailles 1500 et jumbo entre les pairs importants.
Trouvez le plus petit MTU sur le chemin en vérifiant chaque couche d’interface : NIC, bond, VLAN, bridge, tunnel.
Vérifiez PMTUD en capturant les ICMP « frag needed » / « packet too big » ; corrigez les politiques firewall qui les bloquent.
Choisissez une stratégie : jumbo bout à bout pour les domaines contrôlés, ou underlay conservateur à 1500 avec MTU overlay correct et clamp MSS.
Déployez en anneaux avec un canari et un plan de rollback. La production récompense la prudence, pas la témérité.