VxRail: vCenter отображает предупреждение «High pnic rx generic error rate detected» или «High pNic error rate detected»

В этом сообщении указаны две различные проблемы, требующие отдельного подхода к решению.

Проблема 1.
Веб-клиент vCenter отображает следующее сообщение для нескольких хостов. В предупреждении может быть указан любой vmnic, по которому хосты подключены к сети.
** Это отличается от Проблемы 2 (упомянутой ниже). vmnic в оповещении о Проблеме 2 — это активный и/или резервный виртуальный сетевой адаптер vSAN.**

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

При выполнении следующей команды на хосте ESXi пользователи видят множество ошибок длины rx (прием), и их число продолжает расти. Это приведет к появлению предупреждения.
(замените «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 

У всех vmnic на хосте почти одинаковые "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. Попробуйте найти «Malformed Packet» в результатах фильтрации.
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, упомянутый в оповещении, всегда является активным и/или резервным виртуальным сетевым адаптером трафика vSAN.
В большинстве случаев vmnic в сети vSAN является резервным.
Это оповещение появилось в vSphere 7.0U2.
См.: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
В следующей таблице приведены отслеживаемые метрики для pNIC, используемых для vSAN, и их пороговые значения оповещений:

Эти типы ошибок могут повлиять на производительность vSAN.

Проблема 1.
В этом случае при сборе пакетов контроллер Cisco Access Point (AP) отправляет пакеты CAPWAP-Control.
Wireshark помечает их как «Malformed Packet».
Как правило, ESXi также не может обработать этот тип пакета.

Если во время анализа Wireshark обнаруживает пакет, который не соответствует ожидаемой структуре протокола, он помечает пакет как «Malformed». Обычно это указывает на то, что пакет мог быть поврежден во время передачи или что он представляет собой необычную или неправильную реализацию протокола.

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

Вопрос 2.
Компания VMware представила это оповещение для мониторинга ошибок, которые могут повлиять на производительность vSAN.
Когда процент ошибки достигает специального значения. Оповещение появляется, чтобы указать пользователю на необходимость позаботиться о производительности vSAN.

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

В большинстве случаев ошибочный vmnic всегда является резервным vmnic vSAN, поскольку на нем меньше трафика.

Проблема 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. Мы можем рекомендовать заказчикам игнорировать это оповещение, хотя оно периодически появляется.

• vminc, сообщающий об ошибке, является активным vmnic vSAN или резервным vminc, однако пакеты ошибок продолжают расти.

Различные типы ошибок имеют разное решение, мы часто сталкиваемся с оповещениями, вызванными ошибкой CRC, ошибкой длины и кадра паузы.

1. Получены ошибки CRC на vmnic.

   Проблема с оборудованием обычно приводит к ошибкам CRC. В основном это связано с кабелями, SFP и сетевыми адаптерами, как на стороне узла, так и на стороне коммутатора
   Для обнаружения проблемы следуйте инструкциям по поиску и устранению неисправностей оборудования.

2. Получены ошибки длины на vmnic.

   Основная причина та же, что и у Проблемы 1. Вы можете выполнить инструкции по поиску и устранению Проблемы 1, описанные для этого сценария.

3. На vmnic получен кадр паузы.

   Кадр паузы применяется для управления сетевым потоком.
   Включить контроль потока. Нестабильность или перегрузка сети приводит к низкой производительности VxRail и негативно влияет на работу хранилища данных ввода-вывода vSAN.
   Управление потоком — это функция коммутатора, помогающая управлять скоростью передачи данных во избежание переполнения буфера.
   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), на режим «transmit off».
Сбросьте сигнал оповещения на зеленый и следите за тем, появится ли он снова.