VxRail: vCenter zeigt die Warnung „Hohe Anzahl an Fehlern vom Typ „pnic rx generic error“ oder „Hohe pNIC-Fehlerrate erkannt“ 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. Die VMNIC in der Warnung kann eine beliebige VMNIC sein, die die Hosts mit dem Netzwerk verbinden.
**Dies unterscheidet sich von Problem 2 (siehe unten). Die VMNIC im Alarm von Problem 2 ist nur die aktive und (oder) Stand-by-VMNIC von vSAN.**

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

Beim Ausführen des folgenden Befehls auf dem ESXi-Host werden NutzerInnen viele Fehler vom Typ „rx (Receive) length“ angezeigt und der Fehler wächst weiter. Dies löst die Warnung aus.
(Ersetzen Sie das „X“ durch die richtige VMNIC-Nummer.)

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 auf dem Host haben nahezu identische "Receive length error" Zählerstände. Das bedeutet, dass "Multicast packets received" oder "Broadcast packets received" beitragen zu "Receive length errors."

**Multicast-Pakete strömen massenweise in dasselbe VLAN wie normalerweise Broadcast-Pakete.

Wir können das Verhältnis von „received length“-Fehlern zu Broadcast-Paketen oder das Verhältnis von „received length“-Fehlern zu Multicast-Paketen berechnen. Vergleichen Sie sie dann mit anderen Nodes.

Selbst auf verschiedenen Nodes ist der Prozentsatz der durch Multicast oder Broadcast verursachten „received length“-Fehler nahezu identisch.**

Um Problem 1 zu beheben, erfassen Sie Pakete in der VMNIC:

1. Stellen Sie über SSH eine Verbindung her mit Node
2. Führen Sie den folgenden Befehl aus: (Ersetzen Sie „vmnicX“ mit der VMNIC mit dem „received length“-Fehler)

   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 den lokalen Desktop herunter 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, das fehlerhafte Paket im Filterergebnis zu finden.
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 in der Warnung erwähnte VMNIC immer die aktive (und) Stand-by-VMNIC des vSAN-Datenverkehrs ist.
In den meisten Fällen ist die VMNIC die Stand-by-VMNIC des vSAN.
Dieser Alarm tirtt ab vSphere 7.0U2 auf.
Siehe: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Die folgende Tabelle zeigt die Kennzahlen der für überwachte vSAN verwendeten 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, markiert es das Paket als „fehlerhaft“. 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 zu Folgendem führen: "received length error."
Dies ist jedoch nicht korrekt. Daher muss vor der Übermittlung des Berichts an KundInnen eine weitere Analyse der Ausgabe dieses Filters durchgeführt werden.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problem 2:
VMware hat diesen Alarm eingeführt, um Fehler zu überwachen, die sich auf die vSAN-Leistung auswirken können.
Wenn der Prozentsatz des Fehlers den Sonderwert erreicht, wird ein Alarm ausgelöst, um NutzerInnen darauf hinzuweisen, dass auf die vSAN-Performance geachtet werden sollte.

Wir haben jedoch beobachtet, dass der Algorithmus für die Alarmauslösung Probleme machen 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 die fehlerhafte VMNIC immer die Stand-by-VMNIC von vSAN, da weniger Datenverkehr auf der VMNIC vorhanden ist.

Problem 1:

• Im Fall von Problem 1 war die Quell-IP-Adresse 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.

• Der VMNIC-Reporting-Fehler ist die Stand-by-VMNIC von vSAN und die Zunahme von Fehlerpaketen 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.

• Der VMNIC-Reporting-Fehler ist die aktive VMNIC von vSAN oder Stand-by-VMNIC, 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. CRC-Fehler auf der VMNIC empfangen.

   Ein Hardwareproblem führt in der Regel zu CRC-Fehlern. Hauptsächlich im Zusammenhang mit Kabel, SFP und Netzwerkadapter, sowohl auf Node- als auch auf Switch-Seite
   Befolgen Sie den Hardware-Fehlerbehebungsprozess, um das Problem zu lokalisieren.

2. Fehler „Received length“ auf der VMNIC.

   Die Ursache ist die gleiche wie bei Problem 1. Sie können das Troubleshooting von Problem 1 für dieses Szenario befolgen.

3. Auf der VMNIC empfangenes „Pause Frame“.

   „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 Zwischenspeicherüberlauf zu vermeiden.
   VxRail empfiehlt, dass die Flusssteuerung "receive on" and "transmit off."
   Siehe https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf Seite 88.

Wie kann überprüft werden, ob der Switch die Flusssteuerung aktiviert?
Nehmen wir 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

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

Wie deaktiviere ich die Übertragung der Flusssteuerung?

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

Konfigurieren Sie alle Switchschnittstellen, die mit der vSAN-VMNICs verbunden sind, als „Transmit Off“.
Setzen Sie den Alarm auf Grün zurück und überwachen Sie, ob der Alarm zurückkehrt.