VxRail: vCenter visualizza l'avvertenza"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 vmnic indicata nell'avvertenza può essere qualsiasi vmnic che gli host connettono alla rete.
**Non è così nel problema 2 (riportato più avanti). La vmnic nell'allarme del problema 2 è solo la vmnic attiva e (o) di standby della vSAN.**

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

Quando si utilizza il seguente comando sull'host ESXi, gli utenti visualizzano numerosi errori di lunghezza di ricezione (rx) e l'errore continua a crescere. Di conseguenza si attiva l'avvertenza.
Sostituire la "X" con il numero corretto della 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 

Tutte le vmnic nell'host presentano conteggi "Receive length error" quasi identici. Ciò significa che "Multicast packets received" oppure "Broadcast packets received" contribuiscono a "Receive length errors."

**I pacchetti multicast *sono diretti alla stessa VLAN, come lo sono in genere i pacchetti broadcast.

Possiamo calcolare il rapporto tra l'errore di lunghezza di ricezione e i pacchetti broadcast 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 errore di lunghezza di ricezione causato dal multicast o dal broadcast è quasi la stessa.**

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

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

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

3. Acquisire i pacchetti di uplink in errore e arrestare con Ctrl+C.
4. Scaricare il file .pcap 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 "Malformed Packet" nel risultato del filtraggio.
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ò rilevare che la vmnic menzionata nell'allarme è sempre la vmnic attiva o (e) di standby del traffico vSAN.
Nella maggior parte dei casi, la vmnic è la vmnic di standby della vSAN.
Questo allarme è relativo a 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 monitorate per le pNIC utilizzate per la vSAN 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 riscontra un pacchetto non conforme alla struttura del protocollo prevista durante l'analisi, lo contrassegna come "Malformed". 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 seguente filtro può fornire un altro tipo di output (in quanto la lunghezza del frame non è supportata) e può anche causare l'errore "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 potrebbero influire sulle prestazioni della vSAN.
Quando la percentuale dell'errore raggiunge il valore speciale, viene attivato un allarme per segnalare all'utente che le prestazioni della vSAN devono essere controllate.

Tuttavia, abbiamo osservato che l'algoritmo per l'attivazione dell'allarme potrebbe avere problemi. Quando si calcola il rapporto dei pacchetti in errore, vengono utilizzati il numero di pacchetti di dati a breve termine e la quantità totale di pacchetti in errore.

Pertanto, nella maggior parte dei casi, la vmnic in errore è sempre la vmnic di standby della vSAN, perché il traffico su tale vmnic è minore.

Problema 1:

• Nel caso del problema 1, l'indirizzo IP di origine era un controller AP Cisco 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 vmnic che riporta l'errore è la vmnic di standby della vSAN e la crescita del pacchetto in 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 vmnic che riporta l'errore è la vmnic attiva della vSAN o la vmnic di standby, ma i pacchetti in 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. Errori CRC sulla vmnic

   Gli errori CRC sono in genere causati da un problema hardware, spesso correlato al cavo, all'SFP e alla scheda di rete, sia sul lato del nodo che su quello dello switch
   . Seguire la procedura di risoluzione dei problemi hardware per individuare il problema.

2. Errori di lunghezza sulla vmnic

   La root cause è la stessa del Problema 1. Per questo scenario, è possibile seguire la risoluzione dei problemi del Problema 1.

3. Frame in pausa sulla vmnic

   Il frame in pausa viene utilizzato per il controllo del flusso di rete.
   Abilitare il controllo del flusso. L'instabilità o la congestione della rete contribuisce a ridurre le prestazioni in VxRail e ha un effetto negativo sulle operazioni dell'archivio dati di I/O della vSAN.
   Il controllo del flusso è una funzione degli switch che consente di gestire la velocità di trasferimento dei dati per evitare il sovraccarico del buffer.
   VxRail consiglia il flusso sia "receive on" and "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 interruttore consente il controllo del flusso?
Prendiamo ad esempio lo 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

Come si disattiva la trasmissione di controllo del flusso?

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

Configurare tutte le interfacce dello switch connesse alle vmnic della vSAN come "transmit off".
Ripristinare l'allarme su verde e controllare se l'allarme si ripresenta.