Comprensión de los límites de cola y de las caídas de resultados en las Plataformas del Cisco IOS Software

Introducción

Este documento es aplicable a las plataformas del software solamente, que incluye generalmente la 3800 del 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:

• 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 el PRE-HQF: Routeres Cisco que funcionan con el Cisco IOS Software Release 12.3(26)

• Para el HQF: Routeres Cisco que funcionan 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.

Cartilla del Class-Based Weighted Fair Queueing

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 del HQF, las colas justas del flujo basado, configurables 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 el HQF, la prioridad de planificación de una cola basada clase se determina sobre la base del planificador de trabajos del 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 el CBWFQ se aplica a los límites de cola y a las caídas de resultados de comprensión.

Comprensión de los límites de cola y de las caídas de resultados

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 del 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 de la 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 se libera la interrupción de la recepció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 NON-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 del LLQ. Este mecanismo condicional del policing permite una cola de prioridad estricta sin permitir que el priority queue monopolice la interfaz entera 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 del PRE-HQF: NA

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

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

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

Comportamiento del HQF

Lo mismo que el 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 del HQF: 64 paquetes

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

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

• De la “justo-cola” del HQF la “prioridad” + comportamiento “al azar-detecta” +: El NA, ni justo-cola o al azar-detecta soportado en el 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>, el porcentaje de ancho de banda, y el porcentaje restante de ancho de banda del ancho de banda.

Comportamiento del 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 del PRE-HQF: 64 paquetes, armoniosos vía el cola-límite.

• El 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 buffer 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 de la interfaz CLI hacia fuera

  • ATMÓSFERA PVC: 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 (sub) (PRE-HQF): 1000 paquetes, armoniosos con los MAX-buffers 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 velocidad del reloj de la interfaz.

  Nota: En las imágenes del PRE-HQF, cuando una política de modelado basada clase se aplica a la interfaz (sub) a, guárdese de la velocidad de la interfaz física subyacente, como las interfaces <2Mbps omitirán una cola justa cargada y las interfaces >2Mbps omitirá el (Primero en Entrar, Primero en Salir FIFO). En el PRE-HQF, la cola de modelado alimentará la cola en espera de la interfaz, si la política de modelado está asociada en la subinterfaz 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 una 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 threshold WRED, envíe a la cola el paquete y libere la interrupción de la recepción.

  • Entre el minuto threshold 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 threshold WRED. Esto es un ejemplo gráfico:

    

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

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

• Nota: El WRED basado (predeterminado) y basado en DSCP de la Prioridad IP permite el minuto threshold, el máximo threshold, 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 ajustar 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 una oportunidad de expirar todos los buffers afectados un aparato a la cola basada clase que podría dar lugar a los descensos del ninguno-buffer que ocurrían dondequiera dentro de la cola justa basada clase (refiera al Id. de bug Cisco CSCsm94757).

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

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

Comportamiento del HQF

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

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

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

• El HQF “ancho de banda” + “al azar-detecta” 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 del HQF, al azar-detecte y el cola-límite puede coexistir en la misma clase definida por el usario (o el class class-default) y el cola-límite será habilitado y ajustado a 64 paquetes en una configuración predeterminada. 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-buffer discutidos en la sección correspondiente del PRE-HQF. Debido a esta adición, el límite de cola configurado debe ser por lo menos tan grande como el máximo threshold de la al azar-detección, donde el máximo threshold 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 threshold, 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 serán liberadas, y una eliminación de cola registrada. Recuerde, si el cola-límite está ajustado suficientemente arriba para agotar los buffers de espera del agregado para la cola basada en la clase, los descensos del ninguno-buffer puede todavía ocurrir. Los buffers de espera globales para el HQF se definen aquí:

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

  • ATMÓSFERA PVC: 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 del HQF: 1000 paquetes, armoniosos con una combinación de control-cola de la interfaz CLI hacia fuera y de cola-límite de la política hija donde el cola-límite de la política hija tiene un límite superior de control-cola de la interfaz hacia fuera.

  • Directiva de la modelación basada en la clase aplicada a la subinterfaz en el código del 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 velocidad del reloj de la 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 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 momento, se comienza el tráfico. La secuencia es NON-bursty en 400PPS, los marcos de xxx bytes compuesto 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 NON-bursty, la profundidad de cola promedio WRED igualará la profundidad de espera en cola actual, que es la conducta esperada.

• De la “justo-cola” del 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 del 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 cola de flujo 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 cola de flujo individual se registran como flowdrops. Si el número de colas de flujo era perceptiblemente alto al igual que el cola-límite, entonces otra oportunidad para el ninguno-buffer cae. Por ejemplo, la fijación-punta asumida de la directiva es una interfaz física, donde se afectan un aparato 1000 buffers 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 flujo puede morir de hambre los buffers y el resultado globales de la interfaz en los descensos del ninguno-buffer en otras clases definidas por el usario (véase el Id. de bug Cisco CSCsw98427). Esto es porque pueden 1024 colas de 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 de la interfaz 1000.

• De la “justo-cola” del 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 colas de flujo compartirán un caso de los umbrales WRED, significando todos los paquetes enviados a la cola a todas las colas de flujo 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 todas las colas de 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 colas de flujo 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 del PRE-HQF

En el PRE-HQF, el valor por defecto de la clase omite la justo-cola, todas las colas de flujo comparten el cola-límite para la clase (el valor por defecto es 64), y no hay reserva de ancho de banda. Es decir el número total de paquetes enviados a la cola en todas las colas de flujo nunca excederá el cola-límite. La cantidad de paquetes enviados a la cola en cada cola de flujo dependerá de la ponderación calculada de la cola de flujo. Inversamente, si la justo-cola y al azar-detecta se utiliza junta en el class-default, el cola-límite será ignorado y todas las colas de flujo compartirán los mismos umbrales WRED. Como tal, todos los paquetes enviados a la cola actualmente en todas las colas de flujo 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-buffer es alta (refiera al Id. de bug Cisco CSCsm94757).

• Agregar el ancho de banda al class-default dará lugar al comportamiento delineado en el comportamiento del 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 al class class-default dará lugar al comportamiento delineado en el PRE-HQF “ancho de banda” + “al azar-detectan” la sección del comportamiento del comportamiento del 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 class-default.

Comportamiento del HQF

En el 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 de ancho de banda basada en las asignaciones de sobra de las clases definidas por el usario. Como tal, para el comportamiento predeterminado del class class-default del HQF, vea el comportamiento del HQF - las clases definidas por el usario configuradas con el comando section del “ancho de banda”. Siempre, sin importar la configuración, el class class-default en las imágenes del HQF tendrá siempre una reserva de ancho de banda implícita igual al ancho de banda de la interfaz sin usar no consumido por las clases definidas por el usario. Por abandono, el clase class-default recibe un mínimo del 1% del ancho de banda de la dimensión de una variable de la 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 class class-default, el comportamiento hace juego de la “justo-cola” del HQF la sección del comportamiento del “ancho de banda” + del comportamiento del 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 class-default, el comportamiento hace juego de la “justo-cola” del HQF “ancho de banda” + la sección del comportamiento “al azar-la detecta” + del comportamiento del HQF - las clases definidas por el usario configuradas con el comando del “ancho de banda”.

Información Relacionada

• Soluciones guía de configuración de la Calidad de servicio de Cisco IOS, versión 12.4T
• QoS---Marco de espera jerárquico (HQF)
• Soporte de la Tecnología QoS
• Soporte de productos del Routers
• Soporte Técnico y Documentación - Cisco Systems