VxRail: vCenter показує попередження "Виявлено загальний рівень помилок High pnic rx" або "Виявлено високий рівень помилок pNic"

У цьому повідомленні є два різні питання, до яких потрібно ставитися по-різному.

Випуск 1:
Веб-клієнт vCenter показує наведене нижче повідомлення для кількох хостів. Вмніком у попередженні може бути будь-який вмнік, який хости підключають до мережі.
** Це відрізняється від питання 2 (про нього йдеться нижче). vmnic у сигналі тривоги лише випуску 2 є активним та (або) резервним vmnic vSAN.**

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

Під час виконання наступної команди на хості ESXi користувачі бачать багато помилок довжини rx (Receive), і помилка продовжує зростати. Це викликає попередження.
(замініть 'X' на правильний номер 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 

Всі вмніки в хосту мають практично ідентичні "Receive length error" Розраховує. Це означає, що "Multicast packets received" або "Broadcast packets received" сприяти "Receive length errors."

** Багатоадресні пакети заливаються в тому ж VLAN, як і широкомовні пакети зазвичай.

Ми можемо розрахувати відношення похибки довжини прийому і широкомовних пакетів, або відношення похибки довжини прийому і багатоадресних пакетів. Потім порівняйте їх з іншими вузлами.

Навіть на різних вузлах відсоток похибки довжини прийому, спричиненої мультикастом або трансляцією, майже однаковий.**

Щоб усунути неполадки з Проблемою 1, захоплюйте пакети у vmnic:

1. SSH до вузла
2. Виконайте наступну команду: (замініть кнопку «vmnicX" з vmnic, який отримав помилку довжини)

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

3. Зафіксуйте помилку пакетів висхідного зв'язку та зупиніться за допомогою комбінації клавіш ctrl+c.
4. Завантажте файл .pcap на локальний робочий стіл і відкрийте його за допомогою Wireshark.
5. Для широкомовних пакетів Фільтр: ip.addr == 255.255.255.255 
6. Для багатоадресних пакетів Фільтр: eth.dst == ff:ff:ff:ff:ff:ff 
7. Спробуйте знайти «Неправильно сформований пакет» у результаті фільтра.
8. Зрідка спрацьовує такий фільтр (тільки на Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Випуск 2:
Сигнал тривоги має назву.

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

Коли користувач перевіряє режим продуктивності vSAN хоста, він може виявити, що vmnic, згаданий у сигналі тривоги, завжди є активним або (і) резервним vmnic трафіку vSAN.
І в більшості випадків vmnic є резервом vSAN.
Ця сигналізація задіяна від vSphere 7.0U2.
Дивіться: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
У наведеній нижче таблиці наведено показники для pSAN, що використовуються для vSAN, які відстежуються, та їхні порогові значення тривоги:

Ці типи помилок можуть впливати на продуктивність vSAN.

Проблема 1:
У цьому випадку захоплення пакетів показує, що контролер точки доступу Cisco (AP) надсилає пакети CAPWAP-Control.
Wireshark позначає їх як неправильно сформований пакет.
ESXi зазвичай також не може впоратися з таким типом пакетів.

Якщо під час аналізу Wireshark стикається з пакетом, який не відповідає очікуваній структурі протоколу, він позначає пакет як «Неправильно сформований». Зазвичай це вказує на те, що пакет міг бути пошкоджений під час передачі, або це являє собою незвичайну або неправильну реалізацію протоколу.

Наступний фільтр може забезпечити інший тип виводу (оскільки довжина кадру не підтримується), а також може спричинити "received length error."
Однак він не є точним, тому перед тим, як відправити звіт замовнику, необхідно провести подальший аналіз на виході цього фільтра.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Випуск 2:
VMware представила цей сигнал для моніторингу помилок, які можуть вплинути на продуктивність vSAN.
Коли відсоток похибки досягає особливого значення. Спрацьовує сигнал тривоги, щоб повідомити користувачеві про те, що слід подбати про працездатність vSAN.

Однак ми помітили, що з алгоритмом спрацьовування сигналізації можуть виникати проблеми. При розрахунку коефіцієнта пакетів помилок використовується число пакетів даних в короткостроковій перспективі і загальна сума пакетів помилок.

Отже, у більшості випадків помилка vmnic завжди є резервним vmnic від vSAN, оскільки трафіку на vmnic менше.

Випуск 1:

• У випадку проблеми 1 IP-адресою джерела був контролер точки доступу Cisco, підключений до VLAN 1.
• Перевірте налаштування vDS кластера VxRail, щоб переконатися, що трафік за допомогою VLAN 1 відсутній.
• Від'єднайте VLAN 1 з портів комутаторів TOR, які підключені до хостів VxRail.
• Якщо його немає у VLAN 1, виконайте ті самі дії, щоб видалити VLAN із портів комутатора.
• Якщо VLAN передає трафік кластера, ми не можемо видалити VLAN з портів комутатора. Користувачеві може знадобитися змінити структуру мережі, щоб ізолювати трафік, який викликав отриману помилку довжини, від кластера VxRail.

Випуск 2:
Існує кілька сценаріїв для вирішення такого типу проблем.

• Помилка звітування про vmnic є резервним vmnic від vSAN, а зростання пакета помилок відбувається повільно.

Це помилкова тривога, викликана алгоритмом і не впливає на продуктивність vSAN. Ми можемо рекомендувати клієнтам ігнорувати цей сигнал, хоча час від часу він з'являється знову.

• Помилка звітування про vmnic – це активний vmnic vSAN або резервний vminc, але пакети помилок продовжують зростати.

Різні типи помилок мають різну роздільну здатність, ми часто стикаємося з сигналізацією, спричиненою помилкою CRC, помилкою отриманої довжини та отриманим кадром паузи.

1. Отримано помилки CRC на vmnic.

   Проблема з обладнанням зазвичай спричиняє помилки CRC. В основному це пов'язано з кабелем, SFP і мережевим адаптером, як на стороні вузла, так і на стороні
   комутатора Дотримуйтесь процесу усунення несправностей обладнання, щоб знайти проблему.

2. Отримані помилки довжини на vmnic.

   Першопричина така ж, як і у Випуску 1. Ви можете слідкувати за виправленням неполадок у випуску 1 для цього сценарію.

3. Пауза Кадр отримана на вмніку.

   Pause Frame використовується для керування мережевим потоком.
   Увімкнути керування потоком Нестабільність або перевантаження мережі сприяє низькій продуктивності VxRail і негативно впливає на операції сховища даних vSAN I-O.
   Контроль потоку – це функція перемикання, яка допомагає керувати швидкістю передачі даних, щоб уникнути переповнення буфера.
   VxRail рекомендує, щоб контроль потоку був "receive on" and "transmit off."
   Дивіться https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf сторінці 88.

Як перевірити, чи включає перемикач регулювання потоку?
Візьмемо для прикладу перемикач 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

Як відключити передачу контролю потоку?

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

Налаштуйте всі інтерфейси перемикачів, підключені до vSAN vmnics, як передавати вимкнено.
Скиньте будильник на зелений і спостерігайте, чи повертається будильник.