Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Topología

Background

Identificación de interfaces

Rutas en N9K1

Rutas en N9K2

Rutas en N9K3

Identificación del tamaño del paquete

Realización de la prueba

Verificar solicitud ICMP

Verificar respuesta ICMP

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

Nombre

Plataforma

Versión

N9K1

N9K-C93108TC-EX

9.3(10)

N9K2

N9K-C93108TC-EX

9.3(10)

N9K3

N9K-C93108TC-EX

9.3(10)

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

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

Se puede observar que N9K1 envió 5 paquetes en la interfaz e1/1

Se puede observar que N9K2 recibió 5 paquetes en la interfaz e1/1 y envió 5 paquetes en la interfaz e1/2

Se puede observar que N9K3 recibió 5 paquetes en la interfaz e1/1

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

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

Se puede observar que N9K1 recibe 5 paquetes en la interfaz e1/1

Se puede observar que N9K2 envió 5 paquetes en la interfaz e1/1 y recibió 5 paquetes en la interfaz e1/2

Se puede observar que N9K3 envió 5 paquetes en la interfaz e1/1

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.