VxRail : vCenter affichant l’avertissement « Taux d’erreur générique rx pnic élevé détecté » ou « Taux d’erreur pNic élevé détecté »

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. Le vmnic dans l’avertissement peut être n’importe quel vmnic que les hôtes connectent au réseau.
**Il s’agit d’un problème différent du problème 2 (mentionné ci-dessous). Le vmnic dans l’alarme du problème 2 uniquement est le vmnic actif et (ou) de secours 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 voient de nombreuses erreurs de longueur rx (réception) et l’erreur ne cesse de croître. Ceci déclenche l’avertissement.
(Remplacez le « X » par le numéro de vmnic approprié)

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 les vmnics de l’hôte ont des numéros "Receive length error" quasiment identiques. Cela signifie que "Multicast packets received" ou "Broadcast packets received" contribue à "Receive length errors."

**Les paquets de multidiffusion inondent le même VLAN, comme le font généralement les paquets de diffusion.

Nous pouvons calculer le rapport d’erreur de longueur de réception et de paquets de diffusion, ou le rapport d’erreur de longueur de réception et de paquets de multidiffusion. Ensuite, comparez-les avec d’autres nœuds.

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

Pour résoudre le Problème 1, capturez des paquets dans vmnic :

1. SSH au nœud
2. Exécutez la commande ci-dessous : (remplacez le « vmnicX » par le vmnic qui a reçu une erreur de longueur)

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

3. Collectez les paquets de données sortantes d’erreur et arrêtez avec ctrl+c.
4. Téléchargez le fichier .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. Recherchez le « Paquet mal formé » dans le 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 vérifie la vue des performances vSAN de l’hôte, il peut constater que le vmnic mentionné dans l’alarme est toujours le vmnic actif ou (et) de secours du trafic vSAN.
La plupart du temps, le vmnic est de secours 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 métriques des pNIC utilisés pour vSAN surveillés 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 pendant son analyse, il marque le paquet comme « 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 générer l’ "received length error."
Toutefois, il n’est pas exact. Par conséquent, avant de soumettre 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’affecter les performances vSAN.
Lorsque le pourcentage de l’erreur atteint la valeur spéciale. Une alarme est déclenchée pour indiquer à l’utilisateur que les performances vSAN doivent être prises en charge.

Toutefois, nous avons observé que l’algorithme de déclenchement d’alarme peut présenter des problèmes. Lors du calcul du rapport d’erreurs des paquets, le nombre de paquets de données sur une courte période et la quantité totale de paquets d’erreur sont utilisés.

La plupart du temps, l’erreur vmnic est toujours le vmnic de secours de vSAN, car il y a moins de trafic sur le vmnic.

Problème 1 :

• dans l’instance du 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.

• L’erreur de rapport vmnic est le vmnic de secours 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.

• L’erreur de rapport vmnic est le vmnic actif de vSAN ou le vminc de secours, 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 vmnic.

   Un problème matériel provoque généralement des erreurs CRC. Principalement en ce qui concerne le câble, le SFP et la carte réseau, côté nœud et commutateur.
   Suivez le processus de dépannage du matériel pour localiser le problème.

2. Erreurs de longueur reçues sur 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. Image en pause reçue sur vmnic.

   L’image en pause est utilisée pour le contrôle du débit réseau.
   Autoriser une instabilité ou une congestion du contrôle du débit réseau contribue à une faible performance dans VxRail, et a un effet négatif sur les opérations du datastore vSAN I-O.
   Le contrôle du débit est une fonctionnalité de commutateur qui permet de gérer le taux de transfert de données afin d’éviter une saturation de la mémoire tampon.
   VxRail recommande que le contrôle du débit soit "receive on" and "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 autorise le contrôle du débit ?
Prenons l’exemple du commutateur Dell :

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

Vxrail-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 de contrôle du débit ?

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

Configurez toutes les interfaces de commutateur connectées aux vmnics vSAN avec la transmission désactivée.
Réinitialisez l’alarme sur vert et vérifiez si l’alarme réapparaît.