VxRail: o vCenter exibe a advertência "High pnic rx generic error rate detected" ou "High pNic error rate detected"

Essas mensagens estão relacionadas a dois problemas diferentes, que devem ser tratados de forma distinta.

Problema 1:
O vCenter Web Client mostra a mensagem abaixo para vários hosts. O vmnic na advertência pode ser qualquer vmnic que os hosts conectam à rede.
**Ele é diferente do relacionado ao Problema 2 (que será mencionado a seguir). O vmnic no alarme do Problema 2 é apenas o vmnic ativo e/ou em espera do vSAN.**

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

Ao executar o comando a seguir no host do ESXi, muitos erros de comprimento de rx (recebimento) são exibidos e continuam a aumentar. Esses erros acionam a advertência.
(substitua o "X" pelo número correto do 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 

Todos os vmnics no host têm praticamente o mesmo número de "Receive length error" . Isso significa que "Multicast packets received" ou "Broadcast packets received" contribui para "Receive length errors."

**Os pacotes multicast são inundados na mesma VLAN, assim como os pacotes de transmissão normalmente são.

Podemos calcular a proporção de erros de comprimento de recebimento e pacotes de transmissão ou a proporção de erros de comprimento de recebimento e pacotes multicast. Em seguida, faça a comparação com outros nós.

Mesmo em nós diferentes, a porcentagem de erros de comprimento de recebimento causados por multicast ou transmissão é quase a mesma.**

Para solucionar o Problema 1, capture pacotes no vmnic:

1. Abra uma sessão SSH no nó
2. Execute o comando abaixo: (substitua "vmnicX" pelo vmnic que recebeu o erro de comprimento)

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

3. Capture os pacotes de uplink com erro e faça a interrupção com ctrl+c.
4. Faça download do arquivo .pcap na área de trabalho local e abra o arquivo com o Wireshark.
5. Nos pacotes de transmissão, filtre por: ip.addr == 255.255.255.255 
6. Nos pacotes multicast, filtre por: eth.dst == ff:ff:ff:ff:ff:ff 
7. Tente encontrar o pacote "Malformed" no resultado do filtro.
8. Ocasionalmente, esse filtro funciona (apenas no Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
O alarme é denominado.

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

Ao verificar a exibição de desempenho do vSAN do host, o usuário descobre que o vmnic mencionado no alarme é sempre o vmnic ativo e/ou em espera do tráfego do vSAN.
Na maioria das vezes, é o vmnic em espera do vSAN.
Esse alarme está associado ao vSphere 7.0U2.
Consulte: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
A tabela a seguir mostra as métricas de pNICs usadas para vSAN que são monitoradas e os respectivos limites de alarme:

Esses tipos de erros podem afetar o desempenho do vSAN.

Problema 1:
Neste caso, uma captura de pacote mostra um controlador Cisco Access Point (AP) enviando pacotes CAPWAP-Control.
O Wireshark marca esses pacotes como "Malformed".
Geralmente, o ESXi também não consegue lidar com esse tipo de pacote.

Se o Wireshark encontrar um pacote que não esteja em conformidade com a estrutura esperada do protocolo durante a análise, ele marcará o pacote como "Malformed". Esse status normalmente indica que o pacote pode ter sido corrompido durante a transmissão ou representa uma implementação incomum ou incorreta de um protocolo.

O filtro a seguir pode apresentar outro tipo de saída (porque o comprimento do quadro não é compatível) e também pode causar o erro "received length error."
No entanto, ele não é preciso. Dessa forma, antes de enviar o relatório para o cliente, uma análise adicional deve ser feita na saída desse filtro.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
A VMware introduziu esse alarme para monitorar os erros que podem afetar o desempenho do vSAN.
Quando a porcentagem de erro atinge o valor especial. Um alarme é disparado para informar ao usuário que é necessário cuidar do desempenho do vSAN.

No entanto, observamos que o algoritmo para disparo do alarme pode apresentar problemas. Ao calcular a taxa de pacotes com erro, o número de pacotes de dados em curto prazo e a quantidade total de pacotes com erro são usados.

Na maioria das vezes, o vmnic com erro é o vmnic em espera do vSAN, pois há menos tráfego no vmnic.

Problema 1.

• No caso do Problema 1, o endereço IP de origem era um controlador Cisco AP conectado à VLAN 1.
• Verifique as configurações do vDS do VxRail Cluster para garantir que não haja tráfego usando a VLAN 1.
• Remova a VLAN 1 das portas dos switches TOR conectadas aos hosts do VxRail.
• Se elas não estiverem na VLAN 1, siga as mesmas etapas para remover a VLAN das portas do switch.
• Se a VLAN transportar o tráfego do cluster, não será possível removê-la das portas do switch. Talvez o usuário precise alterar o design da rede para isolar o tráfego que causou o erro de comprimento no VxRail Cluster.

Problema 2:
Há vários cenários para lidar com esse tipo de problema.

• O vmnic com erro é o vmnic em espera do vSAN, e o aumento de pacotes com erro é lento.

Esse é um alarme falso causado pelo algoritmo e não afeta o desempenho do vSAN. Podemos recomendar que os clientes ignorem esse alarme, apesar de ele reaparecer de tempos em tempos.

• O vmnic com erro é o vmnic ativo ou em espera do vSAN, mas os pacotes com erro continuam a aumentar.

Os diferentes tipos de erros seguem resoluções distintas. Muitas vezes, o alarme é causado por erro de CRC, erro de comprimento e erros de quadro de pausa.

1. Erros de CRC recebidos no vmnic.

   Um problema de hardware geralmente causa erros de CRC. Na maioria das vezes, eles estão relacionados a cabo, SFP e adaptador de rede, tanto no nó quanto no switch.
   Siga o processo de solução de problemas de hardware para localizar o problema.

2. Erros de comprimento recebidos no vmnic.

   A causa raiz é a mesma do Problema 1. Você pode seguir a solução de problemas do Problema 1 para esse cenário.

3. Erro de quadro de pausa recebido no vmnic.

   O quadro de pausa é usado para controle de fluxo de rede.
   Habilitar a instabilidade ou o congestionamento de rede do controle de fluxo contribui para o baixo desempenho no VxRail e tem um efeito negativo nas operações do datastore de E/S do vSAN.
   O controle de fluxo é um recurso de switch que ajuda a gerenciar a taxa de transferência de dados para evitar o estouro de buffer.
   O VxRail recomenda que o controle de fluxo seja "receive on" and "transmit off."
   Consulte https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf, página 88.

Como verificar se o switch habilita o controle de fluxo?
vamos usar como exemplo o switch 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

Como desabilitar a transmissão do controle de fluxo?

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

Configure todas as interfaces de switch conectadas aos vmnics do vSAN como "transmit off".
Redefina o alarme para verde e monitore se ele retorna.