À propos des paramètres MTU dans les machines et le commutateur

Vous n'avez pas précisé les technologies de réseau dont vous parlez, alors je vais supposer Ethernet et IP [v4].

Ethernet a toujours défini sa gamme de longueurs de charge utile acceptable de 46 à 1500 octets et exige que tous les périphériques (hôtes et commutateurs) sur le LAN puissent recevoir des images avec des charges utiles de 1500 octets. Pour cette raison, Ethernet ne fournit pas de mécanisme de fragmentation, ni fournit un mécanisme pour communiquer ou négocier des MTU (ou, plus important encore, M R Us – Maximum Receive Units) entre les périphériques. En fait, le terme "MTU" ou "unité de transmission maximale" n'apparaît nulle part dans la spécification IEEE 802.3.

Donc ajoutons IP dans l'image. IP a un concept de MTU, et la plupart des piles IP modernes vous permettent de configurer des MTU par interface (et plus). Mais votre question, comme indiqué, ne fonctionne pas non plus dans le contexte de la propriété intellectuelle, car IP a un MTU minimum de 576. Donc, permettez-moi de réitérer votre question car "M1 a un MTU de 600 et M2 possède un MTU de 1200 ". Mais qu'est-ce que MTU devons dire que "Switch" a? Eh bien, si Switch est juste un commutateur Ethernet Layer 2, il n'a pas de concept d'un MTU réglable. Donc pour que votre question se déroule dans le contexte de l'IP, nous devrons transformer ce switch en un routeur. Appelons-en donc "Routeur" et disons qu'il a deux interfaces Ethernet, l'une attachée à M1 et l'une associée à M2. Disons également qu'il a MTU de 1200 mis sur ses deux interfaces.

1. Lorsque M1 envoie un cadre avec une charge utile de 600 octets à M2, il n'y aurait aucun problème.
2. Lorsque M2 envoie une image avec une charge utile de 1200 octets à M1, il n'y aurait toujours aucun problème. Pourquoi pas? Parce que la configuration du MTU de M1 n'a pas nécessairement changé son MRU et, dans mon expérience, les MTU et les MRU sont séparés, et les implémentations ne vous donnent pas le moyen de modifier votre MRU. Donc, MRU de M1 sur cette interface serait 1500 car Ethernet.
3. Le routeur ne sait pas qu'il doit fragmenter les images de M2, car il pense que tous les hôtes sur le réseau local Ethernet M1 sont en mesure de recevoir des images avec des charges utiles de 1200 octets, car il a été configuré pour une MTU de 1200 octets interface. Heureusement, cela fonctionnerait probablement bien, comme je l'ai mentionné dans (2).

D'accord, essayant toujours de trouver et de répondre à l'esprit véritable de votre question, disons que le lien entre M1 et Router est en fait PPP au lieu d'Ethernet. Le protocole PPP permet aux hôtes de communiquer / négocier leurs MRU. Disons que M1 a déclaré au routeur que M1 avait une limitation MRU de 600 octets, de sorte que Router a défini son MTU pour ce lien à 600 octets.

Maintenant, dans ce cas, si M2 envoie un datagramme IP de 1200 octets à M1 (sans définir le bit «Ne pas fragmenter» dans l'en-tête IP), le routeur le recevra très bien et se rendra compte qu'il faut le fragmenter pour l'envoyer À M1. Le routeur le brouille-t-il en deux fragments de 600 octets? Eh bien, non, ce n'est pas si simple pour quelques raisons.

Une des raisons est que chaque fragment doit avoir son propre en-tête IP, qui ajoute 20 octets à la taille de chaque fragment après le premier. L'autre raison est que le champ de décalage de fragmentation d'IP compte dans des blocs de 8 octets au lieu d'octets individuels.

Disons que le datagramme de 1200 octets était spécifiquement 1172 octets de données d'application dans un datagramme UDP (8 octets d'en-têtes UDP, 20 octets d'en-têtes IP). Après la fragmentation, le premier fragment contiendrait un en-tête IP de 20 octets, l'en-tête UDP de 8 octets et les premiers 568 octets des données de l'application, pour un total de 586 octets. La deuxième image contiendrait un autre en-tête IP de 20 octets, aucun en-tête UDP et les 576 octets suivants des données de l'application, pour un total de 586 octets. Cela laisse 28 octets de données d'application pour le fragment final qui, avec son en-tête IP ajouté, serait de 48 octets.

Mise à jour basée sur la mise à jour de Kavin qu'il parlait de cadres Jumbo:
Les cadres Jumbo sont quelque chose que certains fournisseurs de produits Gigabit Ethernet ont créé de manière indépendante pendant le temps que GigE a été créé, et il a été (je crois) par la suite rejeté ou ignoré par l'IEEE et semble peu susceptible de faire partie de la norme Ethernet 802.3. Même IEEE 802.3-2008 qui inclut non seulement 1000BASE-T, mais 10 G BASE-T, ne contient rien à environ 9 000 octets de charge utile.

Les fournisseurs qui ont créé des cadres jumbo n'ont fourni aucun type de mécanisme d'autonegociation ou de communication pour le support de cadre jumbo, ni créé une méthode de fragmentation de couche Ethernet pour traiter le cas (très commun) que vous avez illustré. Si vous souhaitez exécuter votre réseau local Ethernet dans ce mode non standard, vous devez vous assurer que tous les hôtes et les commutateurs de votre réseau local supportent les cadres jumbo.

Si la NIC de M1 n'est pas capable de recevoir des cadres jumbo, elle considérera un cadre jumbo comme étant un "jabber Ethernet" – un périphérique brisé qui "continue à fonctionner"; Continue d'envoyer des bits bien au-delà de la fin d'un cadre maximum autorisé 1500 (vraiment 1518) -byte. Notez que cette signification de jabber est un terme pour une sorte de dysfonctionnement Ethernet et ne doit pas être confondue avec le système de discussion Internet "Jabber" similaire. Vous devrez décider si vous souhaitez arrêter d'utiliser des cadres jumbo sur ce réseau, ou si vous souhaitez mettre à niveau M1 pour avoir une NIC prenant en charge les cadres jumbo.

Si la NIC de M1 est capable de recevoir des cadres jumbo, je soupçonne que le réglage de son MTU IPv4 pour cette interface jusqu'à 1500 assurera qu'il ne transmet pas de datagrammes IP de taille jumbo dans un seul cadre Ethernet jumbo, mais il sera probablement capable de Recevoir de grands datagrammes IP dans des images jumbo Ethernet simples, pas de problème, car encore une fois, MTU n'est pas MRU, et la définition d'un MTU de couche IP n'affecte pas les tampons de cadre de taille que la NIC permet. Maintenant, si vous modifiez un paramètre NIC / pilote pour indiquer à la NIC d'utiliser uniquement des tampons de 1500 octets au lieu des tampons de 9000 octets, c'est un changement de couche Ethernet et pourrait probablement rendre votre NIC comme si elle ne l'avait pas fait Prend en charge les tampons de 9 000 octets.

Je pense honnêtement que vous ne pouvez pas définir un MTU à 100 et établir une forme quelconque de connexion IP. Je crois que ipv4 REQUIRE un minimum de 576 … et peut-être plus. C'est CRAAAZY SMALL … typiquement les commutateurs 10/100 construits au cours des 20 dernières années ont une MTU de 1492 ou 1500 … et dans des réseaux plus exigeants avec de meilleurs équipements jusqu'à 9000.

Il existe une technologie appelée «pmtu» ou Path MTU, par laquelle une extrémité découvre la taille maximale du paquet qu'elle peut envoyer de manière fiable à l'autre et taille ses paquets jusqu'à la taille de la plus petite MTU.

Les paquets plus grands que ceux-ci sont fragmentés, à moins que le drapeau "DF" ou "Ne pas fragmenter" soit défini dans l'en-tête IP, auquel cas le paquet sera perdu en route.

Sur une connexion peer-to-peer comme vous décrivez, il devrait utiliser PMTU assez heureusement. Il ne s'agit que d'un problème lorsque vous roulez à travers un certain nombre de réseaux et que l'un des routeurs entre vous et la destination ne prend pas en charge PMTU correctement et ne signale pas la taille de MTU correcte à utiliser.