« Paquets dépassant la taille maximale » : Causes et correctifs pour ingénieurs réseau
Quand les paquets dépassent le MTU (Maximum Transmission Unit) du chemin, ils sont fragmentés ou rejetés. Voici la liste de dépannage.
Causes racines et solutions
1. Mauvaise configuration trames géantes (Jumbo Frames)
- Problème : Extrémités envoient trames 9000 octets ; switch/port intermédiaire MTU = 1500
- Correctif : Activer trames géantes **bout en bout** (NIC → ports switch → interfaces routeur → pare-feux). Vérifier avec
ping -s 8972 -M do(Linux) /ping -f -l 8972(Windows)
2. Échecs de fragmentation IP
- Problème : Bit « Don't Fragment » (DF) positionné + paquet > MTU chemin → ICMP « Fragmentation Needed » rejeté par pare-feu
- Correctif : Autoriser ICMP Type 3 Code 4 (Destination Inaccessible / Fragmentation Requise). Implémenter **PMTUD** (Path MTU Discovery) ou **PLPMTUD** (RFC 8899)
3. Inadéquation MTU (VPN, Tunnel, VXLAN, PPPoE)
- Surcharge VPN : IPsec ESP (~73 octets), WireGuard (60 octets), OpenVPN (~60 octets)
- PPPoE : 8 octets → MTU 1492
- VXLAN : 50 octets → MTU 1450
- Correctif : Baisser MTU extrémité (ex: 1380 pour IPsec) ou activer **MSS Clamping** (TCP MSS = MTU - 40) sur routeur/pare-feu
4. Matériel défectueux / Bugs pilotes
- Fonctionnalités décharge NIC (TSO, LRO, GRO) dysfonctionnent → trames surdimensionnées
- Correctif : Désactiver déchargements :
ethtool -K eth0 tso off gso off gro off; mettre à jour firmware/pilotes
Commandes de diagnostic
# Tracer MTU chemin tracepath # Linux mturoute.exe # Windows # Test taille spécifique avec bit DF ping -s 1472 -M do # 1472 + 28 en-têtes = 1500 ping -f -l 1472 # Windows # Vérifier MTU interface ip link show | grep mtu # Linux netsh interface ipv4 show subint # Windows Bonne pratique
- Standardiser MTU 1500 partout sauf **maîtrisé bout en bout** (fabric data center)
- Utiliser **MSS clamping** sur routeurs de bord pour trafic VPN/tunnel
- Surveiller ICMP « Packet Too Big » — c'est une fonctionnalité, pas un bug