Resolución de problemas de paquetes descartados con contadores de interfaz en la plataforma Nexus

Introducción

Este documento describe cómo resolver problemas de pérdida de paquetes mediante los contadores de interfaz de Nexus.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Plataforma NXOS

Componentes Utilizados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Topología

Background

En ciertos entornos, los métodos de captura de paquetes tradicionales como ELAM o SPAN no pueden ser opciones viables para diagnosticar problemas de red. Sin embargo, los contadores de paquetes de la interfaz Nexus proporcionan una alternativa valiosa para solucionar problemas de caídas de paquetes.  Es importante tener en cuenta que la disponibilidad de contadores específicos puede variar en función de la configuración de la red, por lo que este método de solución de problemas no puede aplicarse universalmente.

En este ejemplo, se muestra cómo utilizar los contadores de la interfaz Nexus para resolver problemas de conectividad entre las interfaces de loopback de N9K1 ( 172.16.1.1 ) y N9K3 ( 172.16.1.2 ). 

Identificación de interfaces

Para cada dispositivo se debe identificar la interfaz de ingreso y egreso, para identificar estas interfaces para este comando de ejemplo: show ip route is used.

Rutas en 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 el nexus N9K1, se utiliza la interfaz Eth1/1.

Rutas en 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 el nexus N9K1, se utilizan las interfaces Eth1/1 y Eth1/2.

Rutas en 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 el nexus N9K1, se utiliza la interfaz Eth1/1.

Identificación del tamaño del paquete 

Para resolver problemas de caídas de paquetes mediante contadores de interfaz, es necesario identificar un contador que no está aumentando.

En el siguiente ejemplo, el comando sh interface e1/1 counter detailed se ejecutó dos veces, donde se puede observar que los paquetes de contador de 512 a 1023 bytes no aumentaron para RX y TX.

Este proceso debe realizarse en todos los dispositivos involucrados entre el origen y el 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 

Precaución: En un entorno de producción, los contadores de interfaces se pueden borrar para identificar qué contador no está aumentando. Para las interfaces que tienen la MTU establecida en el máximo, se pueden encontrar contadores mayores que 1518. Si los paquetes con un tamaño específico no cruzan el nexus, no aparecerá ningún contador.

Realización de la prueba

Para esta prueba, debido a que se utiliza un entorno controlado, se utilizan los paquetes de contador de 1024 a 1518 en todos los dispositivos. Los contadores de todas las interfaces se borran antes de la prueba:

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

En todos los nexus, se puede ejecutar el siguiente comando para verificar que ningún tráfico con el tamaño de paquete deseado esté pasando a través del nexus; la expectativa es no 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" 

Ahora que todos los contadores están despejados, se puede generar un ping , especificando un tamaño de paquete entre 1024-1518 con DF-BIT configurado.

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 solicitud ICMP

En el siguiente ejemplo, puede observar cómo los contadores aumentan en la dirección TX/RX en los dispositivos involucrados para la solicitud ICMP de 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

Verificar respuesta ICMP

Una vez validado el parche de solicitud de ICMP, puede continuar con la revisión de la respuesta de ICMP.

En el siguiente ejemplo puede observar cómo los contadores aumentan en la dirección TX/RX en los dispositivos involucrados para la respuesta ICMP de 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 esta prueba, se puede confirmar que el tráfico fluyó correctamente a través de los 3 switches. Si uno de los nexus tiene una discrepancia en counter, RX o TX, es decir, donde se puede descartar el tráfico.