vCenter zeigt die Warnungen "High pnic rx generic error rate detected" oder "High pNic error rate detected" an

Es gibt zwei verschiedene Probleme für diese Meldung, die unterschiedlich behandelt werden müssen.

Problem 1: Der vCenter Webclient zeigt die folgende Meldung für mehrere Hosts an. Bei der vmnic In der Warnung kann eine beliebige vmnic dass die Hosts eine Verbindung zum Netzwerk herstellen.
Dies unterscheidet sich von Problem 2 (das im Folgenden erwähnt wird). Bei der vmnic nur im Alarm von Ausgabe 2 ist die aktive und (oder) Standby-Funktion vmnic von vSAN.

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

Beim Ausführen des folgenden Befehls auf dem ESXi-Host sehen NutzerInnen viele rx (Receive) Längenfehler und der Fehler wächst weiter. Dies löst die Warnung aus.
Ersetzen Sie die 'X' mit der richtigen vmnic Anzahl.

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 

Alle vmnics im Host haben fast identische Receive length error Zählerstände. Das bedeutet, dass Multicast packets received oder Broadcast packets received beitragen zu Receive length errors.

Multicast-Pakete werden im selben VLAN geflutet, wie es normalerweise bei Broadcast-Paketen der Fall ist.

Wir können das Verhältnis von Empfangslängenfehlern und Broadcast-Paketen oder das Verhältnis von Empfangslängenfehler und Multicast-Paketen berechnen und sie dann mit anderen Knoten vergleichen.

Selbst auf verschiedenen Nodes ist der Prozentsatz der Empfangslängenfehler, die durch Multicast oder Broadcast verursacht werden, nahezu identisch.

Um Problem 1 zu beheben, erfassen Sie Pakete im vmnicverwalten:

1. Stellen Sie über SSH eine Verbindung her mit Node
2. Führen Sie den folgenden Befehl aus: (Ersetzen Sie die vmnicX mit dem vmnic die einen Längenfehler empfangen haben)

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

3. Erfassen Sie die fehlerhaften Uplink-Pakete und beenden Sie sie mit Strg+C.
4. Laden Sie die .pcap Datei auf dem lokalen Desktop und öffnen Sie sie mit Wireshark.
5. Für Broadcast-Paketfilter: ip.addr == 255.255.255.255 
6. Für Multicast-Paketfilter: eth.dst == ff:ff:ff:ff:ff:ff 
7. Versuchen Sie, die Malformed Packet aus dem Filterergebnis.
8. Gelegentlich funktioniert dieser Filter (nur auf Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problem 2:
Der Alarm hat einen Namen.

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

Wenn NutzerInnen die vSAN-Performanceansicht des Hosts überprüfen, stellen sie fest, dass die vmnic im Alarm erwähnt wird, ist immer der aktive oder (und) Standby vmnic des vSAN-Datenverkehrs.
In den meisten Fällen ist die vmnic ist die Stand-by-Datenbank des vSAN.
Dieser Alarm ist von vSphere 7.0U2 betroffen.
Siehe: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Die folgende Tabelle zeigt die Metriken für für überwachte vSAN verwendete pNICs und ihre Alarmschwellenwerte:

Diese Art von Fehlern kann sich auf die vSAN-Performance auswirken.

Problem 1:
In diesem Fall zeigt eine Paketerfassung einen Cisco AP-Controller (Access Point), der CAPWAP-Control-Pakete sendet.
Der Wireshark markiert sie als fehlerhafte Pakete.
ESXi kann diese Art von Paketen in der Regel auch nicht verarbeiten.

Wenn Wireshark bei der Analyse auf ein Paket stößt, das nicht der erwarteten Struktur des Protokolls entspricht, wird das Paket als fehlerhaft markiert. Dies weist in der Regel darauf hin, dass das Paket während der Übertragung beschädigt wurde, oder es handelt sich um eine ungewöhnliche oder falsche Implementierung eines Protokolls.

Der folgende Filter kann eine andere Art von Ausgabe bereitstellen (da die Frame-Länge nicht unterstützt wird) und kann auch dazu führen, dass die received length error.
Er ist jedoch nicht korrekt, sodass vor der Übermittlung des Berichts an den Kunden eine weitere Analyse der Ausgabe dieses Filters durchgeführt werden muss.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Ausgabe 2:
VMware hat diesen Alarm eingeführt, um die Fehler zu überwachen, die sich auf die vSAN-Leistung auswirken können.
Ein Alarm wird ausgelöst, um NutzerInnen darauf hinzuweisen, dass die vSAN-Leistung behoben werden sollte, wenn der Prozentsatz des Fehlers den speziellen Wert erreicht.

Es wurde jedoch beobachtet, dass der Algorithmus für die Alarmauslösung Probleme haben kann. Bei der Berechnung des Fehlerpaketverhältnisses werden die Anzahl der kurzfristigen Datenpakete und die Gesamtmenge der Fehlerpakete verwendet.

In den meisten Fällen ist der Fehler vmnic ist immer der Standby-Modus vmnic von vSAN, da es weniger Datenverkehr auf dem vmnic.

Problem 1:

• Die Quell-IP-Adresse war ein Cisco AP-Controller, der mit VLAN 1 verbunden war.
• Überprüfen Sie die vDS-Einstellungen des VxRail-Clusters, um sicherzustellen, dass kein Datenverkehr über VLAN 1 vorhanden ist.
• Entfernen Sie VLAN 1 von den TOR-Switchports, die mit VxRail-Hosts verbunden sind.
• Wenn es sich nicht im VLAN 1 befindet, befolgen Sie die gleichen Schritte zum Entfernen des VLAN aus den Switchports.
• Wenn das VLAN den Clusterdatenverkehr überträgt, kann das VLAN nicht von den Switchports entfernt werden. NutzerInnen müssen möglicherweise das Netzwerkdesign ändern, um den Datenverkehr, der den Fehler „Received length“ verursacht hat, vom VxRail-Cluster zu isolieren.

Problem 2:
Es gibt mehrere Möglichkeiten, diese Art von Problem zu behandeln.

• Bei der vmnic Fehlermeldung ist der Stand-by-Modus vmnic von vSAN, und das Wachstum der Fehlerpakete ist langsam.

Hierbei handelt es sich um einen vom Algorithmus verursachten Fehlalarm, der sich nicht auf die vSAN-Leistung auswirkt. Wir können KundInnen empfehlen, diesen Alarm zu ignorieren, obwohl dieser Alarm von Zeit zu Zeit wieder auftauchen wird.

• Bei der vmnic Meldefehler ist der aktive vmnic von vSAN oder Stand-by vminc, aber die Fehlerpakete nehmen weiter zu.

Die verschiedenen Arten von Fehlern benötigen unterschiedliche Lösungen. Wir stoßen häufig auf den Alarm, der durch CRC-Fehler, Fehler „Received length“ und „Pause Frame received“ verursacht wird.

1. Empfangene CRC-Fehler auf dem vmnic.
   Ein Hardwareproblem führt in der Regel zu CRC-Fehlern. Diese beziehen sich hauptsächlich auf Kabel, SFP und Netzwerkadapter, sowohl Nodes als auch Switch-Seiten. Befolgen Sie den Hardware-Fehlerbehebungsprozess, um das Problem zu finden.

2. Empfangene Längenfehler auf dem vmnic.
   Die Ursache ist die gleiche wie bei Problem 1. Sie können das Troubleshooting von Problem 1 für dieses Szenario befolgen.

3. Anhalten Frame empfangen am vmnic.
   "Pause Frame" wird für die Netzwerkflusssteuerung verwendet.
   Flusssteuerung aktivieren Eine Netzwerkinstabilität oder -überlastung führt zu einer geringen Performance in VxRail und wirkt sich negativ auf die vSAN-I-O-Datenspeichervorgänge aus.
   Die Flusssteuerung ist eine Switch-Funktion, mit der die Datenübertragungsrate verwaltet werden kann, um einen Pufferüberlauf zu vermeiden.
   VxRail empfiehlt, dass die Flusssteuerung receive on und transmit off.
   Siehe https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf Seite 88.

So überprüfen Sie, ob der Switch die Flusssteuerung aktiviert:
Nehmen Sie den Dell Switch als Beispiel:

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

So deaktivieren Sie die Übertragung der Flusssteuerung:

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

Konfigurieren aller mit dem vSAN verbundenen Switchschnittstellen vmnics Als transmit offaus.
Setzen Sie den Alarm auf Grün zurück und überwachen Sie, ob der Alarm zurückkehrt.