Determinación de los comandos bandwidth y priority de una política de calidad de servicio (QoS)

Introducción

En este documento se describe cómo se aplican los comandos   y   en una asignación de políticas de interfaz de línea de comandos de calidad de servicio modular. bandwidth  priority

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Antecedentes

Los comandos bandwidth y priority definen acciones que se pueden aplicar dentro de una asignación de políticas de interfaz de línea de comandos de calidad de servicio modular (MQC), que luego se aplica a una interfaz, subinterfaz o circuito virtual (VC) mediante el comando . service-policy

Específicamente, estos comandos proporcionan una garantía de ancho de banda a los paquetes que coinciden con los criterios de una clase de tráfico. Sin embargo, los dos comandos cuentan con importantes diferencias funcionales en esas garantías.

Esta Nota Técnica describe esas diferencias y explica cómo el ancho de banda sin utilizar de una clase se distribuye a los flujos que coinciden con otras clases.

Resumen de diferencias

Esta tabla enumera las diferencias funcionales entre los comandos bandwidth y priority :

Además, los comandos  y priority están diseñados para cumplir con los diferentes objetivos de la política de calidad de servicio (QoS). bandwidth  En esta tabla se enumeran estos diferentes objetivos:

Incluso con interfaces rápidas, la mayoría de las redes aún necesitan un modelo de administración de Calidad de servicio (QoS) intensivo para encargarse de manera eficaz de los puntos de congestión y de los cuellos de botella que inevitablemente ocurren debido a una discrepancia de velocidad o a los patrones de tráfico distintos.

Las redes en el mundo real tienen recursos limitados y obstáculos de recursos por lo que necesitan políticas de QoS para asegurar la asignación correcta de recursos.

Configuración del comando bandwidth

En las Guías de configuración de Cisco IOS^® se describe el comando  como la "cantidad de ancho de banda, en kbps, que se asignará a la clase. bandwidth  . . para especificar o modificar el ancho de banda asignado a una clase que pertenece a una asignación de políticas".

Observe el significado de estas definiciones.

El comando  garantiza un ancho de banda mínimo durante la congestión. bandwidth  Existen tres formas de la sintaxis del comando, como se ilustra en esta tabla:

bandwidth {kbps}

bandwidth percent {value}

bandwidth remaining percent {value}

Nota: El comando bandwidth define un comportamiento, que es una garantía de ancho de banda mínimo. Para implementar este comportamiento, no todas las plataformas de router de Cisco usan    (WFQ) como el algoritmo principal. weighted-fair queueing Para obtener más información, consulte ¿Por qué usar CBWFQ?

Configuración del comando priority

En las Guías de configuración de Cisco IOS se describe el comando priority como reserva de "una cola de prioridad con una cantidad específica de ancho de banda disponible para el tráfico de CBWFQ… para dar prioridad a una clase de tráfico en función de la cantidad de ancho de banda disponible dentro de una política de tráfico".

En el siguiente ejemplo, se explica el significado de estas definiciones.

Se crea una cola de prioridades con los conjuntos de comandos siguientes:

Router(config)#policy-map policy-name
Router(config-pmap)#class class-name
Router(config-pmap-c)#priority kpbs [bytes]

En condiciones de congestión, la clase de tráfico es el ancho de banda garantizado igual a la velocidad especificada. (Recuerde que las garantías de ancho de banda son solo un problema cuando una interfaz está congestionada). En otras palabras, el comando  proporciona una garantía de ancho de banda mínimo. priority 

Además, el comando  implementa una garantía de ancho de banda máximo. priority  Internamente, la cola de prioridad usa un depósito de token que mide la carga ofrecida y garantiza que la transmisión de tráfico se ajuste a la tasa configurada.

Sólo el tráfico que se ajusta a la cubeta con fichas tiene garantizada la baja latencia. El tráfico excedente se envía si el enlace no está congestionado o se descarta si el enlace está congestionado. Para obtener más información, consulte ¿Qué es un depósito de tókenes?

El objetivo del regulador integrado es garantizar que el planificador de cola brinde servicios a las otras colas. En la función de cola de prioridades original de Cisco, que usa los comandos    y    , el planificador siempre prestaba servicios primero a la cola de mayor prioridad. priority-group priority-list

En casos extremos, las colas de menor prioridad se atendieron rara vez y, efectivamente, se las privó de ancho de banda.

La verdadera ventaja del comando  , y la principal diferencia del comando  , es cómo proporciona una estricta prioridad de eliminación de cola para brindar un límite de latencia. priority  bandwidth 

La Guía de configuración del IOS de Cisco describe este beneficio de la siguiente manera: "Una cola de prioridad (PQ) estricta permite que datos sensibles a retardos, como voz, se quiten de la cola y se envíen antes de que se quiten de la cola los paquetes en otras colas”.

Veamos lo que esto significa.

Cada interfaz del router mantiene estos dos conjuntos de colas:

En la tabla anterior se puede observar que la política de servicio se aplica solo a paquetes en la cola de capa 3.

La eliminación de la cola estricta se refiere al planificador de colas que presta servicio a la cola de prioridades y que primero reenvía sus paquetes al anillo de transmisión. El anillo de transmisión es la última parada antes de los medios físicos.

En la siguiente figura, el anillo de transmisión se configuró para sostener cuatro paquetes. Si ya hay tres paquetes en el arnillo, entonces, como máximo, podemos ponernos en la cuarta posición de la cola y esperar a que se vacíen los otros tres.

Luego, el mecanismo de Cola de tiempo de latencia bajo (LLQ) simplemente mueve los paquetes al extremo de la cola “primero en entrar, primero en salir” (FIFO) del nivel del controlador en el anillo de transmisión.

Use el comando  para ajustar el tamaño del anillo de transmisión a un valor no predeterminado. tx-ring-limit Cisco recomienda ajustar el anillo de transmisión cuando transmite tráfico de voz.

El establecimiento de la prioridad del tráfico tiene especial importancia para las aplicaciones interactivas basadas en transacciones y sensibles al retardo. A fin de minimizar el retardo y la fluctuación, los dispositivos de red deben poder prestar servicio a los paquetes de voz a medida que llegan o, en otras palabras, de manera estrictamente prioritaria. Solo una prioridad estricta funciona bien para la voz. A menos que los paquetes de voz se eliminen de la cola inmediatamente, cada salto puede generar más demoras.

La Unión de telecomunicaciones internacional (ITU) recomienda un retardo unidireccional de extremo a extremo máximo de 150 milisegundos. Sin una eliminación de cola inmediata en la interfaz del router, un único salto del router puede acarrear la mayor parte de este presupuesto de retardo. Para obtener más información, consulte Soporte de calidad de voz.

Nota: Con ambos comandos, el valor de kbps debe tener en cuenta la sobrecarga de Capa 2. Es decir, si se aplica una garantía a una clase, dicha garantía se relaciona con el rendimiento de la capa 2.

¿Qué clases de tráfico pueden utilizar ancho de banda en exceso?

Si bien las garantías de ancho de banda proporcionadas por los comandos  y  se describen con términos tales como "reservado" y "ancho de banda que se destinará", ninguno de los dos comandos implementa una verdadera reserva. bandwidth  priority  En otras palabras, si una clase de tráfico no usa su ancho de banda configurado, el ancho de banda sin usar se comparte entre las otras clases.

El sistema de envío a cola impone una excepción importante de clase prioritaria a esta regla. Tal como se observa arriba, la carga ofrecida de una clase de prioridades es medida por el regulador de tráfico. Durante condiciones de congestionamiento, una clase de prioridad no puede utilizar ningún ancho de banda en exceso.

Esta tabla describe cuándo una clase de ancho de banda y una clase de prioridad pueden usar el ancho de banda excedente:

Nota: Una excepción a estas pautas para LLQ es Frame Relay en el router Cisco 7200 y otras plataformas de procesador de switch/sin ruta (RSP). La implementación original de LLQ sobre Frame Relay en estas plataformas no permitía que las clases de prioridad excedieran la velocidad configurada durante periodos de no congestión. La versión 12.2 del software Cisco IOS remueve esta excepción y garantiza que los paquetes no conformes solo se descarten si hay congestión. Además, los paquetes más pequeños que un tamaño de fragmentación FRF.12 ya no se envían a través del proceso de fragmentación, lo que reduce el uso de la CPU.

A partir del debate anterior, es importante comprender que debido a que las clases de prioridades se regulan durante las condiciones de congestión, no se les asigna ningún ancho de banda restante de las clases de ancho de banda. Así, el remanente del ancho de banda es compartido por todas las clases de ancho de banda y clases predeterminadas.

Asignación de ancho de banda sin usar

Esta sección explica cómo el sistema de colas distribuye el ancho de banda restante. Aquí, la Descripción general de la función de cola equitativa y ponderada basada en clases describe el mecanismo de asignación:

"Si está disponible un ancho de banda en exceso, éste se divide entre las clases de tráfico en proporción a sus anchos de banda configurados. Si no se asigna todo el ancho de banda, la parte restante se asigna proporcionalmente entre las clases, según el ancho de banda que tienen configurado".

Observe dos ejemplos.

En el primer ejemplo, policy-map foo garantiza un 30 por ciento de ancho de banda para clase bar y un 60 por ciento para clase baz.

policy-map foo 
  class bar 
    bandwidth percent 30 
 class baz 
  bandwidth percent 60

Si aplica esta política a un enlace de 1 Mbps, significa que se garantizan 300 kbps para la clase BAR y 600 Kbps para la clase BAZ. Muy importante, se dejan 100 Kbps para la clase predeterminada.

Si la clase predeterminada no los necesita, los 100 kbps sin utilizar están disponibles para que los utilicen las clases BAR y BAZ.

Si ambas clases necesitan el ancho de banda, lo comparten en proporción a las velocidades configuradas. En esta configuración, la relación compartida es de 30:60 o 1:2.

La siguiente configuración de muestra contiene tres asignaciones de políticas: BAR, BAZ y POLI. En la asignación de políticas denominada BAR y en la denominada BAZ, el ancho de banda se especifica por porcentaje.

Sin embargo, en la asignación de políticas denominada POLI, el ancho de banda se especifica en kbps.

Recuerde que las asignaciones de clases ya deben haberse creado antes de que se creen las asignaciones de políticas.

 policy-map bar
  class voice
   priority percent 10
  class data
   bandwidth percent 30
  class video
   bandwidth percent 20
 policy-map baz
  class voice
   priority percent 10
  class data
   bandwidth remaining percent 30
  class video
   bandwidth remaining percent 20
 policy-map poli
  class voice
  class data
   bandwidth 30
  class video
   bandwidth 20

Nota: En la versión 12.2(T), se presentó el comando bandwidth remaining percent.

Uso del comando police para establecer un valor máximo

Si una clase de ancho de banda o de prioridades no debe exceder su ancho de banda asignado durante periodos en los que no hay congestión, puede combinar el comando con el comando   . priority police 

Esta configuración impone una frecuencia máxima que siempre está activa en la clase. La elección de configurar una declaración  en esta configuración depende del objetivo de la política. police 

Información sobre el valor de ancho de banda disponible

Esta sección explica cómo el sistema de colocación en cola deriva el valor de Ancho de banda disponible, como se muestra en la salida de los comandos show interfaceoshow queueing .

Hemos creado esta asignación de políticas llamada leslie:

7200-16#show policy-map leslie 
  Policy Map leslie 
    Class voice 
      Weighted Fair Queueing 
            Strict Priority 
            Bandwidth 1000 (kbps) Burst 25000 (Bytes) 
    Class data 
      Weighted Fair Queueing 
            Bandwidth 2000 (kbps) Max Threshold 64 (packets)

Luego, creamos un Circuito virtual permanente (PVC) ATM, lo asignamos a la categoría de servicio ATM de velocidad binaria variable en tiempo no real y configuramos una velocidad de celda sostenida de 6 Mbps. A continuación, aplicamos la asignación de políticas al circuito virtual permanente (PVC) mediante el comando  . service-policy output leslie

7200-16(config)#interface atm 4/0.10 point 
7200-16(config-subif)#pvc 0/101 
7200-16(config-if-atm-vc)#vbr-nrt 6000 6000 
7200-16(config-if-atm-vc)#service-policy output leslie

show queueing interface atm El comando   muestra Available Bandwidth 1500 kilobits/sec (Ancho de banda disponible 1500 kb/s). show queueing interface atm

7200-16#show queue interface atm 4/0.10 
  Interface ATM4/0.10 VC 0/101 
  queue strategy: weighted fair 
  Output queue: 0/512/64/0 (size/max total/threshold/drops) 
     Conversations  0/0/128 (active/max active/max total) 
     Reserved Conversations 1/1 (allocated/max allocated) 
     Available Bandwidth 1500 kilobits/sec

Observemos cómo se deriva este valor:

1. 6 Mbps es la velocidad de célula sostenida (SCR). De forma predeterminada, se puede reservar el 75 %:

   0.75 * 6000000 = 4500000
   

2. 3000 Kbps ya son utilizados por las clases de voz y datos:

   4500000 - 3000000 = 1500000 bps
   

3. El ancho de banda disponible es de 1500000 bps.

El máximo valor predeterminado del ancho de banda de reserva del 75 por ciento está diseñado para dejar suficiente ancho de banda para el tráfico de sobrecarga, como las actualizaciones del protocolo de routing y los keepalives de capa 2.

También abarca la sobrecarga de la capa 2 para los paquetes que coinciden con las clases de tráfico definidas o con la clase predeterminada. Ahora, puede aumentar el valor máximo de ancho de banda de reserva en los PVC del modo de transferencia asíncrona (ATM, asynchronous transfer mode) con el comando  . max-reserved-bandwidth

Para ver los lanzamientos de Cisco IOS compatibles y obtener información general adicional, consulte Información del comando max-reserved-bandwidth en los PVC del ATM.

En los PVC de Frame Relay, los comandos  y    calculan la cantidad total de ancho de banda disponible de una de las siguientes maneras: bandwidth priority

• Si no se configura una Velocidad de la información comprometida (minCIR) mínima aceptable, la CIR se divide en dos.

• Si hay un minCIR configurado, la configuración de minCIR se usará en el cálculo. Todo el ancho de banda de la velocidad anterior puede asignarse a clases de ancho de banda y de prioridades.

De este modo, el comando    no es compatible con los PVC de Frame Relay, aunque debe asegurarse de que la cantidad de ancho de banda configurada sea suficiente para adaptar la sobrecarga de la capa 2. max-reserved-bandwidth Para obtener más información, consulte Configuración de CBWFQ en los PVC de Frame Relay.

Información Relacionada

• Soporte técnico y descargas de Cisco