Comprensión de los límites de cola y de los descensos de la salida en las plataformas del software del Cisco IOS

Introducción

Este documento es aplicable a las plataformas del software solamente, que incluye generalmente la 3800 de Cisco 7200VXR y de Cisco ISR, 2800 de Cisco IOS®, a los 1800 Series Router, así como a los routeres de acceso de Cisco de la herencia incluyendo 3700, 3600, 2600, y los 1700 Series Router.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Guía de configuración de las soluciones de la Calidad de servicio de Cisco IOS

• QoS---Marco de espera jerárquico (HQF)

Componentes Utilizados

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

• Para Pre-HQF: Routers de Cisco que funciona con el Cisco IOS Software Release 12.3(26)

• Para HQF: Routers de Cisco que funciona con el Cisco IOS Software Release 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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

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

Ponderada de asignación justa de ancho de banda en función de clase cartilla de espera

En las imágenes del IOS del pre-HQF, hablando en términos generales, cualquier clase con un comando bandwidth será dada prioridad generalmente contra las clases sin el ancho de banda o la prioridad basada en la ponderación de las clases. Para entender el algoritmo de programación del Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ), usted debe primero entender el concepto de una ponderación, que es flujo-específica para el específico basado flujo de las colas justas y de la clase para las colas de administración del tráfico basadas clase individual dentro de la cola justa cargada basada de la clase.

La fórmula para derivar la ponderación para una cola justa basada flujo es:

32384 / (IP Prec + 1)

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

En las imágenes HQF, las colas justas, configurables flujo-basada en ambas clases y valor por defecto definidos por el usario de la clase con la justo-cola, se programan igualmente (en vez de por peso). Además, en HQF, la prioridad de planificación de una cola basada clase es resuelta sobre la base del planificador de trabajos HQF y no en la fórmula de la ponderación de la herencia de las clases.

Nota: Esta sección no se piensa para ser un análisis del comportamiento completo para los funcionamientos de envío a cola basados clase. La intención es una educación abreviada pues CBWFQ se aplica a los límites de cola y a los descensos de comprensión de la salida.

Comprensión de los límites de cola y de los descensos de la salida

Clases definidas por el usario configuradas con el comando de la “prioridad”

Para las clases definidas por el usario MQC configuradas con cualquier variante del comando priority, incluyendo la prioridad, el <kbps> de la prioridad, y el por ciento de la prioridad.

Comportamiento de Pre-HQF

Técnico, aunque ningún CLI existe para verlo, y él no es configurable, una cola del sistema “ocultada” existe que es compartida por todos los datos de la clase de prioridad. Esto actúa como zona de espera para los datos de la prioridad después de que se haya clasificado y después de que ha sido permitida por el policer que reconoce la congestión. Los paquetes LLQ se colocan en esto cola del sistema “ocultada” si no pueden ser colocados directamente en el anillo de transmisión de la interfaz de egreso durante la interrupción de la recepción, que de otra manera se llama congestión funcional. En esta situación, porque existe la congestión funcional, el paquete se evalúa contra el policer condicional LLQ durante la interrupción de la recepción mientras que todavía es poseído por el driver del interfaz de recepción. Si el paquete no es caído por el policer condicional LLQ, se coloca en esto cola del sistema “ocultada” LLQ y la interrupción de la recepción release/versión. Por lo tanto, todos los paquetes colocados en esto cola del sistema “ocultada” se han ajustado al policer enterado de la congestión LLQ y dequeued al anillo de transmisión de la interfaz de egreso inmediatamente por el planificador de trabajos LLQ/CBWFQ.

A pesar de la existencia de esta cola, el comportamiento es colas de administración del tráfico desemejantes IOS creadas para los datos no--LLQ (tales como justo-cola y colas de ancho de banda) en que el tiempo de espera de espera no adicional (sobre el tiempo de espera del anillo de transmisión) será contraído puesto que los paquetes en esta cola serán drenados inmediatamente al anillo de transmisión por el planificador de trabajos LLQ/CBWFQ. Si un paquete de la clase de prioridad no es caído por el policer condicional durante la interrupción de la recepción, después este paquete LLQ existirá en esto cola del sistema “ocultada” abreviadamente antes de dequeueing al anillo de transmisión de la interfaz de egreso. En este caso, el planificador de trabajos LLQ/CBWFQ presentará inmediatamente el paquete al anillo de transmisión de la interfaz de egreso. El Policer condicional se ha ejecutado antes de admitir el paquete al LLQ/CBWFQ, de tal modo limitando el LLQ a la tarifa de la prioridad configurada.

En resumen, se recomienda para caer los datos LLQ que exceden la tarifa de la prioridad durante las épocas de la congestión que incurrir en el tiempo de espera de espera adicional, que es un componente fundamental de LLQ. Este mecanismo de vigilancia condicional permite una cola de prioridad estricta sin permitir que el priority queue monopolice el interfaz entero PLIM, que es una mejora sobre la característica de colocación en cola de la prioridad de la herencia IOS.

• Límite de cola de Pre-HQF: NA

• Pre-HQF “prioridad” + “al azar-detecta” el comportamiento: NA, WRED no permitido en LLQ.

• De la “justo-cola” de Pre-HQF comportamiento de la “prioridad” +: NA, justo-cola no permitida en LLQ.

• De la “justo-cola” de Pre-HQF la “prioridad” + comportamiento “al azar-detecta” +: El NA, ni justo-cola o al azar-detecta utilizado en LLQ.

Comportamiento HQF

Lo mismo que Pre-HQF excepto la cola ocultada se oculta no más y el cola-límite es configurables ahora y omite 64 paquetes.

• Límite de cola HQF: 64 paquetes

• HQF “prioridad” + “al azar-detectan” el comportamiento: NA, WRED no permitido en LLQ.

• De la “justo-cola” HQF comportamiento de la “prioridad” +: NA, justo-cola no permitida en LLQ.

• De la “justo-cola” HQF la “prioridad” + comportamiento “al azar-detecta” +: El NA, ni justo-cola o al azar-detecta utilizado en LLQ.

Clases definidas por el usario configuradas con el comando del “ancho de banda”

Para las clases definidas por el usario MQC configuradas con cualquier variante del comando bandwidth, incluyendo el <kbps> del ancho de banda, el por ciento del ancho de banda, y el por ciento restante del ancho de banda.

Comportamiento de Pre-HQF

El límite de cola predeterminado es 64 paquetes, que es armonioso. Si, durante la interrupción de la recepción, usted necesita enviar a la cola un paquete que daría lugar a > 64 paquetes en la cola, el paquete es cola caída.

• Cola-límite de Pre-HQF: 64 paquetes, armoniosos vía el cola-límite.

• Pre-HQF “ancho de banda” + “al azar-detecta” el comportamiento:

  Ejemplo:

  policy-map PRE_HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     random-detect

  Si cualquier variante del ancho de banda se configura junto con cualquier variante de al azar-detecte, ignore cualquier cola-límite CLI, que quite con eficacia cualquier límite de búfer en la clase. Es decir al azar-detecte y el cola-límite es mutuamente - exclusiva en las imágenes del pre-HQF. Usando al azar-detecte como estrategia del descenso, el tamaño de la cola actual es libre y puede ocupar teóricamente cada almacenador intermediario afectado un aparato a la justo-cola basada clase, donde esta cantidad de búfers afectada un aparato a la justo-cola basada clase se deriva basó en la punta de fijación de la servicio-directiva:

  • Interfaz física: 1000 paquetes, armoniosos con la control-cola del interfaz CLI hacia fuera

  • PVC ATMÓSFERA: 500 paquetes, armoniosos con la vc-control-cola PVC CLI

  • Map-class del Frame Relay: 600 paquetes, armoniosos con el holdq del Frame Relay del map-class CLI del Frame Relay

  • Directiva de la modelación basada en la clase aplicada al interfaz (sub) (pre-HQF): 1000 paquetes, armoniosos con los máximo-almacenadores intermediarios de la dimensión de una variable de la clase CLI MQC.

  Nota: Todo el Frame Relay y clase basados formando los ejemplos asumen que la suma de talladoras no excede la tarifa de reloj del interfaz.

  Nota: En las imágenes del pre-HQF, cuando una política de modelado basada clase se aplica al interfaz (sub) a, guárdese de la velocidad de la interfaz física subyacente, como los interfaces <2Mbps omitirán una cola justa cargada y los interfaces >2Mbps omitirá el primero en entrar, primero en salir. En el pre-HQF, la cola de modelado alimentará la cola en espera del interfaz, si la política de modelado está asociada en el subinterface o el nivel de interfaz física.

  Durante la interrupción de la recepción, cada vez que siente bien un paquete a un candidato a la cola de salida de un interfaz, el tamaño promedio de la cola WRED se calcula usando esta fórmula:

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

  Si es el tamaño promedio de la cola resultante:

  • Más pequeño que el minuto-umbral WRED, envíe a la cola el paquete y release/versión la interrupción de la recepción.

  • Entre el minuto-umbral WRED y el umbral máximo de WRED, caiga posiblemente el paquete con la probabilidad creciente como el tamaño promedio de la cola consigue más cercano al umbral máximo de WRED. Si el tamaño promedio de la cola es exactamente igual al umbral máximo de WRED, el paquete se cae según el denominador de probabilidad de la marca. El denominador de probabilidad de la marca también sirve como línea de fondo determinar qué porcentaje de paquetes conseguirá caído cuando el límite de la cola promedio no es exactamente igual al umbral máximo de WRED pero es más alto que el minuto-umbral WRED. Esto es un ejemplo gráfico:

    

    Si se cae el paquete, la interrupción de la recepción release/versión y se incrementa un descenso al azar. Si el paquete no se cae, se envía a la cola el paquete y la interrupción de la recepción release/versión.

  • Más arriba que el umbral máximo de WRED, caiga el paquete, release/versión la interrupción de la recepción, e incremente una eliminación de cola.

• Nota: WRED basados (valor por defecto) y basados en DSCP de la Prioridad IP permiten el minuto-umbral, el máximo-umbral, y el denominador de probabilidad de la marca que se definirá diferentemente para diversos valores. Aquí es donde está evidente el componente cargado de la detección temprana aleatoria. Usted puede proteger ciertos valores TOS en relación con otros valores vía la adaptación de sus umbrales relativos y marcar los denominadores de probabilidad.

  Cuando es al azar detecte y se configura junto el ancho de banda, el tamaño de la cola actual puede ser más grande que el umbral máximo de WRED en cualquier punta dada a tiempo. Esto es porque el mínimo de WRED y los umbrales máximos toman solamente medidas basadas en el tamaño de la cola (no actual) medio. Esto proporciona a una oportunidad de expirar todos los almacenadores intermediarios afectados un aparato a la cola basada clase que podría dar lugar a los descensos del ninguno-almacenador intermediario que ocurrían dondequiera dentro de la cola justa basada clase (refiera al ID de bug CSCsm94757 de Cisco).

• De la “justo-cola” de Pre-HQF comportamiento del “ancho de banda” +: NA, justo-cola no permitida en la clase de ancho de banda.

• De la “justo-cola” de Pre-HQF el “ancho de banda” + comportamiento “al azar-detecta” +: NA, justo-cola no permitida en la clase de ancho de banda

Comportamiento HQF

El comportamiento es lo mismo según lo descrito en la sección de Pre-HQF.

• Cola-límite HQF: 64 paquetes, armoniosos vía el cola-límite.

  Éste es lo mismo que ése en el pre-HQF.

• HQF “ancho de banda” + “al azar-detectan” el comportamiento:

  Ejemplo:

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

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

  El comportamiento es lo mismo que en la sección correspondiente del pre-HQF, con una excepción importante. En las imágenes HQF, al azar-detecte y el cola-límite puede coexistir en la misma clase definida por el usario (o el clase-valor por defecto de la clase) y el cola-límite será activado y adaptado a 64 paquetes en una configuración de valor por defecto. Como tal, el cola-límite servirá como tamaño de la cola actual máximo en una clase de la al azar-detección, por lo tanto proporcionando a un mecanismo para limitar los descensos del ninguno-almacenador intermediario discutidos en la sección correspondiente del pre-HQF. Debido a esta adición, el cola-límite configurado debe ser por lo menos tan grande como el máximo-umbral de la al azar-detección, donde el máximo-umbral de la al azar-detección omitirá 40 paquetes, o bien el analizador de sintaxis rechazará la configuración.

  Esto introduce las clases del incorporar un WRED del actual-cola-límite, por el que, incluso si el cálculo de la profundidad de cola promedio es más pequeño que el máximo-umbral, si el tamaño de la cola (no medio) actual es mayor que el cola-límite, el paquete será caído, la interrupción de la recepción release/versión, y una eliminación de cola registrada. Recuerde, si el cola-límite se adapta suficientemente arriba para agotar los almacenadores intermediarios de espera del agregado para la cola Clase-basada, los descensos del ninguno-almacenador intermediario puede todavía ocurrir. Los almacenadores intermediarios de espera globales para HQF se definen aquí:

  • Interfaz física: 1000 paquetes, armoniosos con la control-cola del interfaz CLI hacia fuera

  • PVC ATMÓSFERA: 500 paquetes, armoniosos con la vc-control-cola PVC CLI

  • Map-class del Frame Relay: 600 paquetes, armoniosos con el holdq del Frame Relay del map-class CLI del Frame Relay

  • Directiva de la modelación basada en la clase aplicada a la interfaz física en el código HQF: 1000 paquetes, armoniosos con una combinación de control-cola del interfaz CLI hacia fuera y de cola-límite de la directiva del niño donde el cola-límite de la directiva del niño tiene un límite superior de control-cola del interfaz hacia fuera.

  • Directiva de la modelación basada en la clase aplicada al subinterface en el código HQF: 512 paquetes, no armoniosos (investigue con el equipo de la plataforma NSSTG QoS, si es armonioso)

    Nota: Todo el Frame Relay y clase basados formando los ejemplos asumen que la suma de talladoras no excede la tarifa de reloj del interfaz.

    Aquí está un ejemplo del mundo real:

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

    Durante esta salida, no se está generando ningún tráfico a través del 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
    
    

    A este punto, se comienza el tráfico. La secuencia es no--bursty en 400PPS, los marcos compuesto del byte of1000:

    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

    Aviso cómo, eventual, con una secuencia no--bursty, la profundidad de cola promedio WRED igualará la profundidad de espera en cola actual, que es la conducta esperada.

• De la “justo-cola” HQF comportamiento del “ancho de banda” +:

  Cuando el ancho de banda y la justo-cola se aplican juntos a una clase definida por el usario HQF, cada cola basada en flujo se afecta un aparato un cola-límite igual a .25 * cola-límite. Porque el límite de cola predeterminado es 64 paquetes, cada cola basada flujo en una justo-cola será afectada un aparato 16 paquetes. Si cuatro flujos atravesaran esta clase, por abandono cada flujo-cola tendría 16 paquetes, por lo tanto usted nunca esperaba ver los totales de paquetes enviados a la cola de >64 (4 *16). Todas las eliminaciones de cola de una flujo-cola individual se registran como flowdrops. Si el número de flujo-colas de administración del tráfico era perceptiblemente alto al igual que el cola-límite, entonces otra oportunidad para el ninguno-almacenador intermediario cae. Por ejemplo, la fijación-punta asumida de la directiva es una interfaz física, donde se afectan un aparato 1000 almacenadores intermediarios globales:

  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 administración del tráfico del flujo puede morir de hambre los almacenadores intermediarios y el resultado globales del interfaz en los descensos del ninguno-almacenador intermediario en otras clases definidas por el usario (véase el ID de bug CSCsw98427 de Cisco). Esto es porque pueden 1024 colas de administración del tráfico del flujo, cada uno con un cola-límite de 32 paquetes fácilmente oversubscribe la Asignación de memoria intermedia de espera basada clase global del interfaz 1000.

• De la “justo-cola” HQF el “ancho de banda” + comportamiento “al azar-detecta” +:

  Ejemplo:

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

  Lo mismo que el ancho de banda y la justo-cola en la sección a menos que el tamaño promedio de la cola WRED se calcule cada vez un paquete llega para decidir a si el paquete debe ser haber caído al azar o cola caída. Como con el pre-HQF, todas las flujo-colas de administración del tráfico compartirán un caso de los umbrales WRED, significando todos los paquetes enviados a la cola a todas las flujo-colas de administración del tráfico se utilizan para calcular la profundidad de cola promedio WRED, después la decisión del descenso aplica el mínimo de WRED y los umbrales máximos contra los paquetes globales en todos las colas de administración del tráfico del flujo. Sin embargo, otra salida del ancho de banda y la justo-cola en la sección, porque un caso de los umbrales WRED se aplica a todas las colas basadas en flujo, el cola-límite de las flujo-colas de administración del tráfico individuales (.25 * “cola-límite ") se ignora y en lugar de otro honran el cola-límite global de las clases para un control de límite de cola actual.

Comportamiento predeterminado de la clase

Comportamiento de Pre-HQF

En el pre-HQF, el valor por defecto de la clase omite la justo-cola, todas las flujo-colas de administración del tráfico comparten el cola-límite para la clase (el valor por defecto es 64), y no hay reserva del ancho de banda. Es decir el número total de paquetes enviados a la cola en todas las flujo-colas de administración del tráfico nunca excederá el cola-límite. La cantidad de paquetes enviados a la cola en cada flujo-cola dependerá de la ponderación calculada de la flujo-cola. Inversamente, si la justo-cola y al azar-detecta se utiliza junta en el clase-valor por defecto, el cola-límite será ignorado y todas las flujo-colas de administración del tráfico compartirán los mismos umbrales WRED. Como tal, todos los paquetes enviados a la cola actualmente en todas las flujo-colas de administración del tráfico serán utilizados para calcular el tamaño promedio de la cola WRED. Porque el tamaño de la cola actual no tiene ningún límite superior en esta configuración, la oportunidad para los descensos del ninguno-almacenador intermediario es alta (refiera al ID de bug CSCsm94757 de Cisco).

• Agregar el clase-valor por defecto del ancho de banda dará lugar al comportamiento resumido en el comportamiento de Pre-HQF - las clases definidas por el usario configuradas con el comando section del “ancho de banda”.

• Agregando el ancho de banda y al azar-detecte para clasificar el clase-valor por defecto dará lugar al comportamiento resumido en el Pre-HQF “ancho de banda” + “al azar-detectan” la sección del comportamiento del comportamiento de Pre-HQF - las clases definidas por el usario configuradas con el comando del “ancho de banda”.

Nota: En el pre-HQF, el ancho de banda no puede coexistir con la justo-cola en el clase-valor por defecto.

Comportamiento HQF

En HQF, el valor por defecto de la clase omite una cola primero en entrar, primero en salir y se afecta un aparato una pseudo reserva del ancho de banda basada en las asignaciones de sobra de las clases definidas por el usario. Como tal, para el comportamiento predeterminado del clase-valor por defecto de la clase HQF, vea el comportamiento HQF - las clases definidas por el usario configuradas con el comando section del “ancho de banda”. Siempre, sin importar la configuración, el clase-valor por defecto de la clase en las imágenes HQF tendrá siempre una reserva implícita del ancho de banda igual al ancho de banda de la interfaz sin usar no consumido por las clases definidas por el usario. Por abandono, la clase del clase-valor por defecto recibe un mínimo del 1% del ancho de banda de la dimensión de una variable del interfaz o del padre. Es también posible configurar explícitamente el ancho de banda CLI en el valor por defecto de la clase.

• Si la justo-cola se configura en el Clase-valor por defecto de la clase, el comportamiento hace juego de la “justo-cola” HQF la sección del comportamiento del “ancho de banda” + del comportamiento HQF - las clases definidas por el usario configuradas con el comando del “ancho de banda”.

• Si la justo-cola y al azar-detecta se configura junta en el Clase-valor por defecto, el comportamiento hace juego de la “justo-cola” HQF “ancho de banda” + la sección del comportamiento “al azar-la detecta” + del comportamiento HQF - las clases definidas por el usario configuradas con el comando del “ancho de banda”.

Información Relacionada

• Guía de Configuración de Soluciones de Calidad de Servicio de Cisco IOS, versión 12.2SR
• QoS---Marco de espera jerárquico (HQF)
• Soporte de la Tecnología QoS
• Routers: soporte de productos
• Soporte Técnico y Documentación - Cisco Systems