Comparación de los comandos bandwidth y priority de una política de servicio de QoS

Introducción

Los comandos bandwidth y priority definen las acciones que se pueden aplicar dentro de una correspondencia de políticas de la Interfaz de línea de comando de calidad de servicio modular (MQC), que 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.

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.

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

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

Resumen de diferencias

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

Además, los comandos bandwidth y priority están diseñados para cumplir con los diferentes objetivos de la política de calidad de servicio (QoS). Esta tabla enumera 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 poseen recursos limitados y cuellos de botella de recursos por lo que necesitan políticas de QoS para asegurar la asignación correcta de recursos.

Configuración del comando bandwidth

Las guías de configuración de Cisco IOS^® describen el comando bandwidth como la "cantidad de ancho de banda, en kbps, que se asignará a la clase. . . .Para especificar o modificar el ancho de banda asignado a una clase que pertenece a un policy map."

Observe el significado de estas definiciones.

El comando bandwidth garantiza un ancho de banda mínimo durante la congestión. 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 utilizan la cola equilibrada ponderada (WFQ) como el algoritmo subyacente. Para obtener más información, consulte ¿Por qué usar CBWFQ?.

Configuración del comando priority

Las Guías de configuración de Cisco IOS describen 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". A continuación, explicaremos el significado de estas definiciones.

Se crea una cola prioritaria con el conjunto de comandos siguiente:

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 priority proporciona una garantía de ancho de banda mínimo.

Además, el comando prioritario implementa una garantía de ancho de banda máximo. 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 token?.

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 prioridad original de Cisco, que usa los comandos priority-group y priority-list, el planificador siempre prestaba servicios primero a la cola de mayor prioridad. 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 priority, y la principal diferencia del comando bandwidth, es cómo proporciona una prioridad estricta para quitar de la cola para ofrecer un límite de latencia. 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”. Observemos 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 sólo 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 prioritaria 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 ha sido configurado 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 tx-ring-limit para ajustar el tamaño del anillo de transmisión a un valor no predeterminado. Cisco recomienda ajustar el anillo de transmisión al transmitir tráfico de voz. Consulte el Módulo de la función de cola de latencia baja.

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. Nada que carezca de prioridad estricta funciona bien para la voz. A menos que los paquetes de voz se quiten de la cola inmediatamente, cada salto introducirá más retardo.

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 las Sugerencias técnicas 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. Para obtener más información, consulte ¿Qué bytes se cuentan por IP para la cola de ATM CoS? y ¿Por qué usar LLQ?.

¿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 bandwidth y priority se han descrito con palabras tales como "reservado" y "ancho de banda a destinarse", ninguno de los dos comandos implementa una verdadera reserva. 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 prioridad 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 directrices para LLQ es Frame Relay en el router Cisco 7200 y en otras plataformas que no sean Route/Switch Processor (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 de 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 dado que las clases de prioridad son reguladas durante 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.

¿Cómo es asignado el ancho de banda sin utilizar?

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". Veamos 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 de USO compartido 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 deberían 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: Se introdujo el comando bandwidth other percent en la versión 12.2(T) del IOS de Cisco. Consulte Cola de baja latencia con soporte de porcentaje de prioridad para obtener una descripción detallada del comando bandwidth.

Uso del comando police para establecer un valor máximo

Si una clase de ancho de banda o de prioridad no debe exceder su ancho de banda asignado durante periodos en los que no hay congestión, puede combinar el comando priority con el comando police. Esta configuración impone una frecuencia máxima que siempre está activa en la clase. La elección de configurar una sentencia de regulación del tráfico en esta configuración depende del objetivo de la política.

Información sobre el valor de ancho de banda disponible

En esta sección, se explica cómo el sistema de cola obtiene el valor de ancho de banda disponible, como se muestra en el resultado de los comandos show interface o show queuing.

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. Luego aplicamos el mapa de políticas al 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

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

7200-16# show queueing interface atm 4/0.10 
  Interface ATM4/0.10 VC 0/101 
  Queueing 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 manera predeterminada, el 75 por ciento es reservable:

   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 cubre 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 de ATM con el comando max-reserved-bandwidth. Para ver las versiones de IOS admitidas y obtener información general adicional, consulte Comprensión del comando max-reserved-bandwidth en los PVC de ATM.

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

• 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 del índice anterior puede ser asignado a clases de ancho de banda y de prioridad.

De este modo, el comando max-reserved-bandwidth no es admitido en los PVC de Frame Relay, aunque debería asegurarse de que la cantidad de ancho de banda configurada sea suficiente para acomodar la sobrecarga de la Capa 2. Para obtener más información, consulte Configuración de CBWFQ en PVC de Frame Relay.

Información Relacionada

• Página de Soporte de Qos (Calidad de Servicio)
• Soporte Técnico y Documentación - Cisco Systems