votre réseau Qu'est-ce que MTU ? Le MTU, ou 'Maximum Transmission Unit', est le plus grand bloc de données pouvant être traité au niveau de la couche 3 du modèle OSI . Il s'agit généralement d'IP, donc le MTU fait généralement référence à la taille maximale d'un paquet.
D'où vient cette limite ?
La limite à la couche-3 vient directement de la couche-2. La couche 2 utilise des cadres et chaque cadre a une limite de taille maximale.
La norme Ethernet, par exemple, définit une taille de trame maximale à 1518 octets. Les en-têtes Ethernet ont une longueur de 18 octets, laissant 1500 octets pour le paquet à utiliser. Par conséquent, le MTU du paquet est de 1500 octets.
Nous n'utilisons pas toujours Ethernet comme protocole de couche 2. De
nombreuses normes WAN, telles que PPPoE, utilisent différentes tailles de trame. Cela se traduit par un MTU différent pour le paquet.
Dans cet article, nous supposerons Ethernet, sauf indication contraire.
Certains appareils prennent en charge les trames Jumbo . Les normes
Ethernet plus récentes prennent en charge les trames jusqu'à environ 9 000 octets. C'est plus courant dans les campus et les centres de données, mais encore rare dans le WAN. Pour le reste de cet article, nous parlerons de la limite de trame non Jumbo de 1500 octets.
Le paquet entier doit s'adapter à la limite MTU. Cela inclut les en-têtes IP
ainsi que la charge utile.
TCP a une limite appelée Taille maximale de segment, ou MSS. Il s'agit de la
taille de la charge utile de la couche 4 (sans les en-têtes IP et TCP).
Les en-têtes IP et TCP ajoutent généralement jusqu'à 40 octets au
total. Donc, si on partait d'un MTU de 1500 octets, on a maintenant un MSS de 1460 octets.
Fragmentation Un hôte connaîtra certainement le MTU de sa propre connexion au réseau. Mais, il n'a aucun moyen de connaître le MTU d'un lien plus haut sur le chemin. Par exemple, la carte réseau d'un ordinateur peut avoir une MTU de 1 500. Cependant, la connexion au WAN a une MTU de 1 400.
Cela pourrait nous laisser dans une situation délicate. Le poste de travail
peut envoyer un paquet de 1500 octets. Le routeur connecté au WAN serait incapable d'envoyer le paquet, car le paquet est plus grand que le MTU de 1400 octets.
La solution est la fragmentation . Lorsqu'un paquet est plus grand que le
MTU, un périphérique (souvent un routeur) divisera le paquet en fragments plus petits.
Chacun de ces fragments est toujours un paquet, juste plus petit que l'original. Les paquets se déplacent le long du chemin vers la destination comme d'habitude. Le périphérique de destination rassemble les fragments dans le paquet d'origine et le traite normalement.
Cela peut sembler une solution merveilleuse, mais elle a ses
inconvénients. D'une part, chaque fragment a des en-têtes IP dupliqués, ce qui entraîne l'envoi de plus de trafic.
En outre, cela ajoute une surcharge de traitement sur le routeur qui
fragmente les paquets et sur la destination qui les réassemble.
Et si un fragment disparaît ou est corrompu ? Nous devons renvoyer le
paquet entier, pas seulement le fragment. Les pare-feu peuvent également avoir des problèmes avec les fragments. Certains d'entre eux laisseront tomber des fragments s'ils arrivent dans le désordre, les considérant comme du trafic non sollicité.
CONSEIL : Dans la mesure du possible, évitez la fragmentation
Qu'est-ce qui peut causer la fragmentation ?
Comme nous l'avons déjà mentionné, certaines liaisons WAN utilisent un MTU plus petit. Mais il y a aussi d'autres causes.
Les tunnels, tels qu'un tunnel GRE , ajouteront des en-têtes supplémentaires
à un paquet. Cela peut pousser la taille du paquet au-delà de la limite de trame et provoquer une fragmentation.
Le chiffrement, IPSec par exemple , peut également ajouter des en-têtes
supplémentaires, avec le même effet.
Alors, que faisons-nous à ce sujet ? Dans le cas d'un tunnel (avec ou sans
cryptage), nous abaisserions manuellement le MTU sur l'interface du tunnel.
Nous limitons effectivement la taille de la charge utile, de sorte que la
charge utile plus les en-têtes supplémentaires ne dépassent pas la limite de trame.
Mais cela nous laisse toujours avec la fragmentation. Un poste de travail ne
connaît pas la taille MTU plus petite du tunnel, envoie des paquets volumineux et une fragmentation se produit. Ce n'est pas idéal.
Nous devons maintenant réfléchir à la façon de gérer cela. Une option peut
être de définir manuellement le MTU sur chaque poste de travail. C'est un très gros travail. Une autre option consiste à utiliser Path MTU Discovery (PMTUD).
PMTUD PMTUD est une méthode de découverte dynamique de faibles MTU le long d'un chemin. Cela fonctionne en définissant le bit 'Don't Fragment' (DF) dans l'en-tête IP de chaque paquet.
La définition de ce bit indique aux périphériques que la fragmentation n'est
pas autorisée pour ce paquet. S'il est trop grand et que ce bit est défini, la livraison n'est pas possible et l'appareil supprime le paquet.
L'appareil qui a abandonné le paquet enverra un message ICMP « Destination
inaccessible (la fragmentation était nécessaire et DF a été défini) » à l'expéditeur.
Lorsque l'expéditeur reçoit ce message, il sait que les paquets qu'il envoie sont trop volumineux pour le chemin.
ASTUCE : ne bloquez pas les messages ICMP type 3 code 4 ! Ceux-ci
sont nécessaires pour que PMTUD fonctionne !
Le message ICMP n'indique pas à l'expéditeur ce que doit être le
MTU. L'expéditeur doit réduire sa MTU pour cette connexion et réessayer. Il répétera le processus jusqu'à ce que le paquet soit suffisamment petit pour que ces messages ne soient pas générés.
PMTUD n'est pris en charge que par TCP et UDP
PMTUD n'est pas seulement fait lorsqu'une connexion est initialement
établie. Cela arrive continuellement. C'est parce que les chemins du réseau peuvent changer, donc les MTU peuvent changer. Cela permet aux appareils de s'adapter aux changements dans le réseau.
Il fonctionne également indépendamment dans les deux sens. Imaginez un
cas où un client demande HTTP à un serveur. Le client enverra généralement de petits paquets de requête au serveur, sans déclencher PMTUD. Le serveur renverrait probablement des paquets plus volumineux, ce qui pourrait déclencher PMTUD.
Un autre cas où nous voyons cela est avec le routage
asymétrique. Différents chemins sont utilisés dans différentes directions, qui peuvent avoir des MTU différentes.
TCP MSS Une autre option consiste à régler le MSS. Comme mentionné précédemment, le MSS est comme le MTU, mais utilisé avec TCP à la couche 4.
En termes simples, le MSS est la taille maximale que la charge utile peut atteindre, après avoir soustrait l'espace pour les en-têtes IP, TCP et autres. Ainsi, si le MTU est de 1500 octets et que les en-têtes IP et TCP sont de 20 octets chacun, le MSS est de 1460 octets.
Lors de l'établissement d'une nouvelle connexion TCP, une négociation à
trois est effectuée. Chaque appareil insère son MSS dans les en-têtes TCP, donc dans ce sens, il annonce son MSS à l'appareil distant. L'appareil distant verra le MSS et, si nécessaire, il ajustera la taille de la charge utile qu'il utilise lorsqu'il utilise cette connexion.
Il est important de noter ici que les hôtes annoncent simplement leur MSS. Il n'y a pas de négociation de valeurs mutuellement acceptables. Ils disent simplement « C'est la plus grande charge utile TCP que je peux gérer ». C'est à l'extrémité distante d'honorer cela.
Dispositifs provisoires Le MSS est basé sur le MTU. Nous sommes confrontés à un problème similaire à celui d'avant. Un appareil ne connaîtra que le MTU, et donc le MSS, de son lien local. Ils ne connaîtront pas un MSS inférieur sur un lien quelque part le long du chemin.
Pensez à un réseau avec un tunnel GRE par exemple. Chaque hôte aura un
MSS de 1460. Cependant, le tunnel a des en-têtes supplémentaires, abaissant son MSS à 1436 octets.
Comment pouvons-nous travailler avec des cas comme celui-ci? Nous
pouvons configurer les routeurs pour réécrire le MSS.
Un routeur Cisco, par exemple, aura cette commande configurée sur le
tunnel :
ip tcp adjust mss 1436
Lorsque le trafic TCP, tel que la poignée de main à trois voies, traverse le tunnel, le routeur verra que le MSS est défini sur 1460 dans l'en-tête TCP.
Sachant que le MSS du tunnel est inférieur à cela, il réécrira ceci en 1436.
Maintenant, l'hôte à l'autre extrémité verra le MSS du chemin et ajustera la
charge utile maximale pour cette connexion en conséquence.
Il est important de réaliser qu'il s'agit d'une fonctionnalité de TCP. Cela ne
fonctionnera pas avec UDP ou d'autres types de trafic.
UDP doit recourir à d'autres méthodes telles que PMTUD, les ajustements manuels de MTU ou la fragmentation.
