Introducción a los límites de cola y las caídas de salida en las plataformas de software del IOS de Cisco

Introducción

Este documento se aplica solamente a las plataformas de software Cisco IOS®, que generalmente incluye Cisco 7200VXR y Cisco ISR 3800, 2800, 1800 Series Routers, así como routers de acceso Cisco heredados incluidos 3700, 3600, 2600 y 1700.

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: marco de almacenamiento en cola 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 ejecutan Cisco IOS Software Release 12.3(26)

• Para HQF: Routers de Cisco que ejecutan Cisco IOS Software Release 12.4(22)T

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenciones

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

Manual de cola equilibrada ponderada basada en la clase

En las imágenes de IOS anteriores a HQF, en términos generales, cualquier clase con un comando bandwidth se priorizará generalmente frente a las clases sin ancho de banda o prioridad en función del peso de las clases. Para comprender el algoritmo de programación de cola equilibrada ponderada basada en clases (CBWFQ), primero debe entender el concepto de peso, que es específico para el flujo de colas justas basadas en flujos y específico de clase para colas basadas en clases individuales dentro de la cola equilibrada ponderada basada en clases.

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

32384 / (IP Prec + 1)

Las clases definidas por el usuario dentro de una cola Weighted Fair basada en clase derivan sus respectivos pesos como una función del comando bandwidth configurado en la clase como una proporción de la SUM de todas las clases de ancho de banda en la Cola Basada en Clase. La fórmula exacta es propietaria.

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

Nota: Esta sección no pretende ser un análisis de comportamiento completo para las operaciones de Colocación en Cola Basada en Clase. La intención es una breve educación ya que CBWFQ se aplica para entender los límites de cola y las caídas de salida.

Introducción a los límites de cola y las pérdidas de salida

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

Para las clases definidas por el usuario de MQC configuradas con cualquier variante del comando priority, incluyendo priority, priority <kbps> y priority percent.

Comportamiento previo a HQF

Técnicamente, aunque no existe una CLI para verla y no se puede configurar, existe una cola de sistema "oculta" que comparten todos los datos de clase de prioridad. Esto actúa como zona de espera para los datos prioritarios después de haber sido clasificados y después de haber sido permitida por el vigilante de la congestión. Los paquetes LLQ se colocan en esta cola de sistema "oculta" si no se pueden colocar directamente en el anillo de transmisión de la interfaz de egreso durante la interrupción de recepción, que de lo contrario 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 la interrupción de recepción mientras sigue siendo propiedad del controlador de la interfaz receptora. Si el regulador condicional de LLQ no descarta el paquete, se coloca en esta cola de sistema LLQ "oculta" y se libera la interrupción de recepción. Por lo tanto, todos los paquetes colocados en esta cola de sistema "oculta" se han ajustado al regulador de detección de congestión de LLQ y el planificador LLQ/CBWFQ los quitará 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 de IOS creadas para datos que no son de LLQ (como colas de ancho de banda y cola justa) en que no se producirá ninguna latencia de cola adicional (por encima de la latencia de anillo de transmisión), ya que los paquetes de esta cola serán arrastrados inmediatamente 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 existirá en esta cola del sistema "oculta" brevemente antes de quitarse la cola al anillo de transmisión de la interfaz de egreso. En este caso, el planificador LLQ/CBWFQ presentará inmediatamente el paquete al anillo de transmisión de la interfaz de egreso. El regulador condicional se ha ejecutado antes de admitir el paquete en LLQ/CBWFQ, limitando así el LLQ a la velocidad de prioridad configurada.

En resumen, se recomienda descartar los datos de LLQ que excedan la tasa de prioridad durante los tiempos de congestión en lugar de 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 sin permitir que la cola de prioridad monopolice la interfaz PLIM completa, lo que supone una mejora con respecto a la función heredada de almacenamiento en cola de prioridad del IOS.

• Límite de cola pre-HQF: NA

• Comportamiento pre-HQF "prioridad" + "detección aleatoria": No se permite WRED en LLQ.

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

• Comportamiento pre-HQF "prioridad" + "detección aleatoria" + "cola justa": NA, ni fair-queue ni random-detect soportados en LLQ.

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

• HQF "prioridad" + "detección aleatoria": No se permite WRED en LLQ.

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

• HQF "prioridad" + "detección aleatoria" + "cola justa" comportamiento: NA, ni fair-queue ni random-detect soportados en LLQ.

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

Para las clases definidas por el usuario de MQC configuradas con cualquier variante del comando bandwidth, incluido bandwidth <kbps> , bandwidth percent y bandwidth Restante%.

Comportamiento previo a HQF

El límite de cola predeterminado es 64 paquetes, que se pueden ajustar. Si, durante la interrupción de recepción, necesita poner en cola un paquete que resultaría en más de 64 paquetes en la cola, el paquete se descarta.

• Límite de cola previo a HQF: 64 paquetes, ajustables mediante queue-limit.

• Comportamiento pre-HQF "bandwidth" + "random-detect":

  Ejemplo:

  policy-map PRE_HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     random-detect

  Si se configura cualquier variante del ancho de banda junto con cualquier variante de random-detect, ignore cualquier CLI queue-limit, 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. Mediante el uso de random-detect como estrategia de descarte, el tamaño de cola actual no se limita y teóricamente puede ocupar cada búfer asignado a la cola justa basada en la clase, donde este número de búfers asignados a la cola justa basada en la clase se deriva en función del punto de adhesión de la política de servicio:

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

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

  • Clase de mapa de Frame Relay: 600 paquetes, ajustables con frame-relay map-class CLI frame-relay holdq

  • Política de modelado basada en clase aplicada a (sub)interfaz (anterior a HQF): 1000 paquetes, ajustables con memorias intermedias máx. de la CLI de la clase MQC.

  Nota: Todos los ejemplos de modelado basado en clases y Frame Relay asumen que la suma de los modeladores no excede la velocidad del reloj de la interfaz.

  Nota: En las imágenes anteriores a la HQF, cuando se aplica una política de modelado basado en clases a una (sub)interfaz, tenga cuidado con la velocidad de la interfaz física subyacente, ya que las interfaces <2 Mbps se establecerán de forma predeterminada en una cola equilibrada ponderada y las interfaces >2 Mbps se establecerán de forma predeterminada en FIFO. En el HQF previo, la cola de modelado alimentará la cola de retención de la interfaz, tanto si la política de modelado está conectada en la subinterfaz como en el nivel de interfaz física.

  Durante la interrupción de recepción, cada vez que un paquete se convierte en candidato para la cola de salida de una interfaz, el tamaño promedio de cola WRED se calcula usando 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 de WRED, coloque en cola el paquete y libere la interrupción de recepción.

  • Entre el umbral mínimo WRED y el umbral máximo WRED, posiblemente descarte el paquete con mayor probabilidad a medida que el tamaño promedio de cola se acerca al umbral máximo WRED. Si el tamaño promedio de cola es exactamente igual al umbral máximo de WRED, el paquete se descarta según el denominador de probabilidad de marca. El denominador de probabilidad de marca también sirve como línea de base para determinar qué porcentaje de paquetes se descartarán cuando el límite de cola promedio no es exactamente igual al umbral máximo de WRED sino que es superior al umbral mínimo de WRED. Este es un ejemplo gráfico:

    

    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, el paquete 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 caída de cola.

• Nota: El WRED basado en precedencia IP (predeterminado) y basado en DSCP permiten que el umbral mínimo, el umbral máximo y el denominador de probabilidad de marca se definan de manera diferente para los diferentes valores. Aquí es donde el componente Ponderado de Detección temprana aleatoria es evidente. Puede proteger ciertos valores de ToS relativos a otros valores mediante el ajuste de sus umbrales relativos y los denominadores de probabilidad de marca.

  Cuando se configura la detección aleatoria y el ancho de banda juntos, el tamaño de cola actual puede ser mayor que el umbral máximo de WRED en cualquier momento dado. Esto se debe a que los umbrales mínimo y máximo de WRED sólo toman medidas en función del tamaño de cola medio (no actual). Esto proporciona una oportunidad para vencer todos los búferes asignados a la Cola Basada en la Clase, lo que podría dar lugar a caídas sin búfer en cualquier lugar de la Cola Justa Basada en la Clase (consulte Cisco bug ID CSCsm94757).

• Comportamiento de "ancho de banda" y "cola justa" previo a HQF: NA, cola justa no permitida en clase de ancho de banda.

• Comportamiento pre-HQF "bandwidth" + "random-detect" + "fair-queue": NA, cola justa 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, ajustables mediante queue-limit.

  Esto es igual que en el pre-HQF.

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

  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 el mismo que en la sección anterior al HQF correspondiente, 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 clase predeterminada) y queue-limit se activará y ajustará a 64 paquetes en una configuración predeterminada. Como tal, queue-limit servirá como un tamaño máximo de cola actual en una clase de detección aleatoria, proporcionando por lo tanto un mecanismo para limitar las caídas sin búfer discutidas en la sección anterior al HQF correspondiente. 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 será predeterminado a 40 paquetes, o el analizador rechazará la configuración.

  Esto introduce una comprobación actual de límite de cola en las clases WRED, por la 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 medio) es mayor que el límite de cola, se descartará el paquete, se liberará la interrupción de recepción y se registrará una Caída de cola. Recuerde que si el límite de cola se ajusta lo suficientemente alto como para agotar los búfers de almacenamiento en cola agregados para la cola basada en clase, todavía pueden ocurrir caídas sin búfer. Los búfers de almacenamiento en cola agregado para HQF se definen aquí:

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

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

  • Clase de mapa de Frame Relay: 600 paquetes, ajustables con frame-relay map-class CLI frame-relay holdq

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

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

    Nota: Todos los ejemplos de modelado basado en clases y Frame Relay asumen que la suma de los modeladores no excede la velocidad del 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 está en ráfaga a 400 PPS, que 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, finalmente, con una secuencia sin ráfagas, la profundidad de cola promedio de WRED será igual a la profundidad de cola actual, que es el comportamiento esperado.

• Comportamiento HQF "bandwidth" + "fair-queue":

  Cuando el ancho de banda y la cola justa se aplican conjuntamente a una clase definida por el usuario de HQF, 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 64 paquetes, cada cola basada en flujo en una cola justa será asignada 16 paquetes. Si cuatro flujos atravesaran esta clase, de forma predeterminada cada cola de flujo tendría 16 paquetes, por lo que nunca esperaría ver el total de paquetes enviados a cola de >64 (4 *16). Todas las caídas de cola de una cola de flujo individual se registran como flujos. Si el número de colas de flujo era significativamente alto como lo era el límite de cola, entonces otra oportunidad para caídas sin búfer. Por ejemplo, suponiendo que el punto de conexión de la política es una interfaz física, donde se asignan 1000 búfers 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 dejar de generar memorias intermedias de interfaz agregada y dar lugar a caídas sin búfer en otras clases definidas por el usuario (consulte el ID de bug de Cisco CSCsw98427). Esto se debe a que las colas de flujo 1024, cada una con un límite de cola de 32 paquetes, pueden sobresuscribir fácilmente la asignación de búfer de cola basada en clase de la interfaz agregada 1000.

• HQF comportamiento "bandwidth" + "random-detect" + "fair-queue":

  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 WRED Promedio Tamaño de cola se calcula cada vez que llega un paquete para decidir si el paquete debe ser descartado aleatoriamente o si se debe descartar la cola. Al igual que con el pre-HQF, todas las colas de flujo compartirán una instancia de los umbrales WRED, lo que significa que todos los paquetes enviados a todas las colas de flujo se utilizan para calcular la Profundidad de cola promedio WRED, luego la decisión de descarte aplica los umbrales WRED mínimo y máximo contra los paquetes agregados en todas las colas de flujo. Sin embargo, otra salida del ancho de banda y la cola justa en la sección, porque una instancia de los 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, se honra el límite de cola agregado de clases para una verificación Límite de cola actual.

Comportamiento predeterminado de la clase

Comportamiento previo a HQF

En la cola anterior a HQF, la clase predeterminada es cola justa, 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 colocados en todas las colas de flujo nunca excederá el límite de cola. La cantidad de paquetes puestos en cola en cada cola de flujo dependerá del peso calculado de la cola de flujo. Por el contrario, si fair-queue y random-detect se utilizan juntos en class-default, el queue-limit será ignorado y todas las colas de flujo compartirán los mismos umbrales WRED. Como tal, todos los paquetes actualmente colocados en todas las colas de flujo se utilizarán para calcular el tamaño promedio de cola WRED. Debido a que el tamaño de cola actual no tiene límite superior en esta configuración, la oportunidad de descartes sin búfer es alta (consulte el ID de bug Cisco CSCsm94757).

• La adición de ancho de banda a class-default dará como resultado un comportamiento descrito en la sección Comportamiento Previo a HQF - Clases Definidas por el Usuario Configuradas con el Comando "bandwidth".

• La adición de ancho de banda y la detección aleatoria a la clase class-default dará como resultado un comportamiento descrito en la sección Pre-HQF "bandwidth" + "random-detect" del Comportamiento previo a HQF - Clases definidas por el usuario configuradas con el comando "bandwidth".

Nota: En la cola anterior a HQF, el ancho de banda no puede coexistir con cola justa en la clase predeterminada.

Comportamiento de HQF

En HQF, la clase predeterminada es una cola FIFO y se le asigna una reserva de pseudo ancho de banda basada en las asignaciones sobrantes de las clases definidas por el usuario. Como tal, para el comportamiento predeterminado de clase HQF, vea la sección Comportamiento 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 tendrá una reserva de ancho de banda implícita igual al ancho de banda de la interfaz sin usar 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 primaria. También es posible configurar explícitamente el ancho de banda CLI en la clase predeterminada.

• Si se configura fair-queue en la clase Class-Default, el comportamiento coincide con la sección HQF "bandwidth" + "fair-queue" del comportamiento 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 comportamiento de HQF "bandwidth" + "random-detect" + "fair-queue" de HQF Behavior - User Defined Classes Configurada 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 almacenamiento en cola jerárquico (HQF)
• Soporte de la Tecnología QoS
• Routers: soporte de productos
• Soporte Técnico y Documentación - Cisco Systems