Risoluzione dei problemi di perdita di pacchetti con i contatori di interfaccia sulla piattaforma Nexus

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alla perdita di pacchetti utilizzando i contatori dell'interfaccia Nexus.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Piattaforma NXOS

Componenti usati

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Topologia

Introduzione

In alcuni ambienti, i metodi tradizionali di acquisizione dei pacchetti come ELAM o SPAN non possono essere opzioni fattibili per la diagnosi dei problemi di rete. Tuttavia, i contatori dei pacchetti dell'interfaccia Nexus rappresentano una valida alternativa per la risoluzione dei problemi di perdita dei pacchetti.  È importante notare che la disponibilità di contatori specifici può variare a seconda della configurazione di rete, pertanto questo metodo di risoluzione dei problemi non può essere universalmente applicabile.

Nell'esempio viene mostrato come utilizzare i contatori dell'interfaccia Nexus per risolvere i problemi di connettività tra le interfacce di loopback di N9K1 ( 172.16.1.1 ) e N9K3 ( 172.16.1.2 ). 

Identificazione delle interfacce

Per ciascun dispositivo, è necessario identificare l'interfaccia in entrata e in uscita, al fine di identificare queste interfacce per questo comando di esempio: viene usato show ip route.

Route in N9K1

N9K1# sh ip route 172.16.1.2
<Snipped>
172.16.1.2/32, ubest/mbest: 1/0
   *via 192.168.2.1, Eth1/1, [1/0], static

Per nexus N9K1 viene utilizzata l'interfaccia Eth1/1.

Route in N9K2

N9K2# sh ip route 172.16.1.1
<Snipped>
172.16.1.1/32, ubest/mbest: 1/0 time
   *via 192.168.2.2, Eth1/1, [1/0], static

N9K2# sh ip route 172.16.1.2
<Snipped>
172.16.1.2/32, ubest/mbest: 1/0 time
   *via 192.168.1.2, Eth1/2, [1/0], static

Per nexus N9K1, vengono utilizzate le interfacce Eth1/1 e Eth1/2.

Route in N9K3

N9K3# sh ip route 172.16.1.1
<Snipped>
172.16.1.1/32, ubest/mbest: 1/0 time
   *via 192.168.1.1, Eth1/1, [1/0], static

Per nexus N9K1 viene utilizzata l'interfaccia Eth1/1.

Identificazione delle dimensioni del pacchetto 

Per risolvere i problemi di perdita dei pacchetti tramite i contatori di interfaccia, è necessario identificare un contatore che non sta aumentando.

Nell'esempio successivo, il comando sh interface e1/1 counter detail è stato eseguito due volte, nel caso in cui si possa notare che il numero di pacchetti da 512 a 1023 byte non è aumentato per RX e TX.

Questo processo deve essere eseguito su tutti i dispositivi interessati tra l'origine e la destinazione. 

N9K1# sh interface e1/1 counters detailed
Ethernet1/1
 Rx Packets: 31774
 Rx Unicast Packets: 8419
 Rx Multicast Packets: 23784
 Rx Broadcast Packets: 3
 Rx Bytes: 8115383
 Rx Packets from 0 to 64 bytes: 322
 Rx Packets from 65 to 127 bytes: 22822
 Rx Packets from 128 to 255 bytes: 3393
 Rx Packets from 256 to 511 bytes: 1652
 Rx Packets from 512 to 1023 bytes: 63
 Rx Packets from 1024 to 1518 bytes: 3522
 Tx Packets: 26430
 Tx Unicast Packets: 7351
 Tx Multicast Packets: 19509
 Tx Broadcast Packets: 2
 Tx Bytes: 5114894
 Tx Packets from 0 to 64 bytes: 90
 Tx Packets from 65 to 127 bytes: 20724
 Tx Packets from 128 to 255 bytes: 2243
 Tx Packets from 256 to 511 bytes: 1642
 Tx Packets from 512 to 1023 bytes: 10
 Tx Packets from 1024 to 1518 bytes: 1766

N9K1# sh interface e1/1 counters detailed
Ethernet1/1
 Rx Packets: 31821
 Rx Unicast Packets: 8437
 Rx Multicast Packets: 23817
 Rx Broadcast Packets: 3
 Rx Bytes: 8125733
 Rx Packets from 0 to 64 bytes: 329
 Rx Packets from 65 to 127 bytes: 22878
 Rx Packets from 128 to 255 bytes: 3468
 Rx Packets from 256 to 511 bytes: 1670
 Rx Packets from 512 to 1023 bytes: 63
 Rx Packets from 1024 to 1518 bytes: 3544
 Tx Packets: 26467
 Tx Unicast Packets: 7367
 Tx Multicast Packets: 19534
 Tx Broadcast Packets: 2
 Tx Bytes: 5121572
 Tx Packets from 0 to 64 bytes: 95
 Tx Packets from 65 to 127 bytes: 20768
 Tx Packets from 128 to 255 bytes: 2290
 Tx Packets from 256 to 511 bytes: 1657
 Tx Packets from 512 to 1023 bytes: 10
 Tx Packets from 1024 to 1518 bytes: 1798 

Attenzione: In un ambiente di produzione, i contatori delle interfacce possono essere azzerati per identificare il contatore che non aumenta. Per le interfacce con MTU impostata sul valore massimo, è possibile trovare contatori maggiori di 1518. Se i pacchetti di dimensioni specifiche non attraversano il nexus, non verrà visualizzato alcun contatore.

Esecuzione del test

Poiché si utilizza un ambiente controllato, per questo test vengono usati pacchetti contatori da 1024 a 1518 in tutte le periferiche. I contatori di tutte le interfacce vengono azzerati prima del test:

N9K1# clear counters interface e1/1
N9K2# clear counters interface e1/1-2
N9K3# clear counters interface e1/1

In all nexus, è possibile eseguire il comando successivo per verificare che nessun traffico con le dimensioni di pacchetto desiderate stia passando attraverso il nexus; l'aspettativa è di non vedere nulla;

N9K1# sh int e1/1 cou detailed | i i " 1024 to 1518"
N9K2# sh int e1/1-2 cou detailed | i i " 1024 to 1518"
N9K3# sh int e1/1 cou detailed | i i " 1024 to 1518" 

Dopo aver azzerato tutti i contatori, è possibile generare un ping e specificare le dimensioni del pacchetto tra 1024-1518 con DF-BIT impostato.

N9K1# ping 172.16.1.2 source 172.16.1.1  packet-size 1050 df-bit 
PING 172.16.1.2(172.16.1.2) from 172.16.1.1: 1050 data bytes
1058 bytes from 172.16.1.2: icmp_seq=0 ttl=254 time=1.102 ms
1058 bytes from 172.16.1.2: icmp_seq=1 ttl=254 time=0.668 ms
1058 bytes from 172.16.1.2: icmp_seq=2 ttl=254 time=0.644 ms
1058 bytes from 172.16.1.2: icmp_seq=3 ttl=254 time=0.626 ms
1058 bytes from 172.16.1.2: icmp_seq=4 ttl=254 time=0.631 ms

--- 172.16.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.626/0.734/1.102 ms  

Verifica richiesta ICMP

Nell'esempio seguente, è possibile osservare l'aumento dei contatori in direzione TX/RX sui dispositivi interessati dalla richiesta ICMP da N9K1 a N9K3.

N9K1# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 0
  Tx Packets from 1024 to 1518 bytes: 5

N9K2# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5
  Tx Packets from 1024 to 1518 bytes: 0
N9K2# sh int e1/2 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 0
  Tx Packets from 1024 to 1518 bytes: 5

N9K3# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5
  Tx Packets from 1024 to 1518 bytes: 0

Verifica risposta ICMP

Dopo aver convalidato la patch della richiesta ICMP, è possibile procedere alla revisione della risposta ICMP.

Nell'esempio seguente viene mostrato come i contatori aumentano in direzione TX/RX sui dispositivi interessati per la risposta ICMP da N9K3 a N9K1

N9K1# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5
  Tx Packets from 1024 to 1518 bytes: 5

N9K2# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5
  Tx Packets from 1024 to 1518 bytes: 5
N9K2# sh int e1/2 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5
  Tx Packets from 1024 to 1518 bytes: 5

N9K3# sh int e1/1 cou detailed | i i " 1024 to 1518"
  Rx Packets from 1024 to 1518 bytes: 5

  Tx Packets from 1024 to 1518 bytes: 5

Con questo test, è possibile verificare che il traffico abbia fluito correttamente sui 3 switch. Se uno dei nexus presenta una discrepanza sul contatore, è RX o TX che è dove il traffico può essere scartato.