VxRail: vCenter viser advarslen "Høj pnic rx generisk fejlrate registreret" eller "Høj pNic-fejlrate registreret"

Der er to forskellige problemer i forbindelse med dette budskab, som skal behandles forskelligt.

Udgave 1:
vCenter-webklienten viser nedenstående meddelelse for flere værter. Ikonet vmnic I advarslen kan være enhver vmnic at værterne opretter forbindelse til netværket.
**Dette adskiller sig fra udgave 2 (nævnt i det følgende). Ikonet vmnic i alarmen for problem 2 er kun Aktiv og (eller) Standby vmnic af vSAN.**

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

Når du kører følgende kommando på ESXi-værten, ser brugerne mange rx (modtag) længdefejl, og fejlen fortsætter med at vokse. Dette udløser advarslen.
(erstat 'X' med det korrekte vmnic antal)

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 i værten har næsten identiske "Receive length error" Tæller. Det betyder, at "Multicast packets received" eller "Broadcast packets received" bidrage til "Receive length errors."

**Multicast-pakker oversvømmes i det samme VLAN, ligesom broadcast-pakker normalt.

Vi kan beregne forholdet mellem modtagelseslængdefejl og udsendelsespakker eller forholdet mellem modtagelseslængdefejl og multicast-pakker. Sammenlign dem derefter med andre noder.

Selv på forskellige noder er procentdelen af modtagelseslængdefejl forårsaget af multicast eller udsendelse næsten den samme.**

Hvis du vil foretage fejlfinding af problem 1, skal du registrere pakker i vmnic:

1. SSH til noden
2. Kør nedenstående kommando: (udskift "vmnicX" med vmnic der modtog længdefejl)

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

3. Registrer fejlen uplink-pakker, og stop med ctrl+c.
4. Download .pcap fil til det lokale skrivebord og åbn det med Wireshark.
5. For udsendelsespakker Filtrer: ip.addr == 255.255.255.255 
6. For multicast-pakker Filter: eth.dst == ff:ff:ff:ff:ff:ff 
7. Prøv at finde "Malformed Packet" fra filterresultatet.
8. Lejlighedsvis fungerer dette filter (kun på Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Nr. 2:
Alarmen er navngivet.

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

Når brugeren tjekker værtens vSAN-ydeevnevisning, kan vedkommende konstatere, at ikonet vmnic nævnt i alarmen er altid Aktiv eller (og) Standby vmnic af vSAN-trafik.
Og for det meste er vmnic er standby for vSAN.
Denne alarm er involveret fra vSphere 7.0U2.
Se: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Følgende tabel viser målepunkterne for de målepunkter for pNIC'er, der bruges til vSAN, som overvåges, og deres alarmtærskler:

Disse typer fejl kan påvirke vSAN-ydeevnen.

Problem 1:
I dette tilfælde viser en pakkeregistrering en Cisco Access Point (AP)-controller, der sender CAPWAP-Control-pakker.
Wireshark markerer dem som en misdannet pakke.
ESXi kan normalt heller ikke håndtere denne type pakke.

Hvis Wireshark støder på en pakke, der ikke er i overensstemmelse med protokollens forventede struktur under analysen, markerer den pakken som "Misdannet". Dette indikerer typisk, at pakken kan være blevet beskadiget under transmission, eller det repræsenterer en usædvanlig eller forkert implementering af en protokol.

Følgende filter kan levere en anden type output (fordi rammelængde ikke understøttes) og kan også forårsage "received length error."
Det er dog ikke nøjagtigt, så inden rapporten sendes til kunden, skal der foretages yderligere analyse af outputtet af dette filter.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Nr. 2:
VMware introducerede denne alarm for at overvåge de fejl, der kan påvirke vSAN-ydeevnen.
Når procentdelen af fejlen når specialværdien. En alarm udløses for at nævne for brugeren, at vSAN-ydeevnen skal plejes.

Vi har dog observeret, at algoritmen til alarmudløsning kan have problemer. Ved beregning af fejlpakkeforholdet anvendes antallet af datapakker på kort sigt og det samlede antal fejlpakker.

Så det meste af tiden er fejlen vmnic er altid standby vmnic af vSAN, fordi der er mindre trafik på vmnic.

Problem 1:

• I tilfældet med problem 1 var kildens IP-adresse en Cisco AP-controller, der var tilsluttet VLAN 1.
• Kontroller vDS-indstillingerne for VxRail-klyngen for at sikre, at der ikke er trafik, der bruger VLAN 1.
• Fjern VLAN 1 fra TOR-switchportene, som er forbundet til VxRail-værter.
• Hvis det ikke er i VLAN 1, skal du følge de samme trin for at fjerne VLAN et fra switchportene.
• Hvis VLAN transporterer klyngetrafik, kan vi ikke fjerne VLAN et fra switchportene. Brugeren skal muligvis ændre netværksdesignet for at isolere den trafik, der forårsagede den modtagne længdefejl fra VxRail-klyngen.

Nr. 2:
Der er flere scenarier til at håndtere denne type problemer.

• Ikonet vmnic Rapporteringsfejl er standby vmnic af vSAN, og væksten i fejlpakken er langsom.

Dette er en falsk alarm forårsaget af algoritmen og påvirker ikke vSAN-ydeevnen. Vi kan anbefale, at kunder ignorerer denne alarm, selvom denne alarm vises igen fra tid til anden.

• Ikonet vmnic Rapporteringsfejl er den aktive vmnic af vSAN eller standby vminc, men fejlpakkerne fortsætter med at vokse.

De forskellige typer fejl følger forskellige opløsninger, vi støder ofte på alarmen forårsaget af CRC-fejl, Modtaget længdefejl og Pause Ramme modtaget.

1. Modtog CRC-fejl på vmnic.

   Et hardwareproblem forårsager normalt CRC-fejl. Mest relateret til kabel, SFP og netværksadapter, både node og switchside
   Følg hardwarefejlfindingsprocessen for at finde problemet.

2. Modtagne længdefejl på vmnic.

   Den grundlæggende årsag er den samme som udgave 1. Du kan følge fejlfindingen af problem 1 for dette scenarie.

3. Billede af pause modtaget på vmnic.

   Pause Frame bruges til styring af netværksflow.
   Aktivér flowstyring Ustabilitet eller overbelastning af netværket bidrager til lav ydeevne i VxRail og har en negativ indvirkning på vSAN I/O-datalagerdriften.
   Flowkontrol er en switchfunktion, der hjælper med at administrere dataoverførselshastigheden for at undgå bufferoverløb.
   VxRail anbefaler, at flowstyring "receive on" and "transmit off."
   Se https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf side 88.

Hvordan kontrolleres det, om kontakten aktiverer flowkontrol?
Tag Dell-switchen som et eksempel:

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

Sådan deaktiveres flowkontroloverførsel?

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

Konfigurer alle switchgrænseflader, som er forbundet til vSAN vmnics som sende.
Nulstil alarmen til grøn, og overvåg, om alarmen vender tilbage.