Comprender los límites de cola y las caídas de salida en las plataformas de software IOS

Introducción

Este documento describe los límites de cola y las caídas de salida en las plataformas del software Cisco IOS® y los routers de acceso heredados.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Guía de Configuración de Soluciones de Calidad de Servicio de Cisco IOS®

• QoS: estructura de colas jerárquica (HQF)

Componentes Utilizados

La información que contiene este documento se basa en estas versiones de software:

• Para Pre-HQF: routers Cisco que ejecutan Cisco IOS Software Release 12.3(26)

• Para HQF: routers de Cisco que ejecutan el software Cisco IOS versión 12.4(22)T

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.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

Este documento se aplica solamente a las plataformas de software Cisco IOS®, que generalmente incluyen Cisco 7200VXR y Cisco ISR 3800, 2800, 1800 Series Routers, y los Cisco Access Routers heredados que incluyen 3700, 3600, 2600, y 1700 Series Routers.

Class-Based Weighted Fair Queueing Primer

En imágenes de Cisco IOS anteriores a HQF, cualquier clase con un bandwidth generalmente se puede priorizar contra clases sin ancho de banda o prioridad en función del peso de las clases. Para comprender el algoritmo de programación CBWFQ (Class-Based Weighted Fair Queueing), primero debe comprender el concepto de peso, que es específico del flujo para las colas equitativas basadas en flujo y específico de clase para las colas basadas en clase individuales dentro de la cola equilibrada ponderada basada en clase.

La fórmula para obtener el peso de una cola equilibrada basada en flujo es:

32384 / (IP Prec + 1)

Las clases definidas por el usuario dentro de una cola equilibrada ponderada basada en clases derivan sus ponderaciones respectivas en función de la bandwidth configurado en la clase como una proporción de la SUMA de todas las clases de ancho de banda en la cola basada en clase. La fórmula exacta es patentada.

En las imágenes HQF, las colas equitativas basadas en flujo, configurables tanto en clases definidas por el usuario como en clases predeterminadas con cola regular , se programan equitativamente (en lugar de por peso). Además, en HQF, la prioridad de programación de una cola basada en clases se determina en función del planificador HQF y no en la fórmula de ponderación heredada de las clases.

Nota: Esta sección no pretende ser un análisis de comportamiento completo para las operaciones de Class Based Queueing. La intención es una explicación de cómo CBWFQ aplica los límites de cola y las caídas de salida.

Comprender los límites de cola y las caídas de salida

Clases definidas por el usuario configuradas con el comando "priority"

Para clases definidas por el usuario de MQC configuradas con cualquier variante de la priority comando, con  priority , priority  ,y priority percent  incluido.

Comportamiento previo a HQF

Técnicamente, aunque no existe CLI para verlo, y no es configurable, existe una cola del sistema "oculta" que es compartida por todos los datos de clase de prioridad. Actúa como un repositorio temporal de datos prioritarios después de que se haya clasificado y después de que el regulador de tráfico con detección de congestión lo haya permitido. Los paquetes LLQ se colocan en esta cola del sistema "oculta" si no se pueden colocar directamente en el anillo de transmisión de la interfaz de salida durante la interrupción de recepción, que de otra manera se denomina congestión funcional. En esta situación, debido a la congestión funcional existente, el paquete se evalúa frente al regulador condicional LLQ durante toda la interrupción de recepción y mientras siga siendo propiedad del controlador de interfaz de recepción. Si el regulador condicional LLQ no descarta el paquete, se coloca en esta cola del sistema LLQ "oculta" y se libera la interrupción de recepción. Por lo tanto, todos los paquetes colocados en esta cola del sistema "oculta" se han conformado con el regulador de detección de congestión LLQ y el planificador LLQ/CBWFQ puede quitarlos de la cola al anillo de transmisión de la interfaz de egreso inmediatamente.

A pesar de la existencia de esta cola, el comportamiento es diferente de las colas del IOS de Cisco creadas para datos que no son LLQ (como colas de ancho de banda y cola de cola regular) en que no se puede incurrir en latencia de colocación en cola adicional (por encima de la latencia del anillo de transmisión) ya que los paquetes de esta cola pueden ser inmediatamente drenados al anillo de transmisión por el planificador LLQ/CBWFQ. Si el regulador condicional no descarta un paquete de clase de prioridad durante la interrupción de recepción, este paquete LLQ puede existir brevemente en esta cola del sistema "oculta" antes de quitarse de la cola al anillo de transmisión de la interfaz de salida. En este caso, el planificador LLQ/CBWFQ puede presentar inmediatamente el paquete al anillo de transmisión de la interfaz de salida. El regulador condicional se ha ejecutado antes de que admita el paquete en LLQ/CBWFQ, por lo que limita el LLQ a la velocidad de prioridad configurada.

En resumen, se recomienda descartar los datos LLQ que excedan la velocidad de prioridad en momentos de congestión que incurrir en latencia de colocación en cola adicional, que es un componente fundamental de LLQ. Este mecanismo de regulación condicional permite una cola de prioridad estricta y no permite que la cola de prioridad monopolice la interfaz completa PLIM, lo cual es una mejora respecto de la función de regulación prioritaria heredada de Cisco IOS.

• Límite de cola pre-HQF: NA

• Comportamiento de "prioridad" + "detección aleatoria" previo al HQF: no se permite NA, WRED en LLQ.

• Comportamiento de "prioridad" + "cola regular" previo a HQF: NA, cola regular no permitida en LLQ.

• Comportamiento de "prioridad" + "detección aleatoria" + "cola justa": ND, no soportado en LLQ ni fair-queue ni random-detect.

Comportamiento de HQF

Igual que Pre-HQF excepto que la cola oculta ya no está oculta y el límite de cola ahora es configurable y el valor predeterminado es 64 paquetes.

• Límite de cola HQF: 64 paquetes

• Comportamiento HQF de "prioridad" + "detección aleatoria": NA, WRED no permitido en LLQ.

• HQF "priority" + "fair-queue": NA, fair-queue no permitido en LLQ.

• HQF "priority" + "random-detect" + "fair-queue" behavior: NA, no admite fair-queue ni random-detect en LLQ.

Clases definidas por el usuario configuradas con el comando "bandwidth"

Para clases definidas por el usuario de MQC configuradas con cualquier variante de la bandwidth comando, con  bandwidth  ,  bandwidth percent ,y  bandwidth remaining percen t  incluido.

Comportamiento previo a HQF

El límite de cola predeterminado es 64 paquetes, que se puede ajustar. Si, durante la interrupción de recepción, necesita poner en cola un paquete que resultaría en > 64 paquetes en la cola, el paquete es descartado en la cola.

• Límite de cola Pre-HQF: 64 paquetes, ajustable a través del límite de cola.

• Comportamiento de "ancho de banda" + "detección aleatoria" previo a HQF:

Ejemplo:

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

Si se configura cualquier variante de ancho de banda junto con cualquier variante de random-detect, ignore cualquier límite de cola CLI, que elimina efectivamente cualquier límite de búfer en la clase. En otras palabras, random-detect y queue-limit se excluyen mutuamente en las imágenes pre-HQF. con la estrategia random-detect as drop, el tamaño actual de la cola es ilimitado y teóricamente puede ocupar cada buffer asignado a la cola regular basada en la clase, donde este número de buffers asignados a la cola regular basada en la clase se deriva en función del punto de conexión de la política de servicio:

• Interfaz física: 1000 paquetes, ajustable con interfaz CLI hold-queue out

• ATM PVC: 500 paquetes, ajustables con PVC CLI vc-hold-queue

• Frame-Relay map-class: 600 paquetes, ajustable con frame-relay map-class CLI frame-relay hold-queue

• Política de modelado basada en la clase aplicada a la (sub)interfaz (pre-HQF): 1000 paquetes, ajustable con MQC class CLI shape max-buffers.

Nota: Todos los ejemplos de modelado basado en clase y Frame-Relay suponen que la suma de los modeladores no excede la velocidad de reloj de la interfaz.

Nota: En las imágenes previas a HQF, cuando se aplica una política de modelado basado en clase a una (sub)interfaz, tenga cuidado con la velocidad de la interfaz física subyacente, ya que las interfaces <2Mbps pueden establecer de forma predeterminada una cola equilibrada ponderada y las interfaces >2Mbps pueden establecer de forma predeterminada FIFO. En pre-HQF, la cola de modelado puede alimentar la cola de retención de la interfaz, ya sea que la política de modelado esté conectada en la subinterfaz o en el nivel de la interfaz física.

Durante la interrupción de recepción, cada vez que un paquete se convierte en candidato para una cola de salida de interfaz, el tamaño medio de cola WRED se calcula con esta fórmula:

Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

Si el tamaño medio de cola resultante es:

• Más pequeño que el umbral mínimo WRED, ponga en cola el paquete y libere la interrupción de recepción.
• Entre el umbral mínimo de WRED y el umbral máximo de WRED, posiblemente descarte el paquete con mayor probabilidad a medida que el tamaño medio de la cola se acerque al umbral máximo de WRED. Si el tamaño medio de la cola es exactamente igual al umbral máximo WRED, el paquete se descarta en función del denominador de probabilidad de marca. El denominador de probabilidad de marca también sirve como línea base para determinar qué porcentaje de paquetes se pueden descartar cuando el límite de cola promedio no es exactamente igual al umbral máximo WRED pero es superior al umbral mínimo WRED. Este es un ejemplo gráfico:

Límite de cola promedio no igual a umbral máximo WRED pero superior a umbral mínimo WRED

• • Si se descarta el paquete, se libera la interrupción de recepción y se incrementa una caída aleatoria. Si el paquete no se descarta, se pone en cola y se libera la interrupción de recepción.

  • Mayor que el umbral máximo WRED, descarte el paquete, libere la interrupción de recepción e incremente una descarta de cola.

Nota: WRED basado en precedencia IP (predeterminado) y basado en DSCP permite definir de forma diferente el denominador de probabilidad de marca, umbral mínimo y umbral máximo para diferentes valores. Aquí es donde el componente ponderado de Random Early Detection es evidente. Puede proteger determinados valores ToS relativos a otros valores cuando ajuste sus umbrales relativos y marque los denominadores de probabilidad.

Cuando la detección aleatoria y el ancho de banda se configuran juntos, el tamaño de la cola actual puede ser mayor que el umbral máximo WRED en cualquier momento dado. Esto se debe a que los umbrales mínimo y máximo de WRED sólo actúan en función del tamaño medio de la cola (no actual). Esto proporciona una oportunidad de hacer caducar todos los búferes asignados a la cola basada en clase, lo que podría dar lugar a caídas sin búfer en cualquier lugar de la cola equitativa basada en clase (consulte el Id. de error de Cisco CSCsm94757).

• Comportamiento de "ancho de banda" + "cola regular" previo a HQF:NA, no se permite cola regular en la clase de ancho de banda.

• Comportamiento de "ancho de banda" + "detección aleatoria" + "cola regular": NA, cola regular no permitida en clase de ancho de banda

Comportamiento de HQF

El comportamiento es el mismo que se describe en la sección Pre-HQF.

• Límite de cola HQF: 64 paquetes, ajustable a través del límite de cola.

Esto es lo mismo que en el pre-HQF.

• Comportamiento de "ancho de banda" + "detección aleatoria" de HQF:

Ejemplo:

policy-map HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   queue-limit 512
   random-detect

Nota: El límite de cola predeterminado es de 64 paquetes.

El comportamiento es el mismo que en la sección equivalente anterior al HQF, con una excepción importante. En las imágenes HQF, random-detect y queue-limit pueden coexistir en la misma clase definida por el usuario (o class class-default) y queue-limit puede activarse y ajustarse a 64 paquetes en una configuración predeterminada. Como tal, queue-limit puede servir como un tamaño máximo de cola actual en una clase de detección aleatoria, por lo tanto puede proporcionar un mecanismo para limitar caídas sin búfer descritas en la sección equivalente pre-HQF. Debido a esta adición, el límite de cola configurado debe ser al menos tan grande como el umbral máximo de detección aleatoria, donde el umbral máximo de detección aleatoria puede tener de forma predeterminada 40 paquetes, o de lo contrario el analizador puede rechazar la configuración.

Esto introduce una verificación de límite de cola actual en las clases WRED, por lo cual, incluso si el cálculo de Profundidad de cola promedio es menor que el umbral máximo, si el Tamaño de cola actual (no promedio) es mayor que el límite de cola, el paquete puede ser descartado, la interrupción de recepción liberada y una caída de cola registrada. Recuerde, si el límite de cola se ajusta lo suficientemente alto como para agotar los búferes de colocación en cola agregados para la cola basada en clase, aún pueden ocurrir descartes de no búfer. Las memorias intermedias de colocación en cola agregadas para HQF se definen aquí:

• Interfaz física: 1000 paquetes, ajustable con interfaz CLI hold-queue out

• ATM PVC: 500 paquetes, ajustables con PVC CLI vc-hold-queue

• Frame-Relay map-class: 600 paquetes, ajustable con frame-relay map-class CLI frame-relay hold-queue

• Política de modelado basada en clase aplicada a la interfaz física en código HQF: 1000 paquetes, ajustable con una combinación de interfaz CLI hold-queue out y child policy queue-limit donde child policy queue-limit tiene un límite superior de interfaz hold-queue out.

• Política de modelado basada en la clase aplicada a la subinterfaz en código HQF: 512 paquetes, no ajustables (investigue con el equipo de la plataforma NSSTG QoS, debe ser ajustable)

Nota: Todos los ejemplos de modelado basado en clase y Frame-Relay suponen que la suma de los modeladores no excede la velocidad de reloj de la interfaz.

He aquí un ejemplo real:

policy-map JACKLYN
 class 1
    bandwidth 64
    queue-limit 500 packets
     random-detect
     random-detect precedence 1 22 300

Durante este resultado, no se genera tráfico a través de la interfaz:

F340.11.25-7200-5_LAC#show policy-map interface | i queue      
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 0/387595/0

!--- Current_q_depth is 0

        Mean queue depth: 107 packets

!--- last calculation of Average_queue_depth

En este punto, se inicia el tráfico. La secuencia no tiene ráfagas a 400 PPS y consta de tramas de 1000 bytes:

F340.11.25-7200-5_LAC#show policy-map interface | i queue
      queue limit 500 packets
      (queue depth/total drops/no-buffer drops) 461/387641/0

!--- 461 is Current_q_depth > Prec 1 max-thresh of 300 
!--- but < "queue-limit 500 packets".

        Mean queue depth: 274 packets

!--- Avg_q_depth is rising, Mark Prob Denom is being used.  F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 363/387919/0 !--- 363 is Current_q_depth and it is falling compared to last !--- iteration because WRED is random dropping packets. Mean queue depth: 351 packets !--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop !--- in addition to random-drop.  F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 199/388263/0 Mean queue depth: 312 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 303/388339/0 Mean queue depth: 276 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 325/388498/0 Mean queue depth: 314 packets F340.11.25-7200-5_LAC#show policy-map interface | i queue queue limit 500 packets (queue depth/total drops/no-buffer drops) 298/390075/0 Mean queue depth: 300 packets

Observe cómo, eventualmente, con una secuencia sin ráfagas, la Profundidad de cola promedio de WRED puede igualar la Profundidad de cola actual, que es el comportamiento esperado.

• Comportamiento de "ancho de banda" + "cola regular" de HQF:

Cuando el ancho de banda y fair-queue se aplican juntos a una clase HQF definida por el usuario, a cada cola basada en flujo se le asigna un límite de cola igual a .25 * queue-limit. Debido a que el límite de cola predeterminado es de 64 paquetes, a cada cola basada en flujo de una cola justa se le pueden asignar 16 paquetes. Si cuatro flujos atraviesan esta clase, de forma predeterminada cada cola de flujo tendría 16 paquetes, por lo tanto, nunca esperaría ver paquetes totales en cola de >64 (4 *16). Todas las caídas de cola de una cola de flujo individual se registran como caídas de flujo. Si el número de colas de flujo era significativamente alto, al igual que el límite de cola, habría otra oportunidad para descartes sin búfer. Por ejemplo, si asume que el punto de conexión de la política es una interfaz física, donde se asignan 1000 búferes agregados:

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128

En esta configuración, el tráfico apreciable en todas las colas de flujo puede hacer que los búferes de interfaz agregados mueran de hambre y dar lugar a caídas sin búfer en otras clases definidas por el usuario (consulte el Id. de error de Cisco CSCsw98427). Esto se debe a que 1024 colas de flujo, cada una con un límite de cola de 32 paquetes, pueden fácilmente sobresuscribir la asignación de búfer de 1000 interfaces agregadas basadas en clase.

• Comportamiento de "ancho de banda" de HQF + "detección aleatoria" + "cola regular":

Ejemplo:

policy-map TEST
 class 1
  bandwidth 32
  fair-queue 1024
  queue-limit 128
  random-detect

Igual que el ancho de banda y la cola justa en la sección, excepto el tamaño medio de cola WRED se calcula cada vez que llega un paquete para decidir si el paquete debe ser descartado aleatoriamente o descartado por la cola. Al igual que con el pre-HQF, todas las colas de flujo pueden compartir una instancia de umbrales WRED, lo que significa que todos los paquetes en cola para todas las colas de flujo se utilizan para calcular la profundidad media de cola WRED, luego la decisión de descartar aplica los umbrales mínimo y máximo WRED contra los paquetes agregados en todas las colas de flujo. Sin embargo, otra desviación del ancho de banda y de la cola justa en la sección, debido a que una instancia de umbrales WRED se aplica a todas las colas basadas en flujo, el límite de cola de las colas de flujo individuales (.25 * "queue-limit") se ignora y en su lugar respeta el límite de cola agregado de las clases para una verificación de Límite de cola actual.

Comportamiento predeterminado de clase

Comportamiento previo a HQF

En pre-HQF, Class Default tiene el valor predeterminado fair-queue, todas las colas de flujo comparten el límite de cola para la clase (el valor predeterminado es 64) y no hay reserva de ancho de banda. En otras palabras, el número total de paquetes en cola en todas las colas de flujo nunca puede exceder el límite de cola. La cantidad de paquetes en cola en cada cola de flujo puede depender del peso calculado de la cola de flujo. Por el contrario, si fair-queue y random-detect se utilizan juntos en class-default, queue-limit se puede ignorar y todas las colas de flujo pueden compartir los mismos umbrales WRED. Como tal, todos los paquetes actualmente en cola en todas las colas de flujo se pueden utilizar para calcular el tamaño medio de cola WRED. Debido a que el tamaño actual de la cola no tiene límite superior en esta configuración, la oportunidad de descartes sin búfer es alta (consulte el ID de bug de Cisco CSCsm94757).

• Si se agrega ancho de banda a class-default, puede producirse el comportamiento descrito en la sección Comportamiento previo a HQF - Clases definidas por el usuario configuradas con el comando "bandwidth".

• Si se agregan el ancho de banda y la detección aleatoria a la clase class-default, puede producirse el comportamiento descrito en la sección Comportamiento Pre-HQF "bandwidth" + "random-detect" de Comportamiento Pre-HQF - Clases Definidas por el Usuario Configuradas con el Comando "bandwidth".

Nota: En la fase previa a HQF, el ancho de banda no puede coexistir con fair-queue en class-default.

Comportamiento de HQF

En HQF, el valor predeterminado de la clase es una cola FIFO y se le asigna una reserva de pseudo ancho de banda basada en las asignaciones restantes de las clases definidas por el usuario. Por lo tanto, para el comportamiento predeterminado de clase de clase de HQF, vea la sección Comportamiento de HQF - Clases Definidas por el Usuario Configuradas con el Comando "bandwidth". En todo momento, independientemente de la configuración, la clase class-default en las imágenes HQF siempre puede tener una reserva de ancho de banda implícita igual al ancho de banda de interfaz sin utilizar que no consumen las clases definidas por el usuario. De forma predeterminada, la clase class-default recibe un mínimo del 1% del ancho de banda de la interfaz o de la forma principal. También es posible configurar explícitamente la CLI de ancho de banda en la clase predeterminada.

• Si fair-queue está configurado en class Class-Default, el comportamiento coincide con la sección de comportamiento HQF "bandwidth" + "fair-queue" de HQF Behavior - User Defined Classes Configurado con el Comando "bandwidth".

• Si fair-queue y random-detect se configuran juntos en Class-Default, el comportamiento coincide con la sección de comportamiento HQF "bandwidth" + "random-detect" + "fair-queue" de HQF Behavior - User Defined Classes Configuró con el Comando "bandwidth".

Información Relacionada

• Guía de Configuración de Soluciones de Calidad de Servicio de Cisco IOS, versión 12.2SR
• QoS: marco de cola jerárquico (HQF) [no compatible]
• Compatibilidad con routers
• Asistencia técnica y descargas de Cisco