vCenter mostra avvisi "High pnic rx generic error rate detected" o "High pnic error rate detected"

Questo messaggio fa riferimento a due problemi diversi che devono essere trattati in modo diverso.

Problema 1: Il web client vCenter mostra il messaggio seguente per più host. La colonna vmnic nell'avviso può essere qualsiasi vmnic che gli host si connettano alla rete.
Si tratta di un problema diverso dal problema 2 (menzionato di seguito). La colonna vmnic solo nell'allarme del numero 2 è il Attivo e (o) Standby vmnic di vSAN.

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

Quando si esegue il seguente comando sull host ESXi, gli utenti visualizzano molti rx (Receive) errori di lunghezza e l'errore continua a crescere. In questo modo viene attivato l'avviso.
Sostituire il 'X' con il giusto vmnic Numero.

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 

Tutto vmnics nell'host sono quasi identici Receive length error quasi identici. Ciò significa che Multicast packets received oppure Broadcast packets received contribuiscono a Receive length errors.

I pacchetti multicast vengono inondati nella stessa VLAN, come in genere i pacchetti broadcast.

Possiamo calcolare il rapporto tra l'errore di lunghezza di ricezione e i pacchetti di trasmissione, o il rapporto tra l'errore di lunghezza di ricezione e i pacchetti multicast e quindi confrontarli con altri nodi.

Anche su nodi diversi, la percentuale di errori di lunghezza di ricezione causati dal multicast o dalla trasmissione è quasi la stessa.

Per risolvere il problema 1, acquisire i pacchetti in vmnic:

1. Accedere tramite SSH al nodo.
2. Eseguire il comando che segue: (Sostituire il vmnicX con l'opzione vmnic che ha ricevuto l'errore di lunghezza)

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

3. Acquisire i pacchetti di uplink con errori e arrestarli con ctrl+c.
4. Scarica il .pcap file sul desktop locale e aprirlo con Wireshark.
5. Per il filtraggio dei pacchetti broadcast: ip.addr == 255.255.255.255 
6. Per il filtraggio dei pacchetti multicast: eth.dst == ff:ff:ff:ff:ff:ff 
7. Provare a trovare il file Malformed Packet dal risultato del filtro.
8. A volte questo filtro funziona (solo su Wireshark 4.0.12): ((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
L'allarme ha un nome.

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

Quando l'utente controlla la vista delle prestazioni vSAN dell host, può scoprire che l'icona vmnic menzionato nell'allarme è sempre il Attivo o (e) Standby vmnic del traffico vSAN.
Nella maggior parte dei casi, il vmnic è lo standby di vSAN.
Questo allarme è coinvolto da vSphere 7.0U2.
Vedere: https://knowledge.broadcom.com/external/article/312096/alarm-about-high-pnic-error-rate-being-d.html
La tabella seguente mostra le metriche per le pNIC utilizzate per vSAN monitorate e le relative soglie di allarme:

Questi tipi di errori possono influire sulle prestazioni della vSAN.

Problema 1:
In questo caso, l'acquisizione dei pacchetti mostra un controller di un punto di accesso (AP) Cisco che invia pacchetti CAPWAP-Control.
Wireshark li contrassegna come Malformed Packet.
ESXi non è in genere in grado di gestire questo tipo di pacchetti.

Se Wireshark rileva un pacchetto non conforme alla struttura prevista del protocollo durante l'analisi, contrassegna il pacchetto come non valido. In genere, ciò indica che il pacchetto potrebbe essere stato danneggiato durante la trasmissione o che si tratta di un'implementazione insolita o errata di un protocollo.

Il filtro seguente può fornire un altro tipo di output (perché la lunghezza del fotogramma non è supportata) e può anche causare received length error.
Tuttavia, non è accurato, quindi prima di inviare il report al cliente, è necessario eseguire ulteriori analisi sull'output di questo filtro.
((eth.len != frame.len - 14) || eth.len != frame.len - 18)

Problema 2:
VMware ha introdotto questo allarme per monitorare gli errori che possono influire sulle prestazioni di vSAN.
Viene attivato un allarme per segnalare all'utente che le prestazioni di vSAN devono essere gestite quando la percentuale di errore raggiunge il valore speciale.

Tuttavia, è stato osservato che l'algoritmo per l'attivazione degli allarmi può avere problemi. Nel calcolo del rapporto dei pacchetti di errore, vengono utilizzati il numero di pacchetti di dati a breve termine e la quantità totale di pacchetti di errore.

Quindi, nella maggior parte dei casi, l'errore vmnic è sempre in standby vmnic di vSAN, perché c'è meno traffico sul vmnic.

Problema 1:

• L'indirizzo IP di origine era un controller Cisco AP connesso alla VLAN 1.
• Controllare le impostazioni vDS del VxRail Cluster per assicurarsi che non vi sia traffico che utilizza la VLAN 1.
• Rimuovere la VLAN 1 dalle porte degli switch TOR connesse agli host VxRail.
• Se non è presente nella VLAN 1, seguire gli stessi passaggi per rimuovere la VLAN dalle porte dello switch.
• Se la VLAN trasporta il traffico cluster, non è possibile rimuovere la VLAN dalle porte dello switch. L'utente potrebbe dover modificare la progettazione della rete per isolare il traffico che ha causato l'errore di lunghezza di ricezione dal VxRail Cluster.

Problema 2:
Esistono diversi scenari per gestire questo tipo di problema.

• La colonna vmnic La segnalazione dell'errore è in standby vmnic di vSAN e la crescita dei pacchetti di errore è lenta.

Si tratta di un falso allarme causato dall'algoritmo e non influisce sulle prestazioni della vSAN. Si consiglia ai clienti di ignorare questo allarme, anche se riappare di tanto in tanto.

• La colonna vmnic La segnalazione dell'errore è il file attivo vmnic di vSAN o standby vminc, ma i pacchetti di errore continuano a crescere.

I diversi tipi di errori seguono diverse risoluzioni. Spesso riscontriamo l'allarme causato da errore CRC, errore di lunghezza di ricezione e frame in pausa.

1. Ricevuti errori CRC su vmnic.
   Gli errori CRC sono in genere causati da un problema hardware, Si tratta per lo più di cavi, SFP e schede di rete, sia nodi che lato switch. Seguire la procedura di risoluzione dei problemi hardware per individuare il problema.

2. Errori di lunghezza ricevuti su vmnic.
   La root cause è la stessa del Problema 1. Per questo scenario, è possibile seguire la risoluzione dei problemi del Problema 1.

3. Frame di pausa ricevuto sul vmnic.
   Il frame di pausa viene utilizzato per il controllo del flusso di rete.
   Abilitazione del controllo del flusso L'instabilità o la congestione della rete contribuisce a ridurre le prestazioni in VxRail e ha un effetto negativo sulle operazioni del datastore vSAN I-O.
   Il controllo del flusso è una funzione dello switch che consente di gestire la velocità di trasferimento dei dati per evitare il sovraccarico del buffer.
   VxRail consiglia di impostare il controllo del flusso receive on e transmit off.
   Vedere https://www.delltechnologies.com/asset/en-us/products/converged-infrastructure/technical-support/h15300-vxrail-network-guide.pdf a pagina 88.

Come verificare se lo switch attiva il controllo del flusso:
Prendiamo come esempio lo switch Dell:

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

Come disabilitare la trasmissione del controllo del flusso:

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

Configurazione di tutte le interfacce degli switch collegate a vSAN vmnics Come transmit off.
Ripristina l'allarme su verde e monitora se l'allarme ritorna.