Introduction
Ce document décrit comment dépanner le paquet Ethernet endommagé sur Cisco Nexus 9000 lorsqu'une information de remplissage est endommagée ou malformée.
Informations générales
La taille minimale d’une trame Ethernet est de 64 octets, quelle que soit la balise VLAN qui y est présente ou non.
La taille minimale de la charge utile Ethernet est la suivante :
- 46 octets si la balise VLAN est absente.
- 42 octets si la balise VLAN est présente.
Vous pouvez vérifier ce fait :
La taille minimale d’un paquet Ethernet est de 64 octets, quel que soit l’en-tête du VLAN présent ou non. Le serveur est autorisé à envoyer un paquet de 64 octets qui contient un VLAN, que vous devez accepter et traiter correctement.
Note: Ce comportement est correctement géré par un Catalyst 4500x et non par Nexus 9k.
Comment un paquet est-il traité par un commutateur ?
Étape 1. Recevez une trame Ethernet VALIDE de 64 octets.
Étape 2. Supprimez la séquence de contrôle de trame (FCS, Frame Check Sequence), de sorte que le paquet devient de 60 octets.
Étape 3. Supprimez la balise VLAN, de sorte que le paquet soit long de 56 octets.
Étape 4. Ajoutez un remplissage pour faire 60 octets de paquet.
Étape 5. Il ajoute le FCS, ce qui fait que le paquet a 64 octets de long.
Le remplissage ne doit pas être modifié lorsqu'un paquet passe par un commutateur cut-through.
Remplissage modifié avec des VLAN étiquetés lorsque le trafic traverse N9K
Au lieu de remplir le paquet avec des zéros, le paquet est rempli de caractères d'ordures, dans la plupart des cas, il n'a aucun impact car les sommes de contrôle ne sont pas modifiées et donc personne n'utilise ces données. Cependant, si les clients ont une utilisation particulière et ont besoin de recalculer les sommes de contrôle, ces données de déchets conduisent à la corruption des sommes de contrôle au bout du compte (d'autres appliances, comme NAT/load-balancers, peuvent également voir le problème).
Le périphérique est un N9K 93120TX (détecté initialement sur un 9372TX, cependant), la version est la dernière NXOS 7.0(3)I2(2a).
Utilisez ici des hôtes Linux avec du matériel directement connecté au N9K (aucune virtualisation de quelque sorte que ce soit) (liaisons 1000base-T).
Utilisez cette configuration :
interface Ethernet1/59
switchport mode trunk
!
interface Ethernet1/60
switchport mode trunk
linux configurations:
inet 10.2.1.1/24 brd 10.2.1.255 scope global eth1 <= native vlan
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth1.100 <= taggued vlan 100
ou
Il suffit de connecter l'hôte Windows et d'envoyer les trames marquées, elles doivent déclencher le problème. En outre, assurez-vous que la carte réseau (NIC) est capable d’étiqueter le paquet.
Le commutateur ajoute le remplissage non nul aux trames qui passent.
Exemple : Hôte — [Trunk] N9K [Trunk] — Hôte
Vous pouvez utiliser netcat pour envoyer et recevoir les paquets.
Comme l’illustre l’image, il envoie Side (VLAN 100 balisé), le port e1/59 sur le commutateur.
Il reçoit côté (VLAN 100 balisé), port e1/60 sur le commutateur, comme illustré sur l'image :
Comme l’illustre l’image, le paquet est transmis.
Le paquet est reçu, comme le montre l'image :
Comme le montre l'image, le mauvais remplissage est mis en surbrillance.
Ceci est également affiché avec un analyseur de paquets (dans un autre paquet, les données sont différentes des captures d'écran précédentes mais le test et le bogue sont identiques),
Solution
La solution de contournement est de désactiver buffer-booster sur l'interface où ce serveur est connecté.
C9396PX-1(config)# int et 1/7
C9396PX-1(config-if)# no buffer-boost
Défaillance associée :
CSCva46849 Trame de 60 octets avec commutation L2 en-tête dot1q sur N9k