MTU et fragmentation

13

Considérez ce qui suit: NAS avec interface 10G connecté à l'interface 10G sur le commutateur. Ordinateurs clients connectés pour basculer via Gigabit Ethernet.

  • Y aura-t-il un gain de performances si la taille du MTU est augmentée sur le NAS et le port du commutateur auquel le NAS est connecté si la taille du MTU n'est pas augmentée par rapport aux 1500 octets standard sur les cartes réseau clientes?

  • Cela causera-t-il des problèmes de fragmentation?

  • Comment les appareils "gèrent" les décalages dans MTU pour les interfaces sur un réseau commuté?

Sardine
la source
quel protocole utilisez-vous pour le trafic SAN?
Mike Pennington du
1
En fait, je pense que Path MTU Discovery (PMTUD) est assez courant sur les hôtes ces jours-ci, il est donc probable que le client envoie un message ICMP Fragmentation Needed (Type 3, Code 4) contenant son MTU, ce qui devrait amener l'hôte à réduire sa taille de paquet .

Réponses:

20

Aucun gain de performances n'existera sans que tout le monde utilise des paquets plus gros. Le but des trames jumbo est de regrouper plus de charge utile avec le même temps système. La capacité du NAS à envoyer des paquets plus importants n'a aucun sens si les clients ne le font pas aussi bien.

Il n'y aura aucune "fragmentation" du tout. La couche 2 (Ethernet) n'a aucun moyen si elle indique une "fragmentation nécessaire". Ceci est compris au niveau de la couche 3 (IP) par les routeurs qui envoient un message ICMP lorsqu'il doit abandonner le paquet car il ne rentrera pas dans l'interface du tronçon suivant. Cela ne peut pas se produire en l'absence de routeur - sur un réseau local plat et commuté. Les paquets géants envoyés depuis le NAS seront abandonnés par le client en tant que trame surdimensionnée - ou abandonnés par le commutateur pour la même raison. [Un paquet de 9k ne peut pas être envoyé sur une interface 1500B.]

Ricky Beam
la source
Ainsi, cela causera à peu près des problèmes sans fin, où le client ou le commutateur supprimera une grande partie du trafic du SAN?
nos
@Ricky - Comment pourrait se manifester l'abandon répété de paquets surdimensionnés? L'interface de réception a-t-elle un moyen de "dire" à l'expéditeur qu'il ne peut prendre que des trames de taille X? Ou l'expéditeur voit-il que la trame n'a jamais été reçue par un protocole de couche supérieure comme TCP?
sardean
1
Le paquet est abandonné et c'est la fin. (eh bien, un compteur se déclenche, mais a) personne ne le vérifie et b) vous ne saurez pas exactement ce qui l'a causé. etc.
Ricky Beam
5

Q: Y aura-t-il un gain de performances si la taille MTU est augmentée sur le NAS et le port de commutation auquel le NAS est connecté si la taille MTU n'est pas augmentée par rapport aux 1500 octets standard sur les cartes réseau client?

Réponse: Non, car la taille MTU accrue n'est pas utilisée par le client. Si vous vouliez transporter 100 personnes du point A au point B, vous pourriez utiliser deux bus ou 25 berlines. Si la route entre A et B est conçue pour que les bus puissent se déplacer plus facilement et sans retard, et que vous les déplaciez toujours dans les berlines, vous ne gagnez rien.

Q: Cela causera-t-il des problèmes de fragmentation?

Réponse: Non, la fragmentation se produit dans le scénario opposé lorsque vous envoyez un gros paquet alors que le chemin ne le prend pas en charge et doit le découper en paquets de taille pris en charge.

Q: Comment les appareils "gèrent" les décalages dans MTU pour les interfaces sur un réseau commuté?

Réponse: Si le paquet est plus petit que la taille de paquet autorisée, il est transmis sans problème. Si le paquet est plus grand que la taille autorisée, il est supprimé.

AdnanG
la source
1
Ce n'est pas vrai. Aucune fragmentation ne se produit au niveau de la couche 2. Il n'y a aucun moyen de négocier MTU sur un segment Ethernet. Si tout n'est pas configuré de la même manière, certains nics (avec le plus petit MTU) abandonneront les trames surdimensionnées.
Ricky Beam
Jetez un œil à supportforums.cisco.com/thread/20490 qui explique ce que je veux dire.
AdnanG
Je vois, merci de l'avoir signalé. Je retire cette partie de la réponse.
AdnanG
1

La MTU d'une session TCP est établie sur la connexion TCY SYN initiale. si vous avez une MTU qui ne correspond pas sur le réseau, cela n'aura pas d'importance pour votre application TCP ... couche 2 ou 3. UDP n'a pas le même concept donc oui, pour UDP vous commencerez à fragmenter le trafic qui peut / peut ne pas avoir d'impact sur les performances . Tout dépend du type de trafic, de la taille, du volume et de votre matériel.

payam
la source
0

Quelques trucs manqués ... Premièrement, il n'y a pas de négociations MTU. Deuxièmement, en discutant des paquets TCP SYN, ils vont rarement dépasser une taille de trame MTU de liaison. Dans cette régression, il y a des réponses PMTU lors de la discussion sur la couche 3 ainsi que TCP MSS qui fournissent une charge utile quelle est la taille maximale. Je ne dis pas que quelqu'un est incorrect ici, mais souvent les paramètres MTU peuvent passer inaperçus à cause de ces fonctionnalités.

Jason B Shrout
la source