Vous êtes sur la page 1sur 8

MTU et MSS Domicile 

> Des articles > Théorie > MTU et MSS

Comment MTU et MSS affectent


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.

Vous aimerez peut-être aussi