Switches : Cisco Nexus 3500 Series Switches

Nexo 3500 caídas de resultados y buffer QoS

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios

Introducción

Este documento describe los comandos usados para resolver problemas el tipo de tráfico caído en la plataforma y el búfer de salida (OB) del nexo 3500 en los cuales se cae este tráfico.

Contribuido por Clark Dyson, el Advanced Services de Cisco, y Yogesh Ramdoss, ingeniero de Cisco TAC.

Metodología

  1. Comprobación para las caídas de resultados

  2. Determine si los descensos son unicast o Multicast

  3. Determine se utiliza qué búfer de salida

  4. Marque la supervisión activa del buffer

Marque para saber si hay caídas de resultados

Marque las estadísticas de la interfaz física para determinar si el tráfico se cae en la dirección de salida. Determine si el “descarte de la salida” contrario en la dirección TX incrementa y/o es no-cero.

Nexus3548# show interfce Eth1/7
Ethernet1/7 is up
 Dedicated Interface
  Hardware: 100/1000/10000 Ethernet, address: a44c.116a.913c (bia a44c.116a.91ee)
  Description: Unicast Only
  Internet Address is 1.2.1.13/30
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec
  reliability 255/255, txload 35/255, rxload 1/255
  Encapsulation ARPA
  full-duplex, 1000 Mb/s, media type is 1G
  Beacon is turned off
  Input flow-control is off, output flow-control is off
  Rate mode is dedicated
  Switchport monitor is off
  EtherType is 0x8100
  Last link flapped 00:03:48
  Last clearing of "show interface" counters 00:03:55
  1 interface resets
  30 seconds input rate 200 bits/sec, 0 packets/sec
  30 seconds output rate 0 bits/sec, 0 packets/sec
  Load-Interval #2: 5 minute (300 seconds)
    input rate 40 bps, 0 pps; output rate 139.46 Mbps, 136.16 Kpps
  RX
    1 unicast packets  118 multicast packets  0 broadcast packets
    119 input packets  9830 bytes
    0 jumbo packets  0 storm suppression bytes
    0 runts  0 giants  0 CRC  0 no buffer
    0 input error  0 short frame  0 overrun   0 underrun  0 ignored
    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop
    0 input with dribble  0 input discard
    0 Rx pause
  TX
    23605277 unicast packets  0 multicast packets  0 broadcast packets
    23605277 output packets  3038908385 bytes
    0 jumbo packets
    0 output errors  0 collision  0 deferred  0 late collision
    0 lost carrier  0 no carrier  0 babble 11712542 output discard
    0 Tx pause 

Determine si los descensos son unicast o Multicast

Una vez que se determina que la interfaz cae el tráfico, ingrese el comando de la interfaz para colocación en cola <x/y> de la demostración para descubrir si el tráfico caído es Multicast o unicast. En las versiones anterior de 6.0(2)A3(1), la salida parece:

Nexus3548# show queuing interface Eth1/7
Ethernet1/7 queuing information:
  TX Queuing
    qos-group  sched-type  oper-bandwidth
        0       WRR            100

  RX Queuing
    Multicast statistics:
        Mcast pkts dropped                      : 0
    Unicast statistics:
    qos-group 0
    HW MTU: 1500 (1500 configured)
    drop-type: drop, xon: 0, xoff: 0
    Statistics:
        Ucast pkts dropped                      : 11712542

En la versión 6.0(2)A3(1) y posterior, la salida parece:

Nexus3548# show queuing interface Eth1/7
Ethernet1/7 queuing information:
    qos-group  sched-type  oper-bandwidth
        0       WRR            100
    Multicast statistics:
        Mcast pkts dropped                      : 0
    Unicast statistics:
    qos-group 0
    HW MTU: 1500 (1500 configured)
    drop-type: drop, xon: 0, xoff: 0
    Statistics:      
Ucast pkts dropped                      : 11712542

Nota: Si el receptor lento del Multicast se configura para el puerto, vea el Lento-receptor del Multicast para la información de la característica. Los descensos no son seguidos por la “interfaz para colocación en cola Eth<x/y> de la demostración” debido a una limitación del hardware. Vea el Id. de bug Cisco CSCuj21006.

Determine se utiliza qué búfer de salida

En el nexo 3500, hay tres recursos compartidos del almacén intermedio usados en la dirección de salida. La salida del comando interno del puerto-mappping de la información de mtc-USD del hardware de la demostración proporciona la información de mapeo.

Nexus3548# show hardware internal mtc-usd info port-mappping
OB Ports to Front Ports:
========= OB0 =========    ========= OB1 =========    ========= OB2 =========
45 47 21 23 09 11 33 35    17 19 05 07 41 43 29 31    13 15 37 39 25 27 01 03
46 48 22 24 10 12 34 36    18 20 06 08 42 44 30 32    14 16 38 40 26 28 02 04

Front Ports to OB Ports:
=OB2= =OB1= =OB0= =OB2=    =OB1= =OB0= =OB2= =OB1=    =OB0= =OB2= =OB1= =OB0=
12 14 04 06 08 10 00 02    00 02 04 06 08 10 12 14    12 14 04 06 08 10 00 02
13 15 05 07 09 11 01 03    01 03 05 07 09 11 13 15    13 15 05 07 09 11 01 03

La primera parte de los resultados indica que el pool 0 OB es utilizado por los delantero-puertos tales como 45, 46, 47, 48, y así sucesivamente y OB1 es utilizado por los delantero-puertos 17, 18, y así sucesivamente.

La segunda parte de que los resultados indican que Eth1/1 está asociado OB2 al puerto 12, Eth1/2 se asocia OB2 al puerto 13, y así sucesivamente.

El puerto en la discusión, Eth1/7, se asocia a OB1.

Vea la sección de administración del búfer en este documento para más información.

Marque la supervisión activa del buffer

Vea el whitepaper activo de la supervisión del buffer del nexo 3548 de Cisco y la sección ABM en este documento para más información sobre esta característica.

Los contadores incrementan activamente

Si los descartes de la salida incrementan activamente, habilite la supervisión activa del buffer (ABM) con este comando. Observe que el comando permite que usted monitoree el unicast o el Multicast, pero no ambos. También, le deja configurar el intervalo de muestreo y los valores de umbral.

hardware profile buffer monitor [unicast|multicast] {[sampling <interval>] |
[threshold <Kbytes>]}

Salida abreviada

Una vez que se habilita el ABM, usted puede ver los resultados con este comando.

Nexus3500# show hardware profile buffer monitor interface e1/7 brief
Brief CLI issued at: 09/30/2013 19:43:50

                     Maximum buffer utilization detected
                   1sec     5sec    60sec     5min      1hr
                  ------   ------   ------   ------   ------
Ethernet1/7       5376KB   5376KB   5376KB      N/A      N/A

Estos resultados indican que el de 6 MB del 5.376 MB del buffer OB1 ha sido utilizado por el tráfico de unidifusión que salió de Eth1/7 para los últimos 60 segundos.

Salida detallada

Nexus3500# show hardware profile buffer monitor interface Eth1/7 detail
Detail CLI issued at: 09/30/2013 19:47:01

Legend -
384KB  - between   1 and 384KB of shared buffer consumed by port
768KB  - between 385 and 768KB of shared buffer consumed by port
307us  - estimated max time to drain the buffer at 10Gbps

Active Buffer Monitoring for Ethernet1/7 is: Active
KBytes                 384  768 1152 1536 1920 2304 2688 3072 3456 3840 4224 4608 4992 5376 5760 6144
us @ 10Gbps            307  614  921 1228 1535 1842 2149 2456 2763 3070 3377 3684 3991 4298 4605 4912
                      ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
09/30/2013 19:47:01      0    0    0    0    0    0    0    0    0    0    0    0    0  250    0    0
09/30/2013 19:47:00      0    0    0    0    0    0    0    0    0    0    0    0    0  252    0    0
09/30/2013 19:46:59      0    0    0    0    0    0    0    0    0    0    0    0    0  253    0    0
09/30/2013 19:46:58      0    0    0    0    0    0    0    0    0    0    0    0    0  250    0    0
09/30/2013 19:46:57      0    0    0    0    0    0    0    0    0    0    0    0    0  250    0    0
09/30/2013 19:46:56      0    0    0    0    0    0    0    0    0    0    0    0    0  250    0    0
09/30/2013 19:46:55      0    0    0    0    0    0    0    0    0    0    0    0    0  251    0    0
09/30/2013 19:46:54      0    0    0    0    0    0    0    0    0    0    0    0    0  251    0    0
09/30/2013 19:46:53      0    0    0    0    0    0    0    0    0    0    0    0    0  250    0    0
09/30/2013 19:46:52      0    0    0    0    0    0    0    0    0    0    0    0    0  253    0    0
09/30/2013 19:46:51      0    0    0    0    0    0    0    0    0    0    0    0    0  249    0    0
...

La información en cada fila se registra en un segundo intervalo. Cada columna representa el uso de búfer. Como se menciona en el comando resulta, si hay un valor sin cero señalado para la columna el "384" que significa que el uso de búfer estaba entre 0-384 kilobytes cuando el ABM sondeó el uso OB. El número no-cero es la cantidad de veces que el uso fue señalado.

Estos resultados indican que OB1 hizo un promedio del 5.376 MB del uso entre 249 - 253 veces para cada segundo en el último 10 segundos para Eth1/7. Tarda 4298 microsegundos (nosotros) para borrar el buffer de este tráfico.

Genere un registro cuando se cruza un umbral

Si el contador de caídas y el uso de búfer incrementa periódicamente, después es posible fijar un umbral y generar un mensaje del registro cuando se cruza el umbral.

logging level mtc-usd 5
hardware profile buffer monitor unicast sampling 10 threshold 4608

Se fija el comando de monitorear el tráfico de unidifusión en un intervalo de 10 nanosegundos y cuando pasa por encima el 75% del buffer él genera un registro.

Usted puede también crear un planificador de trabajos para recoger las estadísticas y el contador de la interfaz ABM hechos salir cada hora y añadirlo al final del fichero a los archivos del bootflash. Este ejemplo está para el tráfico Multicast:

hardware profile buffer monitor multicast

feature scheduler
scheduler job name ABM
show hardware profile buffer monitor detail >> ABMDetail.txt
show clock >> ABMBrief.txt
show hardware profile buffer monitor brief >> ABMBrief.txt
show clock >> InterfaceCounters.txt
show interface counters errors >> InterfaceCounters.txt
scheduler schedule name ABM
time start now repeat 1:0
job name ABM

Bug Cisco notable ID

  • Id. de bug Cisco CSCum21350: Las inestabilidades del puerto rápidas hacen todos los puertos en el mismo buffer de QoS caer todo el Multicast/el tráfico de broadcast TX. Esto se repara en 6.0(2)A1(1d) y posterior.
  • Id. de bug Cisco CSCuq96923: Se pega el bloque del buffer del Multicast, que da lugar al Multicast de la salida/a los descensos transmitidos. Este problema todavía está bajo investigación.

Preguntas Frecuentes

¿El ABM afecta el funcionamiento o el tiempo de espera?

No, esta característica no afecta el tiempo de espera o el funcionamiento del dispositivo.

¿Cuál es el impacto del intervalo de sondeo más bajo del hardware ABM?

Por abandono, el intervalo de sondeo del hardware es 4 milisegundos. Usted puede configurar este valor de hasta sólo 10 nanosegundos. No hay impacto del funcionamiento o del tiempo de espera debido al intervalo de sondeo más bajo del hardware. La interrogación predeterminada del hardware de 4 milisegundos se selecciona para aseegurarle no desborda los contadores del histograma antes de que el software sondee cada 1 segundo. Si usted baja el intervalo de sondeo del hardware entonces puede ser que sature los Contadores de hardware en 255 muestras. El dispositivo no puede manejar un software que sondea más bajo de 1 segundo, para hacer juego sondear más bajo del hardware debido al CPU y a las restricciones de la memoria. El whitepaper tiene el ejemplo del intervalo de sondeo más bajo del hardware y de su caso del uso.

Apéndice: Información sobre la Función

Administración del búfer

  • Almacén intermedio del paquete del 18 MB compartido por 3 bloques OB:
    • ~4 MB reservados: Tamaños basados en la Unidad máxima de transmisión (MTU) configurada (MTU) (por la suma del puerto de la talla del MTU x 2 x # de los grupos habilitados de QoS)
    • ~14 MB compartidos: Resto del búfer total
    • ~767 KB de OB: 0 para los paquetes destinados CPU
  • El 6 MB para cada OB es compartido por un conjunto de 16 puertos (comando interno de la correlación de puertos de la información de mtc-USD del hardware de la demostración).

Planificación

previsión de la Tres-capa:

  • Unicast y Multicast
  • Clases de tráfico del mismo esquema de planificación
  • Clases de tráfico a través del esquema

Lento-receptor del Multicast

En este diagrama:

  • La congestión continua es el on1 introducido G Eth1/40.
  • Otros receptores de multidifusión (Eth1/1 - 3) en el bloque del buffer es afectado debido al comportamiento de previsión del Multicast.  Los receptores en otros bloques del buffer siguen siendo inafectados.
  • El “lento-receptor del Multicast” se puede aplicar a e1/40 para evitar la pérdida de tráfico en los puertos no congestionados.
  • El “lento-receptor del Multicast” drena el Multicast a una tarifa de 10 G en Eth1/40. Todavía se espera que los descensos ocurran en el puerto congestionado.
  • Configurado con el comando <x> del puerto del lento-receptor del Multicast del perfil del hardware.

Supervisión activa del buffer

Vea el whitepaper activo de la supervisión del buffer del nexo 3548 de Cisco para una descripción de la característica.

Implementación de hardware

  • ASIC tiene 18 compartimientos y cada compartimiento corresponde a un rango de la utilización del almacén intermedio (por ejemplo, 0-384KB, 385-768KB, y así sucesivamente).
  • ASIC sondea la utilización del almacén intermedio para todos los puertos cada 4 milisegundos (valor por defecto).  Este intervalo de sondeo de ASIC es tan bajo configurable como 10 nanosegundos.
  • De acuerdo con la utilización del almacén intermedio para cada intervalo de sondeo del hardware, el contador del compartimiento para el rango correspondiente se incrementa. Es decir, si el puerto 25 consume 500 KB del buffer, el compartimiento #2 (385-768KB) al revés se incrementa.
  • Este contador de la utilización del almacén intermedio se mantiene para cada interfaz en el formato del histograma.
  • Cada compartimiento se representa con 8 bits, así que se reajustan los maxes contrarios hacia fuera en 255 y él una vez que el software lee los datos.

Implementación del software

  • Cada 1 segundo, el software sondea ASIC para descargar y borrar todos los contadores del histograma.
  • Estos contadores del histograma se mantienen en la memoria por 60 minutos con 1 segundo granularity.
  • El software también la aseegura copia el histograma del buffer al bootflash cada hora, que se puede copiar al analizador para el análisis adicional.
  • Con eficacia, esto mantiene las horas 2 de datos del histograma del buffer para todos los puertos, de la última 1 hora de la memoria y de segunda hora en el bootflash.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118904