Contenu

Introduction

Fond

Informations sur le remplissage

Fragmentation et erreur de correspondance MTU

Topologie

Dépannage MTU à l'aide du test ping

Ping avec taille de paquet 1500

Ping avec taille de paquet 5000

Introduction

Ce document décrit les différentes configurations de MTU et aborde également les scénarios qui impliquent le comportement avec différentes combinaisons et remplissage.

Fond

La fragmentation a lieu sur le chemin de couche 3 non sur le chemin de couche 2

Le remplissage est essentiellement utilisé pour s'assurer que l'en-tête de paquet IP a une longueur multiple de 32 bits

Prérequis

Fragmentation et réassemblage IP

MTU sur les commutateurs Cisco Nexus

Informations sur le remplissage

- L'expéditeur[initiateur] effectuera le remplissage, les périphériques de transit intermittents n'effectueront pas le remplissage

- Le remplissage ne doit pas être modifié lorsqu'un paquet passe par un commutateur cut-through

- Le commutateur considérera le paquet comme une trame de taille inférieure si l’émetteur n’est pas capable d’effectuer le remplissage

- La capture Wireshark aura lieu avant le remplissage

- En gros, le commutateur ajoute des octets supplémentaires même si la taille de paquet qu’il est sur le point d’envoyer au câble est inférieure à 64 milliards

- Lorsqu’un tramage Ethernet étiqueté 802.1q de 64 octets est reçu sur un port d’agrégation d’une couche 2/L3 et acheminé/transféré vers un port d’accès non étiqueté, la balise 802.1q est réduite et la taille de trame réduite de 4 octets

- Au cours du processus de démarquage d’une trame, la trame ne répond plus à la MTU minimale de 64 octets spécifiée dans la spécification IEEE 802.1q, le commutateur doit recadrer la trame à 64 octets

Fragmentation et erreur de correspondance MTU

- Si Path est L3, la fragmentation a lieu, le paquet ne sera pas abandonné.

- Si le chemin est L2, aucune fragmentation n’a lieu, le paquet sera complètement abandonné

- Lancez [ICMP] avec la taille de paquet 1540B et le chemin L2 est toujours en cours, mais vous ne voyez pas les pertes, où la taille totale devient 1568 [1540+20+8]

- Lancez [ICMP avec ] packet-size 1541B, total packet devient 1569, et vous voyez les pertes et les pertes sont vues comme des compteurs Giants

- En cas de non-correspondance MTU suite à l'incrémentation des compteurs - Jumbo, Giants, Runt, etc. sur la base du scénario et de la configuration.

Topologie

9K = MTU 9K [Jumbo]

1,5 K = MTU 1,5 K + configuré comme L2

La topologie des travaux pratiques ci-dessus a été divisée en plusieurs scénarios comme suit :

Dépannage MTU à l'aide du test ping

Ping avec taille de paquet 1500

Initialisation de la commande ping et réussite de la suppression de la commande ping.

Même si nous avons L2, nous ne voyons pas la perte comme la taille de la requête ping qu'il a fallu est par défaut un 1500.

N5K-1# ping 10.1.1.2 count 10

PING 10.1.1.2 (10.1.1.2): 56 data bytes

64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=3.228 ms

64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=4.832 ms

Ping avec taille de paquet 5000

Initialisation de la requête ping avec la taille de paquet 5000 avec le nombre de paquets 50 de N5k1 à Nexus-Sw2 et abandon en transit de L2

N5K-1# ping 10.1.1.2 packet-size 5000 count 50

PING 10.1.1.2 (10.1.1.2): 5000 data bytes

Request 0 timed out

Request 1 timed out

Paquet considéré comme Jumbo en entrée de Nexus-sw1

Nexus-Sw1# sh interface ethernet 3/3 | i MTU|jumbo

MTU 9216 bytes, BW 10000000 Kbit, DLY 10 usec

50 jumbo packets 0 storm suppression packets         >>>>>>> exact 50 jumbo packets are seeing in the RX counter.

Paquet considéré comme Jumbo à la sortie de Nexus-sw1

Nexus-Sw1# sh interface ethernet 3/1 | i MTU|jumbo     >>>>>>> Intertace connected towards to N7k2 with MTU 1500

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec

50 jumbo packets                                     >>>>>>> Exact 50 jumbo packets are egress in the TX.

Paquet abandonné en entrée de Nexus-sw2

Nexus-Sw2# sh interface et3/1  |  i MTU|giant          >>>>>>> Interface connected towards Nexus-Sw1 with e3/1 MTU 1500

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec

0 runts 50 giants 0 CRC/FCS 0 no buffer              >>>>>>> Exact 50 input error and 50 Giants packets observed in the RX counter.

50 input error 0 short frame 0 overrun 0 underrun 0 ignored

Nexus-Sw2# sh interface et3/4 |  i MTU|giant|error     >>>>>>> Interface with MTU 1500

MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec

0 runts 0 giants 0 CRC/FCS 0 no buffer                 >>>>>>> No counter seen

0 output error 0 collision 0 deferred 0 late collision >>>>>>> No counter seen