vCenter affiche des avertissements « High pnic rx generic error rate detected » ou « High pNic error rate detected »

Ce message comporte deux problèmes différents qui doivent être traités différemment.

Problème 1 : le client Web vCenter affiche le message ci-dessous pour plusieurs hôtes. La commande vmnic dans l’avertissement peut être n’importe quel vmnic que les hôtes se connectent au réseau.
Ceci est différent du problème 2 (mentionné ci-dessous). La commande vmnic dans l’alarme du problème 2 seulement est l’actif et (ou) en veille vmnic de vSAN.

Warning: High pnic rx generic error rate detected on vmnicX.

Lors de l’exécution de la commande suivante sur l’hôte ESXi, les utilisateurs constatent de nombreuses rx (Receive) erreurs de longueur et l’erreur ne cesse de croître. Cela déclenche l’avertissement.
Remettez en place le 'X' avec le bon vmnic Nombre.

esxcli network nic stats get -n vmnicX

vmnic0
Packets received: 2611289
Receive length errors: 279662
Multicast packets received: 529478
Broadcast packets received: 512315

vmnic1
packets received: 5812398
Receive length errors: 279518
Multicast packets received: 538956
Broadcast packets received: 427913 

Tous vmnics dans l’hôte ont presque identique Receive length error quasiment identiques. Cela signifie que Multicast packets received ou Broadcast packets received contribue à Receive length errors.

Les paquets de multidiffusion sont inondés dans le même VLAN, comme le sont généralement les paquets de diffusion.

Nous pouvons calculer le rapport entre l’erreur de longueur de réception et les paquets de diffusion, ou le rapport entre l’erreur de longueur de réception et les paquets de multidiffusion, puis les comparer avec d’autres nœuds.

Même sur des nœuds différents, le pourcentage d’erreurs de longueur de réception causées par la multidiffusion ou la diffusion est presque le même.

Pour résoudre le problème 1, capturez les paquets dans le vmnic:

1. SSH au nœud
2. Exécutez la commande ci-dessous : (Remettez en place le vmnicX avec l' vmnic qui a reçu une erreur de longueur)

   pktcap-uw --uplink vmnicX --dir 2 -o /tmp/lengtherror.pcap

3. Capturez les paquets de données sortantes en erreur et arrêtez-vous à la commande ctrl+c.
4. Téléchargez le .pcap sur le bureau local et ouvrez-le avec Wireshark.
5. Pour le filtre de paquets de diffusion : ip.addr == 255.255.255.255 
6. Pour le filtre de paquets de multidiffusion : eth.dst == ff:ff:ff:ff:ff:ff 
7. Essayez de trouver le Malformed Packet à partir du résultat du filtre.
8. Parfois, ce filtre fonctionne (uniquement sur Wireshark 4.0.12) : ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problème 2 :
l’alarme est nommée.

High pNic error rate detected Check the host's vSAN performance view for details.

Lorsque l’utilisateur consulte la vue des performances vSAN de l’hôte, il peut constater que le vmnic mentionné dans l’alarme est toujours l’Active ou (et) Standby vmnic du trafic vSAN.
La plupart du temps, le vmnic est la veille du vSAN.
Cette alarme est impliquée à partir de vSphere 7.0U2.
Voir : https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Le tableau suivant présente les mesures des cartes pNIC surveillées pour vSAN et leurs seuils d’alarme :

Ces types d’erreurs peuvent avoir un impact sur les performances vSAN.

Problème 1 :
dans ce cas, une capture de paquets montre un contrôleur de point d’accès (AP) Cisco envoyant des paquets CAPWAP-Control.
Wireshark les marque comme étant des paquets mal formés.
ESXi ne peut généralement pas non plus gérer ce type de paquet.

Si Wireshark rencontre un paquet qui n’est pas conforme à la structure attendue du protocole lors de son analyse, il marque le paquet comme étant mal formé. Cela indique généralement que le paquet a peut-être été corrompu pendant la transmission ou qu’il s’agit d’une implémentation inhabituelle ou incorrecte d’un protocole.

Le filtre suivant peut fournir un autre type de sortie (car la longueur de trame n’est pas prise en charge) et peut également provoquer le received length error.
Toutefois, ce n’est pas exact. Par conséquent, avant d’envoyer le rapport au client, une analyse plus approfondie doit être effectuée sur la sortie de ce filtre.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problème 2 :
VMware a introduit cette alarme pour surveiller les erreurs susceptibles d’avoir un impact sur les performances vSAN.
Une alarme est déclenchée pour mentionner à l’utilisateur que les performances vSAN doivent être traitées lorsque le pourcentage d’erreur atteint la valeur spéciale.

Cependant, il a été observé que l’algorithme de déclenchement des alarmes peut avoir des problèmes. Lors du calcul du taux de paquets d’erreur, le nombre de paquets de données à court terme et la quantité totale de paquets d’erreur sont utilisés.

Donc, la plupart du temps, l’erreur vmnic Est toujours en veille vmnic de vSAN, car il y a moins de trafic sur le vmnic.

Problème 1 :

• L’adresse IP source était un contrôleur Cisco AP connecté au VLAN 1.
• Vérifiez les paramètres VDS du cluster VxRail pour vous assurer qu’il n’y a pas de trafic utilisant VLAN 1.
• Retirez le VLAN 1 des ports des commutateurs TOR connectés aux hôtes VxRail.
• S’il ne se trouve pas dans le VLAN 1, suivez les mêmes étapes pour supprimer le VLAN des ports de commutateur.
• Si le VLAN transporte le trafic du cluster, nous ne pouvons pas supprimer le VLAN des ports de commutateur. L’utilisateur devra peut-être modifier la conception du réseau pour isoler le trafic qui a causé l’erreur de longueur reçue du cluster VxRail.

Problème 2 :
il existe plusieurs scénarios pour gérer ce type de problème.

• La commande vmnic L’erreur de signalement est la veille vmnic de vSAN, et la croissance des paquets d’erreur est lente.

Il s’agit d’une fausse alarme provoquée par l’algorithme et n’affecte pas les performances de vSAN. Nous recommandons aux clients d’ignorer cette alarme, bien que celle-ci réapparaisse de temps à autre.

• La commande vmnic L’erreur de signalement est l’erreur active vmnic de vSAN ou en veille vminc, mais les paquets d’erreur continuent de croître.

Les différents types d’erreurs suivent des résolutions différentes. Nous rencontrons souvent l’alarme causée par l’erreur CRC, l’erreur de longueur reçue et l’image en pause reçue.

1. Erreurs CRC reçues sur le vmnic.
   Un problème matériel provoque généralement des erreurs CRC. Ils sont principalement liés aux câbles, SFP et adaptateurs réseau, à la fois les nœuds et les côtés du commutateur. Suivez la procédure de dépannage matériel pour localiser le problème.

2. Erreurs de longueur reçues sur le vmnic.
   La cause première est la même que celle du problème 1. Vous pouvez suivre le dépannage du problème 1 pour ce scénario.

3. Trame de pause reçue sur le vmnic.
   Pause Frame est utilisé pour le contrôle des flux réseau.
   Activer le contrôle de flux L’instabilité ou l’encombrement du réseau contribue aux faibles performances de VxRail et a un effet négatif sur les opérations du magasin de données d’E-S vSAN.
   Le contrôle de flux est une fonctionnalité de commutation qui permet de gérer le débit de transfert de données afin d’éviter le dépassement de la mémoire tampon.
   VxRail recommande que le contrôle de flux soit receive on et transmit off.
   Voir https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf page 88.

Comment vérifier si le commutateur permet le contrôle de flux :
Prenez le commutateur Dell comme exemple :

Run the command "show interface ethernet 1/1/1," replacing the switch interface number with the interface connecting the node

S5048-01# show interface ethernet 1/1/1
Ethernet 1/1/1 is up, line protocol is down
Pluggable media present, SFP28 type is SFP28 25GBASE-SR-NOF
    Wavelength is 850
Interface index is 15
Internet address is not set
Mode of IPv4 Address Assignment: not set
Interface IPv6 oper status: Disabled
MTU 1532 bytes, IP MTU 1500 bytes
LineSpeed 0, Auto-Negotiation off
Configured FEC is cl108-rs, Negotiated FEC is cl108-rs
Flowcontrol rx on tx on  ----- tx on means that the flow control is transmit on

Comment désactiver la transmission du contrôle de flux :

S5048-01# configure terminal
S5048-01(config)# interface e1/1/1 ----replace the switch interface number
S5048-01(conf-if-eth1/1/1)# flowcontrol transmit off

Configurer toutes les interfaces de commutateur connectées au vSAN vmnics Comme transmit off.
Réinitialisez l’alarme en vert et surveillez si l’alarme revient.