Introducción
En este documento se describe cómo solucionar los problemas de las caídas de salida en las plataformas Catalyst 9000 Series.
Prerequisites
Requirements
Para solucionar problemas de calidad de servicio (QoS) en las plataformas Catalyst serie 9000, debe comprender:
- Conceptos de QoS estándar
- Interfaz de línea de comandos (CLI) de QoS modular
Componentes Utilizados
La información de este documento se basa en esta versión de hardware y software, pero la metodología y la mayoría de los comandos se pueden aplicar a otros switches Catalyst de la serie 9000 en otro código:
- Cisco Catalyst 9300
- Cisco IOS® XE 16.12.3
Nota: Consulte la guía de configuración correspondiente para conocer los comandos que se utilizan para activar estas funciones en otras plataformas de Cisco.
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.
Antecedentes
Para obtener una explicación detallada de QoS en las plataformas Catalyst serie 9000, que incluye configuraciones de QoS predeterminadas, estructura de cola y explicaciones de búfer, consulte el informe técnico sobre QoS y colas de Catalyst 9000 Revise la guía de la versión recomendada para asegurarse de que cuenta con el software recomendado más reciente para su plataforma. Estas recomendaciones aseguran que su software sea compatible y ayudan a evitar errores conocidos en códigos antiguos. Versiones recomendadas para Catalyst
Qué son las caídas de salida
El conocimiento de la asignación del búfer puede ayudarle a comprender cómo la congestión del búfer provoca caídas de salida. La congestión ocurre cuando la interfaz de destino tiene un número de paquetes que exceden su velocidad de salida. Estos paquetes deben almacenarse en el búfer hasta que se puedan transmitir. Tenga en cuenta que estos switches tienen como máximo 36 MB de búferes por ASIC, que luego se comparten entre todos los puertos en el ASIC. Mientras que una interfaz de salida puede vaciar ese buffer a velocidad de línea, cualquier escenario que cause que los paquetes se almacenen en buffer a mayor velocidad puede causar congestión. La congestión puede ocurrir incluso si la ráfaga de tráfico solo dura una fracción de segundo, y puede causar latencia en el tráfico, o caídas de salida si ese buffer se llenara completamente.
Nota: El contador de caídas de salida que se muestra en show interface se presenta en bytes de forma predeterminada. En la versión 16.9.3 y posteriores, estos contadores son paquetes de forma predeterminada.
Tipos de congestión
Como se muestra en la imagen 1, hay dos tipos de congestión.

Imagen 1. Tipos de congestión
Los dos tipos de congestión que se muestran en la Imagen 1 son:
- Muchos a uno: Cuando varios puertos de origen envían tráfico hacia un único destino al mismo tiempo, el puerto de destino puede congestionarse con la cantidad de tráfico que ha recibido de múltiples orígenes.
- Discordancia de velocidad: Cuando un puerto con mayor velocidad transmite a un puerto con menor velocidad (por ejemplo, de 10 Gbps a 1 Gbps), los paquetes deben tardar en salir del puerto de salida, lo que puede provocar retrasos o caídas de paquetes.
Congestión con bajo rendimiento
Las ráfagas de tráfico pueden causar caídas de salida incluso cuando la velocidad de salida de la interfaz es significativamente menor que la capacidad máxima de la interfaz. De forma predeterminada, las tasas de salida en el comando show interface se promedian durante cinco minutos, lo que no es adecuado para capturar ráfagas de corta duración. Es mejor promediarlos durante 30 segundos, aunque incluso en este escenario una ráfaga de tráfico durante milisegundos podría dar lugar a caídas de salida que no provoquen que la velocidad promedio de 30 segundos aumente. Este documento se puede utilizar para resolver cualquier otro tipo de congestión que se observe en su switch Catalyst serie 9000.
Validar congestión de búfer
Hay dos comandos que se utilizan para validar la congestión del búfer. El primer comando es show platform hardware fed switch active qos queue config interface <interface>. Este comando le permite ver la asignación de memoria intermedia actual en el puerto, como se muestra en la Imagen 2.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:2 - 1800
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 7 800 19 475 0 0 3 2400
1 1 5 0 8 1200 19 712 8 300 3 2400
2 1 5 0 6 0 0 0 0 0 3 2400
3 1 5 0 6 0 0 0 0 0 3 2400
4 1 5 0 6 0 0 0 0 0 3 2400
5 1 5 0 6 0 0 0 0 0 3 2400
6 1 5 0 6 0 0 0 0 0 3 2400
7 1 5 0 6 0 0 0 0 0 3 2400
Imagen 2. Asignación de búfer de cola
Concretamente, desea consultar la columna Hardmax y Softmax, que muestra el número de búferes que tienen disponibles las colas. Para obtener información sobre qué son estas memorias intermedias y cómo se asignan de forma predeterminada, vea el Informe técnico sobre QoS y colas de Catalyst 9000.
El segundo comando es show platform hardware fed switch active qos queue stats interface <interface>. Este comando le permite ver las estadísticas por cola en una interfaz, que incluye cuántos bytes se pusieron en cola en los búfers y cuántos bytes se descartaron debido a la falta de búfers disponibles.
9300#show platform hardware fed switch active qos queue stats interface Gig 1/0/1
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 384251797 0
1 0 0 0 488393930284 0
2 0 0 0 0 0
3 0 0 0 0 0
4 0 0 0 0 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 192308101 0 0 0
2 0 0 0 0 0 0
3 0 0 0 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Imagen 3. Estadísticas del búfer de cola con caídas
Como se muestra en la Imagen 3, la Cola 0 y la Cola 1 tienen bytes en cola, pero es la Cola 1 la que experimenta caídas en la columna Drop-TH2. Esta información indica que el tráfico de la cola 0 no se ha visto afectado por esta congestión y que la causa de la congestión es específicamente el tráfico de la cola 1.
Modificar búferes para resolver caídas de salida
Multiplicador SoftMax
Para aumentar el número de búferes que cada cola puede solicitar del conjunto compartido, aumente el umbral SoftMax con la configuración qos queue-softmax-multiplier <100 - 1200>. El valor más alto es 1200 y aumenta en un múltiplo de 12, la capacidad de una cola de un solo puerto para absorber microrráfagas. Este comando aumenta los umbrales de cola de puerto para que la cola de puerto pueda consumir unidades de buffer adicionales del conjunto compartido. Como se muestra en la imagen 4, la configuración y la asignación de búfer aumentada.
9300(config)#qos queue-softmax-multiplier 1200
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 14400
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 6 200 9 9600 2 600 0 0 1 15000
1 1 5 0 10 14400 2 900 1 450 1 15000
2 1 5 0 6 0 0 0 0 0 1 15000
3 1 5 0 6 0 0 0 0 0 1 15000
4 1 5 0 6 0 0 0 0 0 1 15000
5 1 5 0 6 0 0 0 0 0 1 15000
6 1 5 0 6 0 0 0 0 0 1 15000
7 1 5 0 6 0 0 0 0 0 1 15000
Imagen 4. Configuración de cola con multiplicador SoftMax de 1200
Ésta es una configuración común utilizada como método rápido para resolver caídas de salida. En la Imagen 4, esta configuración se aplica a todas las colas sin prioridad en todas las interfaces. La asignación del búfer en sí supone que las microrráfagas no ocurren en todos los puertos del switch al mismo tiempo. Si se producen microrráfagas en momentos aleatorios, el búfer compartido puede dedicar unidades de búfer adicionales para absorberlas.
Modificación de búfer por cola
La modificación del búfer por cola se puede aprovechar en escenarios en los que no se puede utilizar el multiplicador SoftMax o en escenarios en los que se intenta ajustar los búferes para que se ajusten a un perfil de tráfico. Para modificar la asignación del búfer de cola, el switch por interfaz, debe utilizar mapas de políticas. En la mayoría de las circunstancias, se modifica el policy-map actual de una interfaz y se cambian las memorias intermedias por clase.
En este ejemplo, la interfaz GigabitEthernet1/0/48 ha experimentado caídas de salida. Como se muestra en la imagen 5, el policy-map de salida que se aplica a esta interfaz.
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
class class-default
Imagen 5. Ejemplo de mapa de política
Este policy-map tiene 5 class-maps, que da como resultado 5 colas de salida totales en la interfaz. Cada clase tiene un número predeterminado de búferes asignados en función de su nivel de prioridad.
La imagen 6 muestra las asignaciones de búfer actuales.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 600
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 100 9 100 0 0 0 0 3 800
1 1 7 100 10 400 19 237 0 0 3 800
2 1 5 0 10 400 19 237 8 100 3 800
3 1 5 0 10 400 19 237 8 100 3 800
4 1 5 0 10 400 19 237 8 100 3 800
5 1 5 0 6 0 0 0 0 0 3 800
6 1 5 0 6 0 0 0 0 0 3 800
7 1 5 0 6 0 0 0 0 0 3 800
Imagen 6. Configuración del búfer de cola con la política de ejemplo
Dado que esta interfaz ha experimentado caídas de salida, observe las estadísticas de colocación en cola de la interfaz para ver dónde está la congestión.
9300#show platform hardware fed switch active qos queue stats interface gigabitEthernet 1/0/48
DATA Port:0 Enqueue Counters
---------------------------------------------------------------------------------------------
Q Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2 Qpolicer
(Count) (Bytes) (Bytes) (Bytes) (Bytes)
- ------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 489094 0
1 0 0 0 4846845 0
2 0 0 0 89498498 0
3 0 0 0 21297827045 0
4 0 0 0 74983184 0
5 0 0 0 0 0
6 0 0 0 0 0
7 0 0 0 0 0
DATA Port:0 Drop Counters
-------------------------------------------------------------------------------------------------------------------------------
Q Drop-TH0 Drop-TH1 Drop-TH2 SBufDrop QebDrop QpolicerDrop
(Bytes) (Bytes) (Bytes) (Bytes) (Bytes) (Bytes)
- -------------------- -------------------- -------------------- -------------------- -------------------- --------------------
0 0 0 0 0 0 0
1 0 0 0 0 0 0
2 0 0 0 0 0 0
3 0 0 3854484 0 0 0
4 0 0 0 0 0 0
5 0 0 0 0 0 0
6 0 0 0 0 0 0
7 0 0 0 0 0 0
Imagen 7. Estadísticas del búfer de cola con caídas con una política de ejemplo
La imagen 7 muestra que la cola 3 tiene más tráfico en cola que cualquier otra cola, y también es la única que ha experimentado caídas de salida. Dado que el número de cola comienza en 0, la cola 3 se asigna al cuarto mapa de clase, class Data.
Para aliviar las caídas en esta cola, asigne más buffers a la Cola 3. Para cambiar esta asignación de buffer, utilice la configuración de ratio de queue-buffers <0-100> en el policy-map. Si se configura en cada clase de la política, debe sumar hasta 100. Si sólo configura una sola clase con este comando, el sistema intenta restar de manera uniforme los buffers de las otras colas.
En la Imagen 8, la clase Data se ha configurado con la proporción de queue-buffers 40.
policy-map MYPOL
class Voice
priority level 1 percent 20
class Video
priority level 2 percent 10
class Control
bandwidth percent 10
class Data
bandwidth percent 5
queue-buffers ratio 40
Imagen 8. Ejemplo de mapa de política con búferes de cola modificados
En la imagen 9, puede ver que la clase Data ahora tiene el 40% de los búfers de interfaz, 800 búfers en total.
9300#show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
Asic:0 Core:0 DATA Port:47 GPN:48 LinkSpeed:0x1
AFD:Disabled FlatAFD:Disabled QoSMap:0 HW Queues: 376 - 383
DrainFast:Disabled PortSoftStart:3 - 1200
DTS Hardmax Softmax PortSMin GlblSMin PortStEnd
----- -------- -------- -------- -------- ---------
0 1 7 75 9 75 0 0 0 0 3 1600
1 1 7 75 10 300 19 178 0 0 3 1600
2 1 5 0 10 300 19 178 8 75 3 1600
3 1 5 0 7 800 19 475 8 200 3 1600
4 1 5 0 10 300 19 178 8 75 3 1600
5 1 5 0 6 0 0 0 0 0 3 1600
6 1 5 0 6 0 0 0 0 0 3 1600
7 1 5 0 6 0 0 0 0 0 3 1600
Imagen 9. Configuración del búfer de cola con la política de ejemplo actualizada
Esto también hace que las otras colas tengan menos memorias intermedias Softmax. Es importante realizar estos cambios en el búfer en pequeños incrementos para garantizar que los cambios no provoquen caídas de salida en las otras colas.
Con ese cambio realizado, verifique las estadísticas de la cola y vea si las caídas siguen incrementándose en esta u otra cola. Si las caídas continúan, modifique aún más la configuración del buffer de cola hasta que se resuelvan las caídas de salida.
Métodos alternativos para administrar la congestión
QoS es principalmente un método para priorizar el tráfico y no es una solución para cada escenario de caída de salida. Hay algunos escenarios donde una modificación de los búferes de cola no es suficiente para resolver todas las caídas de salida. En estos escenarios, puede administrar la congestión de varias otras maneras:
- Reduzca el índice de sobresuscripción.
Esto incluye métodos que aumentan el ancho de banda de salida, como canales de puerto o múltiples rutas de igual coste (ECMP), pero que también pueden requerir configuraciones más implicadas, como la ingeniería de tráfico.
- Utilice un programador de colas para priorizar el tráfico.
Aunque un planificador de colas no detiene la congestión, sí protege su tráfico importante del impacto de la congestión
- Utilice algoritmos de gestión de la congestión, como el descarte anticipado aleatorio ponderado (WRED) o el descarte trasero ponderado (WTD) para descartar parte del tráfico antes.
- Controle el tráfico de entrada para reducir el tráfico de salida.
Análisis de caídas de salida con Wireshark
Wireshark es una herramienta útil para identificar las ráfagas de tráfico que causan la congestión y las caídas del búfer. Si SPAN una interfaz en la dirección de salida mientras experimenta caídas, Wireshark puede graficar la velocidad de salida para ver cuándo y qué tráfico desencadenó las caídas. Esto es especialmente útil cuando se identifican caídas de salida en escenarios de bajo rendimiento.
Ver la velocidad de E/S
Una vez abierta la captura SPAN con Wireshark, seleccione Statistics, luego I/O Graph, como se muestra en la imagen 10.

Imagen 10. Seleccione el gráfico de E/S
Una vez seleccionado, Wireshark genera un gráfico del tráfico en bits por segundo. La imagen 11 muestra un ejemplo de gráfico para una interfaz mientras experimentaba caídas de salida.

Imagen 11. Bits de gráficos de E/S/milisegundo
El gráfico de la imagen 11 indica que la interfaz tenía un rendimiento máximo que apenas supera los 80 Mbps. La vista gráfica predeterminada no es lo suficientemente granular como para identificar pequeñas ráfagas de tráfico que causan caídas de paquetes. Es un promedio de la velocidad de tráfico por segundo. Para comprender cómo esta velocidad podría causar la congestión del búfer, considere el rendimiento en una escala de milisegundos.
Una interfaz Gigabit puede reenviar 1.000.000.000 de bits por segundo. Una vez convertido a milisegundos, esto equivale a 1.000.000 (o 10^6) bits por milisegundo.
Cuando la velocidad de la interfaz va más allá de esa velocidad de reenvío de la interfaz, los switches deben almacenar en búfer estos paquetes, lo que resulta en congestión y caídas de salida.
Ver la velocidad de E/S en milisegundos
Wireshark permite al usuario representar gráficamente la velocidad de E/S en bits por milisegundo. Para ello, reduzca el intervalo de 1 segundo a 1 ms y, a continuación, haga clic en Restablecer para ver correctamente el gráfico. Este paso se muestra en la imagen 12.

Imagen 12. Reduzca el intervalo a 1 ms y reinicie el gráfico
El gráfico actualizado muestra con mayor precisión la verdadera velocidad de E/S de la interfaz. Cuando la velocidad alcanza o supera los 10^6 bits por milisegundo, el switch experimenta congestión o caídas de salida. La imagen 13 muestra el gráfico de E/S actualizado para una interfaz que experimentó caídas de salida.

Imagen 13. Bits de gráficos de E/S/milisegundo
La imagen 13 muestra que hay varios picos de tráfico que cumplen o exceden el umbral de 10^6. El tráfico estaría sujeto a almacenamiento en búfer y se descartaría si supera el tamaño del búfer de salida.
Nota: Si el destino SPAN está conectado por una interfaz de 1 Gbps, la velocidad de E/S en Wireshark no puede superar esa velocidad de 10^6 bits por milisegundo, independientemente de cuál sea la velocidad de la interfaz de origen. En su lugar, la interfaz de destino SPAN almacena en el búfer o descarta esos paquetes. Es común ver la meseta del gráfico de E/S en ese rendimiento máximo o presentar una velocidad de tráfico promedio que parece ir más alto.