Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Topologia

Introduzione

Identificazione delle interfacce

Route in N9K1

Route in N9K2

Route in N9K3

Identificazione delle dimensioni del pacchetto

Esecuzione del test

Verifica richiesta ICMP

Verifica risposta ICMP

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

Nome

Piattaforma

Version

N9K1

N9K-C93108TC-EX

9.3(10)

N9K2

N9K-C93108TC-EX

9.3(10)

N9K3

N9K-C93108TC-EX

9.3(10)

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

N9K2

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

Si può notare che N9K1 ha inviato 5 pacchetti sull'interfaccia e1/1

Si può osservare che N9K2 ha ricevuto 5 pacchetti sull'interfaccia e1/1 e ha inviato 5 pacchetti sull'interfaccia e1/2

Si può osservare che N9K3 ha ricevuto 5 pacchetti sull'interfaccia e1/1

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

N9K2

N9K3

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

Si può notare che N9K1 riceve 5 pacchetti sull'interfaccia e1/1

Si può osservare che N9K2 ha inviato 5 pacchetti sull'interfaccia e1/1 e ha ricevuto 5 pacchetti sull'interfaccia e1/2

Si può osservare che N9K3 ha inviato 5 pacchetti sull'interfaccia e1/1

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.