O vCenter mostra os avisos "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. A coluna vmnic no aviso pode ser qualquer vmnic que os hosts se conectam à rede.
Isso é diferente do problema 2 (mencionado a seguir). A coluna vmnic no alarme do problema 2 é apenas o ativo e (ou) em espera vmnic de vSAN.

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

Ao executar o seguinte comando no host do ESXi, os usuários veem muitos rx (Receive) Erros de comprimento e o erro continua crescendo. Isso aciona o aviso.
Substitua o 'X' com o devido vmnic Número.

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 vmnics no host tem quase idênticos Receive length error . Isso significa que Multicast packets received ou Broadcast packets received contribui para Receive length errors.

Geralmente, os pacotes de multidifusão são inundados na mesma VLAN, como geralmente são os pacotes de difusão.

Podemos calcular a proporção de erro de comprimento de recepção e pacotes de difusão, ou a proporção de erro de comprimento de recepção e pacotes multicast e, em seguida, compará-los com outros nós.

Mesmo em nós diferentes, a porcentagem de erros de comprimento de recepção 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 o vmnicX com o vmnic que recebeu erro de comprimento)

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

3. Capture os pacotes de uplink de erro e pare com Ctrl+C.
4. Faça download do .pcap para a área de trabalho local e abra-o 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 Malformed Packet do 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.

Quando o usuário verifica a exibição de desempenho do vSAN do host, ele pode descobrir que a vmnic mencionado no alarme é sempre o ativo ou (e) em espera vmnic de tráfego do vSAN.
Na maioria das vezes, o vmnic é o modo de espera do vSAN.
Esse alarme é emitido do 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 seus 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 sua análise, ele marcará o pacote como Malformado. 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 fornecer outro tipo de saída (porque o comprimento do quadro não é compatível) e também pode causar a received length error.
No entanto, ela não é precisa, portanto, antes de enviar o relatório ao cliente, mais análises devem ser feitas sobre a saída desse filtro.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Edição 2:
A VMware introduziu esse alarme para monitorar os erros que podem afetar o desempenho do vSAN.
Um alarme é acionado para mencionar ao usuário que o desempenho do vSAN deve ser resolvido quando a porcentagem de erro atinge o valor especial.

No entanto, observou-se que o algoritmo para disparo de alarmes pode apresentar problemas. Ao calcular a taxa de pacotes de erro, o número de pacotes de dados no curto prazo e a quantidade total de pacotes de erro são usados.

Então, na maioria das vezes, o erro vmnic é sempre o modo de espera vmnic de vSAN, porque há menos tráfego no vmnic.

Problema 1.

• O endereço IP de origem era um controlador de AP da Cisco 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.

• A coluna vmnic O erro de geração de relatórios é o modo de espera vmnic do vSAN e o crescimento do pacote de erros é 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.

• A coluna vmnic O erro de geração de relatórios está ativo vmnic de vSAN ou em standby vminc, mas os pacotes de erro continuam a crescer.

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. Eles estão relacionados principalmente a cabos, SFP e adaptadores de rede, tanto nós quanto comutadores. 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. Pausar quadro recebido no vmnic.
   Pause Frame é usado para controle de fluxo de rede.
   Habilitar o controle de fluxo A instabilidade ou o congestionamento da rede contribuem para o baixo desempenho no VxRail e têm um efeito negativo sobre as operações de armazenamento de dados 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 estouro de buffer.
   O VxRail recomenda que o controle de fluxo seja receive on e 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:Veja
o switch Dell como exemplo:

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

Como desativar a transmissão do controle de fluxo:

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

Configurar todas as interfaces de switch conectadas ao vSAN vmnics Como transmit off.
Redefina o alarme para verde e monitore se ele retorna.