vCenter muestra las advertencias "Alta tasa de error genérico de pnic rx detectada" o "Alta tasa de error de pNic detectada"

Hay dos cuestiones distintas para este mensaje que se deben tratar de diferentes maneras.

Problema 1: el cliente web de vCenter muestra el siguiente mensaje para varios hosts. La variable vmnic en la advertencia puede ser cualquier vmnic que los hosts se conecten a la red.
Esto es diferente del problema 2 (que se menciona a continuación). La variable vmnic en la alarma del problema 2 solo es el Activo y (o) en espera vmnic de vSAN.

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

Cuando se ejecuta el siguiente comando en el host ESXi, los usuarios ven una gran cantidad de rx (Receive) length y el error sigue creciendo. Esto activa la advertencia.
Reemplace el 'X' con el adecuado 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 en el anfitrión tienen casi idénticos Receive length error conteos prácticamente idénticos. Esto significa que Multicast packets received o Broadcast packets received contribuye a Receive length errors.

Los paquetes de multidifusión se inundan en la misma VLAN, como suelen estar los paquetes de difusión.

Podemos calcular la relación entre el error de longitud de recepción y los paquetes de difusión, o la relación entre el error de longitud de recepción y los paquetes de multidifusión, y luego compararlos con otros nodos.

Incluso en nodos diferentes, el porcentaje de errores de longitud de recepción causados por la multidifusión o la difusión es casi el mismo.

Para solucionar el problema 1, capture paquetes en vmnic:

1. Acceda mediante SSH al nodo
2. Ejecute el siguiente comando: (Reemplace el vmnicX Con el vmnic que recibió un error de longitud)

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

3. Capture los paquetes de enlace ascendente de error y deténgalos con ctrl+c.
4. Descargue el archivo .pcap en el escritorio local y ábralo con Wireshark.
5. Para filtro de paquetes de difusión: ip.addr == 255.255.255.255 
6. En el caso de filtro de paquetes de multidifusión: eth.dst == ff:ff:ff:ff:ff:ff 
7. Intente encontrar el Malformed Packet del resultado del filtro.
8. Ocasionalmente, este filtro funciona (solo en Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
se nombra la alarma.

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

Cuando el usuario comprueba la vista de rendimiento de vSAN del host, puede descubrir que el vmnic mencionado en la alarma es siempre el activo o (y) en espera vmnic del tráfico de vSAN.
La mayoría de las veces, el vmnic es el servidor en espera de vSAN.
Esta alarma está involucrada desde vSphere 7.0U2.
Consulte: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
En la siguiente tabla, se muestran las métricas de pNIC utilizadas para vSAN que se monitorean y sus umbrales de alarma:

Esos tipos de errores pueden afectar el rendimiento de vSAN.

Problema 1:
en este caso, una captura de paquetes muestra una controladora de punto de acceso (AP) de Cisco que envía paquetes de control CAPWAP.
Wireshark los marca como paquetes con formato incorrecto.
Por lo general, ESXi tampoco puede manejar este tipo de paquete.

Si Wireshark encuentra un paquete que no se ajusta a la estructura esperada del protocolo durante su análisis, marca el paquete como Malformed. Por lo general, esto indica que el paquete puede haberse dañado durante la transmisión o representa una implementación inusual o incorrecta de un protocolo.

El siguiente filtro puede proporcionar otro tipo de salida (ya que la longitud de trama no es compatible) y también puede causar la received length error.
Sin embargo, no es preciso, por lo que antes de enviar el informe al cliente, se deben realizar más análisis sobre el resultado de este filtro.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
VMware presentó esta alarma para monitorear los errores que pueden afectar el rendimiento de vSAN.
Se activa una alarma para mencionar al usuario que el rendimiento de vSAN se debe abordar cuando el porcentaje del error alcanza el valor especial.

Sin embargo, se ha observado que el algoritmo para la activación de alarmas puede tener problemas. Al calcular la tasa de paquetes de error, se utiliza la cantidad de paquetes de datos a corto plazo y la cantidad total de paquetes de error.

Por lo tanto, la mayoría de las veces, el error vmnic es siempre el punto de espera vmnic de vSAN, debido a que hay menos tráfico en el vmnic.

Problema 1:

• La dirección IP de origen era una controladora Cisco AP conectada a VLAN 1.
• Compruebe los ajustes de vDS del clúster de VxRail para asegurarse de que no haya tráfico mediante la VLAN 1.
• Extraiga la VLAN 1 de los puertos de los switches TOR que están conectados a los hosts de VxRail.
• Si no está en la VLAN 1, siga los mismos pasos para extraer la VLAN de los puertos del switch.
• Si la VLAN transporta el tráfico del clúster, no podemos extraer la VLAN de los puertos del switch. Es posible que el usuario deba cambiar el diseño de red para aislar el tráfico que causó el error de longitud recibida del clúster de VxRail.

Problema 2:
hay varias opciones para manejar este tipo de problema.

• La variable vmnic El error de generación de informes es el estado en espera vmnic de vSAN y el crecimiento del paquete de error es lento.

Esta es una falsa alarma causada por el algoritmo y no afecta el rendimiento de vSAN. Podemos recomendar a los clientes que ignoren esta alarma, aunque esta alarma vuelve a aparecer de vez en cuando.

• La variable vmnic El error de informe es el activo vmnic de vSAN o en espera vminc, pero los paquetes de error continúan creciendo.

Los diferentes tipos de errores siguen diferentes resoluciones; a menudo, nos encontramos con la advertencia causada por el error de CRC, el error de longitud recibida y el marco de pausa recibido.

1. Se recibieron errores de CRC en el vmnic.
   Por lo general, un problema de hardware provoca errores de CRC. Estos se relacionan principalmente con cables, SFP y adaptadores de red, tanto de nodos como de lados de switch. Siga el proceso de solución de problemas de hardware para localizar el problema.

2. Errores de longitud recibidos en el vmnic.
   La causa de origen es la misma que la del problema 1. Puede seguir la solución de problemas del problema 1 para este caso.

3. Trama de pausa recibida en el vmnic.
   El marco de pausa se utiliza para el control de flujo de red.
   Habilitar el control de flujo La inestabilidad o la congestión de la red contribuyen al bajo rendimiento en VxRail y tienen un efecto negativo en las operaciones del almacén de datos de I-O de vSAN.
   El control de flujo es una función del switch que ayuda a administrar la velocidad de transferencia de datos para evitar la saturación del búfer.
   VxRail recomienda que el control de flujo sea receive on y transmit off.
   Consulte https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf, página 88.

Cómo comprobar si el switch habilita el control de flujo:
Tome el switch Dell como ejemplo:

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

Cómo deshabilitar la transmisión del control de flujo:

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 las interfaces de switch conectadas a vSAN vmnics Como transmit off.
Restablezca la alarma a verde y controle si la alarma vuelve.