Solucione problemas de quedas de pacotes com contadores de interface na plataforma Nexus
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:
- Plataforma NXOS
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" |
N9K2# sh int e1/1 cou detailed | i i " 1024 to 1518" |
N9K3# sh int e1/1 cou detailed | i i " 1024 to 1518" |
| 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" |
N9K2# sh int e1/1 cou detailed | i i " 1024 to 1518" |
N9K3# sh int e1/1 cou detailed | i i " 1024 to 1518" |
| 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.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
26-Mar-2025
|
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)