Nástroj vCenter zobrazuje výstrahy "High pnic rx generic error rate detected" nebo "High pNic error rate detected"

U této zprávy existují dva různé problémy, ke kterým je třeba přistupovat odlišně.

Problém 1:Webový klient vCenter zobrazuje níže uvedenou zprávu pro více hostitelů. Skript vmnic ve varování může být libovolná vmnic že se hostitelé připojují k síti.
To se liší od problému 2 (zmíněného v následujícím textu). Skript vmnic pouze v alarmu vydání 2 je aktivní a (nebo) pohotovostní režim vmnic sítě vSAN.

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

Při spuštění následujícího příkazu na hostiteli ESXi se uživatelům zobrazí velké množství rx (Receive) chyby délky a chyba stále narůstá. Tím se spustí varování.
Namontujte 'X' se správnými vmnic Číslo.

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 

Vše vmnics v hostiteli mají téměř identické Receive length error . To znamená, že Multicast packets received nebo Broadcast packets received přispěje k Receive length errors.

Pakety vícesměrového vysílání jsou zaplaveny ve stejné síti VLAN jako obvykle pakety všesměrového vysílání.

Můžeme vypočítat poměr chyby délky příjmu a všesměrových paketů nebo poměr chyby délky příjmu a paketů vícesměrového vysílání a poté je porovnat s ostatními uzly.

Dokonce i na různých uzlech je procento chyb délky příjmu způsobených vícesměrovým nebo všesměrovým vysíláním téměř stejné.

Chcete-li vyřešit problém 1, zachytejte pakety v vmnic:

1. Připojte se k uzlu pomocí SSH
2. Spusťte příkaz níže: (Nahraďte vmnicX Pomocí tlačítka vmnic u kterého došlo k chybě délky)

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

3. Zachyťte chybové pakety uplinku a zastavte pomocí CTRL+C.
4. Stáhněte si .pcap soubor na místní plochu a otevřete jej pomocí Wiresharku.
5. Pro pakety broadcast použijte filtr: ip.addr == 255.255.255.255 
6. Pro pakety multicast použijte filtr: eth.dst == ff:ff:ff:ff:ff:ff 
7. Pokuste se najít Malformed Packet z výsledku filtru.
8. Občas tento filtr funguje (pouze u verze Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problém 2:
Výstraha je pojmenována.

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

Když uživatel zkontroluje zobrazení výkonu sítě vSAN hostitele, může zjistit, že vmnic uvedené v alarmu je vždy aktivní nebo (a) pohotovostní režim vmnic provozu sítě vSAN.
Ve většině případů vmnic je pohotovostní režim sítě vSAN.
Tento alarm je součástí systému vSphere 7.0U2.
Viz: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
V následující tabulce jsou uvedeny metriky pro pNIC používané pro vSAN, které jsou monitorovány, a jejich prahové hodnoty alarmů:

Tyto typy chyb mohou ovlivnit výkon sítě vSAN.

Problém 1:
V tomto případě zachytávání paketů ukazuje, že řadič Cisco Access Point (AP) odesílá pakety CAPWAP-Control.
Nástroj Wireshark je označí jako poškozený paket.
Systém ESXi obvykle nedokáže zpracovat ani tento typ balíčku.

Pokud Wireshark během analýzy narazí na paket, který neodpovídá očekávané struktuře protokolu, označí paket jako poškozený. To obvykle znamená, že paket mohl být poškozen během přenosu nebo představuje neobvyklou či nesprávnou implementaci protokolu.

Následující filtr může poskytnout jiný typ výstupu (protože délka rámce není podporována) a může také způsobit received length error.
Není však přesný, takže před odesláním reportu zákazníkovi je nutné provést další analýzu výstupu tohoto filtru.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problém 2:
Společnost VMware zavedla tento alarm, aby monitorovala chyby, které mohou ovlivnit výkon sítě vSAN.
Když procento chyby dosáhne speciální hodnoty, spustí se alarm, který uživateli sdělí, že je třeba řešit výkon sítě vSAN.

Bylo však pozorováno, že algoritmus pro spuštění alarmu může mít problémy. Při výpočtu poměru chybových paketů se vychází z počtu datových paketů v krátkodobém horizontu a celkového počtu chybových paketů.

Takže ve většině případů chyba vmnic je vždy v pohotovostním režimu vmnic vSAN, protože je menší provoz na vmnic.

Problém 1:

• Zdrojovou IP adresou byl řadič přístupového bodu Cisco připojený k síti VLAN 1.
• Zkontrolujte nastavení vDS clusteru VxRail a ujistěte se, že neprobíhá žádný provoz pomocí sítě VLAN 1.
• Odeberte síť VLAN 1 z portů přepínačů TOR, které jsou připojené k hostitelům VxRail.
• Pokud není v síti VLAN 1, postupujte stejným způsobem a odeberte síť VLAN z portů přepínače.
• Pokud síť VLAN přenáší provoz clusteru, nelze síť VLAN z portů přepínače odebrat. Uživatel může změnit návrh sítě, aby izoloval provoz, který způsobil přijatou chybu délky, z clusteru VxRail.

Problém 2:
K dispozici je několik scénářů, jak tento typ problému vyřešit.

• Skript vmnic Hlášení chyby je pohotovostní režim vmnic sítě vSAN a růst chybových paketů je pomalý.

Jedná se o falešnou výstrahu způsobenou algoritmem, který nemá vliv na výkon sítě vSAN. Zákazníkům můžeme doporučit, aby tuto výstrahu ignorovali, i když se čas od času znovu objeví.

• Skript vmnic Chyba hlášení je aktivní vmnic sítě vSAN nebo pohotovostního režimu vminc, ale chybové pakety stále rostou.

Různé typy chyb mají různá řešení, často se setkáváme s výstrahou způsobenou chybou CRC, chybou přijaté délky a přijatým rámcem pozastavení.

1. Přijaté chyby CRC na vmnic.
   Problém s hardwarem obvykle způsobuje chyby CRC. Většinou se týkají kabelů, SFP a síťových adaptérů, a to jak na straně uzlů, tak na straně přepínačů. Postupujte podle pokynů pro odstraňování problémů s hardwarem a vyhledejte problém.

2. Přijaté chyby délky na vmnic.
   Hlavní příčina je stejná jako u problému 1. V tomto scénáři můžete postupovat podle kroků odstraňování pro problém 1.

3. Pause Frame přijatý na vmnic.
   Rámec pozastavení se používá pro řízení toku sítě.
   Povolení řízení toku Nestabilita nebo zahlcení sítě přispívá k nízkému výkonu v systému VxRail a má negativní vliv na operace datového úložiště vSAN I/O.
   Řízení toku je funkce přepínače, která pomáhá řídit rychlost přenosu dat, aby nedocházelo k přetečení vyrovnávací paměti.
   Řešení VxRail doporučuje řídit tok receive on a transmit off.
   Viz https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf, strana 88.

Jak zkontrolovat, zda přepínač umožňuje řízení toku:
Jako příklad si vezměte přepínač Dell:

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

Jak zakázat přenos řízení toku:

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

Konfigurace všech rozhraní přepínačů připojených k síti vSAN vmnics Jako transmit off.
Resetujte budík na zelenou a sledujte, zda se budík vrátí.