Introdução
Este documento descreve como solucionar problemas de perda de pacotes usando contadores de interface do Nexus.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
Componentes Utilizados
Nome |
Plataforma |
Versão |
N9K1 |
N9K-C93108TC-EX |
9.3(10) |
N9K2 |
N9K-C93108TC-EX |
9.3(10) |
N9K3 |
N9K-C93108TC-EX |
9.3(10) |
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Topologia

Background
Em certos ambientes, os métodos tradicionais de captura de pacotes, como ELAM ou SPAN, não podem ser opções viáveis para diagnosticar problemas de rede. No entanto, os contadores de pacotes da interface do Nexus fornecem uma alternativa valiosa para a solução de problemas de quedas de pacotes. É importante observar que a disponibilidade de contadores específicos pode variar dependendo da configuração de rede, portanto, esse método de solução de problemas não pode ser universalmente aplicável.
Neste exemplo, é demonstrado como utilizar os contadores de interface do Nexus para solucionar problemas de conectividade entre as interfaces de loopback de N9K1 ( 172.16.1.1 ) e N9K3 ( 172.16.1.2 ).
Identificando interfaces
Para cada dispositivo, a interface de entrada e saída deve ser identificada, a fim de identificar essas interfaces para este exemplo de comando: show ip route é utilizado.
Rotas em 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
Para o nexus N9K1, a interface Eth1/1 é usada.
Rotas em 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
Para o nexus N9K1, as interfaces Eth1/1 e Eth1/2 são usadas.
Rotas em 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
Para o nexus N9K1, a interface Eth1/1 é usada.
Identificando o tamanho do pacote
Para solucionar problemas de quedas de pacotes usando contadores de interface, é necessário identificar um contador que não esteja aumentando.
No próximo exemplo, o comando sh interface e1/1 counter detailed foi executado duas vezes, onde pode ser observado que o contador Packets de 512 a 1023 bytes não aumentou para RX e TX.
Esse processo precisa ser feito em todos os dispositivos envolvidos entre a origem e o destino.
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
Caution: Em um ambiente de produção, os contadores de interfaces podem ser apagados para identificar qual contador não está aumentando. Para interfaces com MTU definido como o máximo, podem ser encontrados contadores maiores que 1518. Se pacotes com tamanho específico não cruzarem o nexo, um contador não aparecerá.
Realização do ensaio
Para esse teste, como um ambiente controlado é usado, o contador Pacotes de 1024 a 1518 é usado em todos os dispositivos. Os contadores de todas as interfaces são limpos antes do teste:
N9K1# clear counters interface e1/1
N9K2# clear counters interface e1/1-2
N9K3# clear counters interface e1/1
Em todos os nexus, o próximo comando pode ser executado para verificar se nenhum tráfego com o tamanho de pacote desejado está passando pelo nexus; a expectativa é não ver nada;
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"
Agora que todos os contadores estão limpos, um ping pode ser gerado , especificando um tamanho de pacote entre 1024-1518 com DF-BIT definido.
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
Verificar solicitação ICMP
No próximo exemplo, você pode observar como os contadores estão aumentando na direção TX/RX nos dispositivos envolvidos para a solicitação ICMP de N9K1 para 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
|
Pode-se observar que o N9K1 enviou 5 pacotes na interface e1/1 |
Pode-se observar que o N9K2 recebeu 5 pacotes na interface e1/1 e enviou 5 pacotes na interface e1/2 |
Pode-se observar que o N9K3 recebeu 5 pacotes na interface e1/1 |
Verificar resposta do ICMP
Depois que o patch de solicitação ICMP for validado, você poderá prosseguir para revisar a resposta ICMP.
No próximo exemplo, você pode observar como os contadores estão aumentando na direção TX/RX nos dispositivos envolvidos para a resposta ICMP de N9K3 para 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
|
Pode-se observar que o N9K1 recebe 5 pacotes na interface e1/1 |
Pode-se observar que o N9K2 enviou 5 pacotes na interface e1/1 e recebeu 5 pacotes na interface e1/2 |
Pode-se observar que o N9K3 enviou 5 pacotes na interface e1/1 |
Com esse teste, pode-se confirmar que o tráfego fluiu corretamente pelos 3 switches. Se um dos nexus tiver uma discrepância no contador, RX ou TX é onde o tráfego pode ser descartado.