VxRail: vCenter viser advarselen «High pnic rx generic error rate detected» eller «High pNic error rate detected»

Det er to forskjellige problemer for denne meldingen som må behandles annerledes.

Utgave 1:
vCenter-webklienten viser meldingen nedenfor for flere verter. VMNIC i advarselen kan være en hvilken som helst VMNIC som vertene kobler til nettverket.
**Dette er forskjellig fra utgave 2 (nevnt i det følgende). VMNIC-en i alarmen i utgave 2 er bare den aktive og (eller) standby-vmnic for vSAN.**

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

Når du kjører følgende kommando på ESXi-verten, ser brukerne mange rx (motta) lengdefeil, og feilen fortsetter å vokse. Dette utløser advarselen.
(erstatt 'X' med riktig 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 vmnic-er i verten har nesten identiske "Receive length error" Teller. Dette betyr at "Multicast packets received" eller "Broadcast packets received" bidra til "Receive length errors."

**Multicast-pakker oversvømmes i samme VLAN, som vanligvis kringkastingspakker.

Vi kan beregne forholdet mellom feil på mottakslengde og kringkastingspakker, eller forholdet mellom feil på mottakslengde og multicast-pakker. Sammenlign dem deretter med andre noder.

Selv på forskjellige noder er prosentandelen av mottakslengdefeil forårsaket av multicast eller kringkasting nesten den samme.**

Hvis du vil feilsøke problemet 1, må du registrere pakker i vmnic:

1. SSH til noden
2. Kjør kommandoen nedenfor: (erstatt "vmnicX" med VMNIC som mottok lengdefeil)

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

3. Registrer feilen uplink pakker, og stopp med ctrl + c.
4. Last ned .pcap-filen til det lokale skrivebordet og åpne den med Wireshark.
5. For kringkastingspakker Filter: ip.addr == 255.255.255.255 
6. For multikastingspakker Filter: eth.dst == ff:ff:ff:ff:ff:ff 
7. Prøv å finne den "misformede pakken" fra filterresultatet.
8. Noen ganger fungerer dette filteret (bare på Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Utgave 2:
Alarmen er navngitt.

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

Når brukeren sjekker vertens vSAN-ytelsesvisning, kan de oppdage at vmnic som er nevnt i alarmen, alltid er aktiv eller (og) standby vmnic for vSAN-trafikk.
Og mesteparten av tiden er vmnic standby for vSAN.
Denne alarmen er aktivert fra vSphere 7.0U2.
Se: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Følgende tabell viser måledataene for pNIC-er som brukes for vSAN som overvåkes, og deres alarmterskler:

Denne typen feil kan påvirke vSAN-ytelsen.

Problem 1:
I dette tilfellet viser en pakkeregistrering en Cisco Access Point (AP)-kontroller som sender CAPWAP-Control-pakker.
Wireshark markerer dem som en misformet pakke.
ESXi kan vanligvis ikke håndtere denne typen pakke heller.

Hvis Wireshark støter på en pakke som ikke samsvarer med den forventede strukturen til protokollen under analysen, markerer den pakken som "Malformed". Dette indikerer vanligvis at pakken kan ha blitt ødelagt under overføring, eller det representerer en uvanlig eller feil implementering av en protokoll.

Følgende filter kan gi en annen type utdata (fordi delbildelengden ikke støttes), og kan også forårsake "received length error."
Det er imidlertid ikke nøyaktig, så før du sender rapporten til kunden, må ytterligere analyse gjøres på utgangen av dette filteret.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Utgave 2:
VMware introduserte denne alarmen for å overvåke feilene som kan påvirke vSAN-ytelsen.
Når prosentandelen av feilen når spesialverdien. En alarm utløses for å nevne for brukeren at vSAN-ytelsen bør tas vare på.

Vi har imidlertid observert at algoritmen for alarmutløsing kan ha problemer. Ved beregning av feilpakkeforholdet brukes antall datapakker på kort sikt og den totale mengden feilpakker.

Så mesteparten av tiden er feilen vmnic alltid standby vmnic av vSAN, fordi det er mindre trafikk på vmnic.

Problem 1:

• I tilfelle av problem 1 var kildens IP-adresse en Cisco AP-kontroller koblet til VLAN 1.
• Kontroller vDS-innstillingene til VxRail-klyngen for å sikre at det ikke er trafikk via VLAN 1.
• Fjern VLAN 1 fra TOR-svitsjportene som er koblet til VxRail-verter.
• Hvis den ikke er i VLAN 1, følger du de samme trinnene for å fjerne VLAN fra bryterportene.
• Hvis VLAN fører klyngetrafikk, kan vi ikke fjerne VLAN fra svitsjportene. Brukeren må kanskje endre nettverksdesignet for å isolere trafikken som forårsaket den mottatte lengdefeilen fra VxRail-klyngen.

Utgave 2:
Det er flere scenarier for å håndtere denne typen problemer.

• VMNIC-rapporteringsfeilen er standby-vmnic for vSAN, og veksten av feilpakken er langsom.

Dette er en falsk alarm forårsaket av algoritmen og påvirker ikke vSAN-ytelsen. Vi kan anbefale at kundene ignorerer denne alarmen, selv om denne alarmen dukker opp igjen fra tid til annen.

• VMNIC-rapporteringsfeilen er den aktive vmnic for vSAN eller standby vminc, men feilpakkene fortsetter å vokse.

De forskjellige typer feil følger forskjellige oppløsninger, vi støter ofte på alarmen forårsaket av CRC-feil, Mottatt lengdefeil og Pause Frame mottatt.

1. Mottok CRC-feil på vmnic.

   Et maskinvareproblem forårsaker vanligvis CRC-feil. Mest relatert til kabel-, SFP- og nettverkskort, både node- og svitsjside
   Følg feilsøkingsprosessen for maskinvare for å finne problemet.

2. Mottok lengdefeil på vmnic.

   Den grunnleggende årsaken er den samme som utgave 1. Du kan følge feilsøkingen for utgave 1 for dette scenariet.

3. Pause Frame mottatt på vmnic.

   Pause Frame brukes til nettverksflytkontroll.
   Aktiver flytkontroll Ustabilitet eller overbelastning i nettverket bidrar til lav ytelse i VxRail, og har en negativ effekt på vSAN I-O-datalageroperasjoner.
   Flytkontroll er en svitsjfunksjon som hjelper deg med å administrere dataoverføringshastigheten for å unngå bufferoverløp.
   VxRail anbefaler at flytkontroll er "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 sjekke om bryteren aktiverer flytkontroll?
Ta Dell-svitsjen 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

Hvordan deaktivere overføring av flytkontroll?

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

Konfigurere alle svitsjgrensesnittene som er koblet til vSAN vmnics som overføring av.
Tilbakestill alarmen til grønt og følg med på om alarmen kommer tilbake.