VxRail: vCenter wyświetla ostrzeżenie „Wykryto wysoki współczynnik błędów ogólnych pnic rx” lub „Wykryto wysoki współczynnik błędów pNic”

Z tym komunikatem wiążą się dwa różne problemy, które należy potraktować różnie.

Problem 1:
Klient internetowy vCenter wyświetla poniższy komunikat dla wielu hostów. Kartą vmnic wskazaną w ostrzeżeniu może być dowolna karta vmnic, którą hosty łączą z siecią.
**Jest inaczej niż w przypadku problemu 2 (wspomnianego poniżej). Tylko karta vmnic wskazana w alarmie dotyczącym problemu 2 jest aktywną i (lub) rezerwową kartą vmnic sieci vSAN**.

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

Podczas uruchamiania następującego polecenia na hoście ESXi użytkownicy widzą wiele błędów długości rx (odbieranej), a ich liczba stale rośnie. Powoduje to wyzwolenie ostrzeżenia.
(zastąp „X” prawidłowym numerem karty vmnic)

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 

Wszystkie karty vmnic na hoście mają prawie identyczne liczby "Receive length error" . Oznacza to, że "Multicast packets received" lub "Broadcast packets received" przyczynia się do "Receive length errors."

**Pakiety multicast zalewają tę samą sieć VLAN, jaką zwykle zalewają pakiety broadcast.

Możemy obliczyć stosunek liczby błędów długości odbieranej do liczby pakietów broadcast lub stosunek liczby błędów długości odbieranej i do liczby pakietów multicast. Następnie porównaj je z innymi węzłami.

Nawet w różnych węzłach procent liczby błędów długości odbieranej spowodowanych przez multicast lub broadcast jest prawie taki sam**.

Aby rozwiązać problem 1, przechwyć pakiety w vmnic:

1. Za pomocą protokołu SSH połącz się z węzłem
2. Uruchom następujące polecenie: (zastąp „vmnicX„ kartą vmnic z błędem długości odbierania)

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

3. Przechwyć pakiety uplink z błędem i zatrzymaj przechwytywanie za pomocą kombinacji klawiszy ctrl+c.
4. Pobierz plik .pcap na komputer lokalny i otwórz go za pomocą programu Wireshark.
5. Filtr pakietów broadcast: ip.addr == 255.255.255.255 
6. Filtr pakietów multicast: eth.dst == ff:ff:ff:ff:ff:ff 
7. Spróbuj znaleźć pozycję „Malformed Packet” w wynikach filtrowania.
8. Czasami ten filtr działa (tylko w Wireshark 4.0.12) w następujący sposób: ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problem 2:
Alarm ma nazwę.

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

Gdy użytkownik sprawdzi widok wydajności sieci vSAN na hoście, może stwierdzić, że karta vmnic wymieniona w alarmie jest zawsze aktywną lub (i) rezerwową kartą vmnic dla ruchu w sieci vSAN.
W większości przypadków karta vmnic jest kartą rezerwową sieci vSAN.
Ten alarm jest związany z vSphere 7.0U2.
Patrz: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
Poniższa tabela przedstawia wskaźniki dla monitorowanych kart pNIC używanych w sieci vSAN oraz ich progi alarmowe:

Tego typu błędy mogą mieć wpływ na wydajność sieci vSAN.

Problem 1:
W tym przypadku przechwytywanie pakietów pokazuje, że kontroler Cisco Access Point (AP) wysyła pakiety CAPWAP-Control.
Wireshark oznacza je jako zniekształcone.
ESXi zwykle także nie radzi sobie z takimi pakietami.

Jeśli podczas analizy Wireshark napotka pakiet, który nie ma oczekiwanej struktury zgodnie z protokołem, oznacza go jako „Zniekształcony”. Zazwyczaj oznacza to, że pakiet mógł zostać uszkodzony podczas transmisji albo reprezentuje nietypową lub niepoprawną implementację protokołu.

Poniższy filtr może mieć jeszcze inny typ danych wyjściowych (ponieważ długość ramki nie jest obsługiwana), a także może spowodować "received length error."
Nie jest on jednak dokładny, dlatego przed przesłaniem raportu do klienta należy przeprowadzić dalszą analizę danych wyjściowych tego filtra.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problem 2:
Firma VMware wprowadziła ten alarm w celu monitorowania błędów, które mogą mieć wpływ na wydajność sieci vSAN.
Gdy wartość procentowa błędów osiągnie wartość specjalną. Uruchamiany jest alarm informujący użytkownika o konieczności zajęcia się wydajnością sieci vSAN.

Zaobserwowaliśmy jednak, że algorytm wyzwalania alarmów może mieć problemy. Przy obliczaniu współczynnika pakietów z błędami wykorzystywana jest liczba pakietów danych za krótki okres oraz całkowita liczba pakietów z błędami.

Dlatego w większości przypadków karta sieciowa maszyny wirtualnej (vmnic) z błędem jest rezerwową vmnic sieci vSAN, ponieważ ruch na vmnic jest mniejszy.

Zagadnienie 1:

• W przypadku problemu 1 źródłowy adres IP wskazywał na kontroler Cisco AP podłączony do sieci VLAN 1.
• Sprawdź ustawienia vDS klastra VxRail, aby upewnić się, że nie ma ruchu korzystającego z sieci VLAN 1.
• Usuń sieć VLAN 1 z portów przełączników TOR podłączonych do hostów VxRail.
• Jeśli nie ma go w sieci VLAN 1, wykonaj te same czynności, aby usunąć sieć VLAN z portów przełączników.
• Jeśli sieć VLAN przenosi ruch klastra, nie można usunąć jej z portów przełączników. Użytkownik może być zmuszony do zmiany projektu sieci w celu odizolowania ruchu, który spowodował błąd długości odbierania z klastra VxRail.

Problem 2:
Istnieje kilka scenariuszy radzenia sobie z takim problemem.

• Zgłaszany błąd vmnic dotyczy rezerwowej karty vmnic sieci vSAN, a wzrost liczby pakietów z błędami jest powolny.

Jest to fałszywy alarm spowodowany przez algorytm, który nie wpływa na wydajność sieci vSAN. Możemy zalecić klientom zignorowanie tego alarmu, chociaż od czasu do czasu pojawia się on ponownie.

• Zgłaszany błąd vmnic dotyczy aktywnej karty vmnic sieci vSAN lub rezerwowej karty vminc, ale liczba pakietów z błędami dalej rośnie.

Różne typy błędów mają różne rozwiązania, często spotykamy się z alarmem spowodowanym błędem CRC, błędem odbieranej długości i odbieraną ramką wstrzymania.

1. Odebrano błędy CRC w vmnic.

   Błędy CRC zwykle powoduje problem sprzętowy. Dotyczy głównie adaptera kablowego, SFP i karty sieciowej, zarówno po stronie węzła, jak i przełącznika
   Postępuj zgodnie z procedurą rozwiązywania problemów ze sprzętem, aby zlokalizować problem.

2. Odebrano błędy długości w vmnic.

   Główna przyczyna jest taka sama jak w przypadku problemu 1. W tym scenariuszu możesz zastosować rozwiązywanie problemu 1.

3. Odebrano ramkę wstrzymania w vmnic.

   Ramka wstrzymania służy do kontroli przepływu w sieci.
   Włącz kontrolę przepływu Niestabilność lub przeciążenie sieci przyczynia się do niskiej wydajności VxRail i ma negatywny wpływ na operacje we/wy magazynu danych vSAN.
   Kontrola przepływu to funkcja przełącznika, która pomaga zarządzać szybkością transferu danych w celu uniknięcia przepełnienia buforu.
   Zespół VxRail zaleca, aby kontrola przepływu była "receive on" and "transmit off."
   Patrz https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf, str. 88.

Jak sprawdzić, czy przełącznik umożliwia kontrolę przepływu?
Weźmy dla przykładu przełącznik firmy Dell:

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

Jak wyłączyć transmisję z kontrolą przepływu?

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

Skonfiguruj wszystkie interfejsy przełączników podłączonych do vSAN vmnic jako „transmisja wyłączona”.
Zresetuj alarm do zielonego i monitoruj, czy alarm powróci.