VxRail: vCenter muestra la advertencia "Se detectó una tasa alta de error genérico de pnic rx" o "Se detectó una tasa alta de error de pNic"

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. El vmnic en la advertencia puede ser cualquier vmnic que los hosts conecten a la red.
** Esto es diferente al problema 2 (que se menciona a continuación). El vmnic en la alarma del problema 2 solamente es el vmnic activo o en espera 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 errores de longitud de rx (recepción) y el error continúa creciendo. Esto activa la advertencia.
(reemplace la "X" con el número de vmnic correcto)

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 los vmnics del host tienen "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, al igual que los paquetes de difusión en general.

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. Luego, los comparamos con otros nodos.

Incluso en nodos diferentes, el porcentaje de error de longitud de recepción causado 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 "paquete malformado" en el 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 siempre es el vmnic activo o (y) en espera del tráfico de vSAN.
Además, la mayoría de las veces, el vmnic es el respaldo del 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 el siguiente cuadro, 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 "Malformado". 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 debe realizar un análisis más detallado de la salida 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.
Cuando el porcentaje del error alcanza el valor especial. Se activa una alarma para avisarle al usuario que debe cuidar el rendimiento de vSAN.

Sin embargo, observamos que el algoritmo para la activación de alarmas puede tener problemas. Cuando se calcula 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 vmnic de error siempre es el vmnic en espera de vSAN, porque hay menos tráfico en el vmnic.

Problema 1:

• En el caso del 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.

• El error de generación de informes de vmnic es el vmnic en espera 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.

• El error de generación de informes de vmnic es el vmnic activo de vSAN o vmnic en espera, 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. Se relaciona principalmente con el cable, el SFP y el adaptador de red, tanto del lado del nodo como del switch
   Siga el proceso de solución de problemas de hardware para localizar el problema.

2. Se recibieron errores de longitud 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. Marco de pausa recibido en el vmnic.

   El marco de pausa se utiliza para el control de flujo de red.
   Habilitar el control de flujo de inestabilidad o congestión contribuye 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" and "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 interruptor habilita el control de flujo?
Tomemos como ejemplo el switch de 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

¿Cómo deshabilitar la transmisión del control de flujo?

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 las interfaces de switch conectadas a vmnics de vSAN como transmisión apagada.
Restablezca la alarma a verde y controle si la alarma vuelve.