24 votes

Quelle est la taille "dans le fil" d'une trame Ethernet ? 1518 ou 1542 ?

Selon le le tableau ici Il est indiqué que le MTU = 1500 octets et que la partie payante est de 1500 - 42 octets ou 1458 octets (<- c'est en fait faux !). En plus de cela, il faut ajouter les en-têtes IPv4 et UDP, qui font 28 octets (20 IP + 8 UDP). Cela me laisse un message d'application maximum de 1430 octets ! Mais en cherchant ce chiffre sur l'internet, je vois plutôt 1472. Est-ce que je me trompe dans ce calcul ?

Tout ce que je veux savoir, c'est quel est le maximum de messages d'application que je peux envoyer sur le câble sans risque de fragmentation. Ce n'est certainement pas 1500 car cela inclut les en-têtes de trame. Quelqu'un peut-il m'aider ?


La confusion vient du fait que la charge utile peut en fait atteindre 1500 octets, ce qui correspond au MTU. Quelle est donc la taille dans le fil pour une charge utile de 1500 octets ? D'après ce tableau, elle peut atteindre 1542 octets.

Le nombre maximum de messages que je peux envoyer est donc de 1472 (1500 - 20 (ip) - 8 (udp)) pour un maximum de 1542 dans la taille du câble. Je suis étonné de voir à quel point les choses peuvent devenir si compliquées alors qu'elles sont en fait très simples. Et je n'ai aucune idée de comment quelqu'un a pu trouver le nombre 1518 si le tableau indique 1542.

35voto

voretaq7 Points 78924

Le diagramme de Wikipedia est horrible. J'espère que ce que je vais écrire sera plus clair.


Le maximum charge utile dans l'Ethernet 802.3 est de 1500 octets.
Il s'agit des données que vous essayez d'envoyer sur le câble (et auxquelles le MTU fait référence).
[payload] <- 1500 octets

La charge utile est encapsulée dans un Trame Ethernet (qui ajoute le MAC source/destination, la balise VLAN, la longueur et la somme de contrôle CRC). Cela représente un total de 22 octets de "trucs" supplémentaires
[SRC+DST+VLAN+LENGTH+[payload]+CRC] <- 1522 Bytes

La trame est transmise sur le câble - avant que votre carte Ethernet ne le fasse, elle se lève et crie très fort pour s'assurer que personne d'autre n'utilise le câble (CSMA/CD). Préambule y Délimiteur de début de trame (SFD) -- 8 octets supplémentaires, ce qui nous donne maintenant :
[Preamble+SFD+[Ethernet Frame]] <- 1530 Bytes

Enfin, lorsqu'un émetteur-récepteur Ethernet a fini d'envoyer une trame, la norme 802.3 exige qu'il transmette 12 octets de silence ("Interframe Gap") avant d'être autorisé à envoyer la trame suivante.
[Preamble+SFD+[Ethernet Frame]+Silence] <- 1542 octets transmis sur le fil.


Le préambule, le SFD et le décalage inter-trame ne sont pas considérés comme faisant partie de la trame. Il s'agit d'une structure de support pour le protocole Ethernet lui-même.

Le MTU s'applique à la charge utile : il s'agit de la plus grande unité de données que l'on peut insérer dans le paquet. Ainsi, un paquet Ethernet avec un MTU de 1500 octets sera en fait une trame de 1522 octets, et de 1542 octets sur le fil (en supposant qu'il y ait une balise vLAN).

La réponse à votre question est donc - Quel est le plus gros paquet que je peux envoyer sur 802.3 ethernet sans fragmentation ? - est 1500 octets de données utiles .

TOUTEFOIS la couche Ethernet n'est peut-être pas le facteur limitant. Pour savoir si quelque chose sur le chemin limite le MTU à moins de 1500 octets de données utiles, utilisez l'une des méthodes suivantes :

  • Fenêtres : ping hostname -f -l sizeofdata (technique mentionnée par John K)
  • BSD : ping -D -s sizeofdata hostname
  • Linux : ping -M do -s sizeofdata hostname

La plus grande valeur de sizeofdata qui fonctionne est le MTU (sur le chemin particulier emprunté par vos données).

3voto

Univ426 Points 2139

Cela dépend de la quantité de données que vous mettez dans le cadre. Si vous placez 1500 octets de données dans une trame, la taille totale de la trame sera de 1518 octets. Avec 1472 octets de données, la taille totale de la trame sera de 1500 octets.

http://en.wikipedia.org/wiki/Ethernet_frame

Cela dit, si vous souhaitez vraiment tester la fragmentation, un bon moyen de le faire est d'effectuer un bon vieux ping avec quelques drapeaux :

ping nom d'hôte -f -l taille des données

L'option -f fait échouer le ping si le paquet est fragmenté. La clé à comprendre ici est que "sizeofdata" est la quantité de données que vous pouvez mettre dans un message sans fragmenter - donc si vous envoyez une charge utile de 1500, vous commencerez à fragmenter dès que vous dépasserez 1500 octets. Réduisez cette taille à 1472 (1500 - les 18 octets de surcharge), et vous verrez que les pings passeront.

0voto

Christian Jensen Points 101

Pour la trame Ethernet_II de base, la taille de la trame est de 1518 octets (sur ou hors fil). Elle se compose de 6 octets pour l'adresse de destination et l'adresse source, de 2 octets pour le champ de type entre 46 et 1500 octets pour la charge utile (dans votre cas, le paquet IP entier avec son en-tête IP et son en-tête UDP) et de 4 octets pour le FCS. En outre, la taille d'une trame est limitée à 64 octets. C'est pourquoi la plage est de 46 octets (ajoutez cela aux deux adresses, au type et au FCS et vous obtenez 64 octets - 46+6+6+2+4=64).

Si la trame se trouve sur un réseau qui prend en charge plusieurs vlans et que vous devez marquer la trame avec une balise vlan, un champ supplémentaire est ajouté avant le champ type. Il s'agit de 4 octets. Cela signifie que la gamme de tailles pour la charge utile peut être réduite de 4 octets à l'extrémité inférieure, tout en conservant un minimum de 64 octets. D'où les 42. (Donc 42+6+6+2+4 + 4 pour la balise vlan = 64)

Ainsi, lorsque la fourchette est écrite 1500-42, cela ne signifie pas 1500 moins 42, mais que tout ce qui est compris entre 1500 et 42 octets est valable. Sur le fil, cette trame balisée peut atteindre 1522 octets (si une seule balise est utilisée, ou 1526 si deux balises sont utilisées). Rien de tout cela n'explique le nombre 1542.

Pour arriver à ce chiffre, il faut voir comment une trame peut être envoyée sur Ethernet. Il n'y a pas d'horloge sur un réseau local Ethernet, de sorte qu'une série de 1 et de 0 est envoyée par l'émetteur d'une trame pour régler l'horloge. C'est ce qu'on appelle le préambule. Tous les auditeurs n'entendront pas la totalité du préambule, mais la plupart d'entre eux devraient en entendre une partie. Pour signaler la fin du préambule, l'un des 8 derniers bits envoyés est inversé, de sorte qu'au lieu de 10101010, il devient 10101011. Cet octet est appelé délimiteur de début de trame (SDF). Il n'est pas techniquement utile de le capturer sur le fil, de sorte que les 7 octets du préambule et le SDF d'un octet ne sont normalement pas comptés, mais s'ils l'étaient, nos 1518 d'origine seraient maintenant 1526. Ce n'est pas encore 1542

Après l'envoi d'une trame, il y a un silence forcé sur le fil, appelé intervalle inter-trame. Cela équivaut à une transmission de 12 octets. Cet espace n'est pas non plus compté ou capturé, mais s'il l'était, il nous amènerait à 1538 octets. La seule façon de passer de 1538 à 1542 est de dire que la trame est balisée (c'est-à-dire qu'elle contient la balise de plan de 4 octets). Ouf, enfin 1542.

Tout est dans la terminologie. Une trame standard représente 1518 octets sur le fil (en ce qui concerne tout dispositif de capture). Une trame balisée (une seule balise) représente 1522 octets sur le câble. Ces trames occupent 1538 octets ou 1542 octets d'espace de transmission sur le câble.

J'espère que cela aidera à clarifier

-1voto

joseph Points 1

Non, vous ne voulez pas qu'il y ait de fragmentation, c'est pourquoi vous les paquets doivent être fragmentés, mais l'ensemble df Prenons l'exemple d'une autoroute à double sens avec un grand nombre de semi-remorques par rapport à la même autoroute avec un grand nombre de petites voitures intelligentes qui vont toutes deux vers la même destination. Les semi-remorques transportent plus de charge utile mais sont plus lents et peuvent encombrer plus facilement. Les petites voitures transportent moins de charge utile mais voyagent plus vite.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X