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.

prerrequisitos

Requisitos

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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Resumen de diferencias

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

Además, diseñan a los comandos bandwidth and priority de lograr diversos objetivos de la política del Calidad de Servicio (QoS). Esta tabla enumera esos objetivos de diferenciación:

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 del ^{® del} Cisco IOS describen el comando bandwidth como la “cantidad de ancho de banda, en el kbps, de ser asignado a la clase. Para especificar o modificar el ancho de banda afectado un aparato para una clase que pertenece a una correspondencia de políticas.”

Observe el significado de estas definiciones.

El comando bandwidth garantiza un ancho de banda mínimo durante la congestión. Hay tres formas de la sintaxis de los comandos, 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 mínima del ancho de banda. Para implementar este comportamiento, no todas las plataformas de router de Cisco utilizan la cola equilibrada ponderada (WFQ) como el algoritmo subyacente. Para más información, refiérase a porqué el uso CBWFQ?.

Configuración del comando priority

Las guías de configuración del Cisco IOS describen el comando priority como reserva “de un priority queue con una determinada cantidad de ancho de banda disponible para el tráfico CBWFQ… para dar la prioridad a una clase de tráfico basada en la cantidad de ancho de banda disponible dentro de una política de tráfico.” A continuación, explicaremos el significado de estas definiciones.

Usted crea un priority queue con estos conjunto de comandos:

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. (Memoria que las garantías de ancho de banda son solamente un problema cuando se congestiona una interfaz.) Es decir el comando priority proporciona una garantía mínima del ancho de banda.

Además, el comando prioritario implementa una garantía de ancho de banda máximo. Internamente, el priority queue utiliza un token bucket que mida la carga ofrecida y se asegura de que el flujo de tráfico se ajusta a la velocidad configurada. Sólo el tráfico que se ajusta a la cubeta con fichas tiene garantizada la baja latencia. Se envía si el link no se congestiona o se cae cualquier tráfico en exceso si se congestiona el link. Para más información, refiérase a cuál es un token bucket?.

El propósito del vigilante incorporado es asegurarse de que las otras colas de administración del tráfico son mantenidas por el planificador de trabajos de espera. En la característica de colocación en cola de la prioridad original de Cisco, que utiliza los comandos priority-group and priority-list, el planificador de trabajos mantuvo siempre la cola más prioritaria primero. En casos extremos, las colas de menor prioridad se atendieron rara vez y, efectivamente, se las privó de ancho de banda.

El beneficio real del comando priority — y su diferencia principal del comando bandwidth — es cómo proporciona una prioridad del retiro estricto de la cola para proporcionar un límite en el tiempo de espera. La Guía de configuración del IOS de Cisco describe este beneficio de la siguiente manera: “Una cola de prioridad estricta (PQ) permite que envíans los datos sensibles al retardo tales como Voz de-sean hechos cola y antes de que los paquetes en otras colas de administración del tráfico de-se hagan cola.” Observemos lo que esto significa:

Cada interfaz del router mantiene estos dos conjuntos de las colas de administración del tráfico:

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 parada más reciente antes de los medios físicos.

En la siguiente figura, el anillo de transmisión ha sido configurado para sostener cuatro paquetes. Si tres paquetes están ya en el timbre, después en el mejor de los casos podemos hacer cola a la cuarta posición y después esperar los otros tres para vaciar. 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.

Utilice el comando tx-ring-limit de 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. Refiera al módulo de función del low latency queueing.

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 de-se hagan 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 más información, refiera a los consejos técnicos de la Calidad de voz.

Nota: Con los comandos both, el valor del kbps debe tomar en cuenta la capa 2 de arriba. Es decir si una garantía se hace a una clase, esa garantía está en cuanto a la producción de la capa 2. ¿Para más información, refiérase a qué bytes son contados haciendo cola del IP to ATM CoS? y porqué uso 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. Es decir si una clase de tráfico no está utilizando su configuré el ancho de banda, cualquier ancho de banda sin utilizar 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 cuando una clase de ancho de banda y una clase de prioridad pueden utilizar el ancho de banda en exceso:

Nota: Una excepción a estas guías de consulta para el LLQ es Frame Relay en el Cisco 7200 Router y otras Plataformas de la NON-ruta/del Procesador del switch (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. El Cisco IOS Software Release 12.2 quita esta excepción y se asegura de que los paquetes sin conformidad a normas están caídos solamente si hay congestión. Además, los paquetes más pequeños que un tamaño de fragmentación FRF.12 se envían no más con el proceso de fragmentación, reduciendo la utilización 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 colocación en cola distribuye cualquier ancho de banda restante. Aquí es cómo la descripción general de características del Class-Based Weighted Fair Queueing describe el mecanismo de asignación: “Si el ancho de banda en exceso está disponible, el ancho de banda en exceso se divide entre las clases de tráfico en proporción a sus configuré el ancho de banda. Si no todo el ancho de banda se afecta un aparato, el ancho de banda restante se afecta un aparato proporcional entre las clases, sobre la base de su configuré el ancho de banda.” 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 usted aplica esta directiva al link mbps del a1, significa que 300 kbps están garantizados a la clase BAR, y 600 kbps se garantizan a la clase BAZ. Importantemente, 100 kbps son de sobra para el class-default. 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 30:60 o 1:2.

La configuración de muestra siguiente contiene tres correspondencias de políticas — barra, baz, y poli. En la correspondencia de políticas llamada barra y la correspondencia de políticas llamada baz, el ancho de banda es especificado por el porcentaje. Sin embargo, en la correspondencia de políticas llamada poli, el ancho de banda se especifica en el kbps.

Recuerde que las correspondencias de la clase deben ser creadas ya antes de que usted cree las correspondencias 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: Presentaron al comando bandwidth remaining percent en la versión deL Cisco IOS 12.2(T). Refiera al low latency queueing con el soporte de porcentaje de prioridad para 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 velocidad máxima que sea siempre 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

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

Creamos este directiva-mapa nombrado 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 visualiza los “kilobites disponibles/sec del ancho de banda 1500.”

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

Miremos 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 son utilizados ya por la Voz y las clases de datos:

   4500000 - 3000000 = 1500000 bps
   

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

El máximo predeterminado del valor del ancho de banda reservable del 75 por ciento se diseña para dejar el ancho de banda suficiente para el tráfico de arriba, tal como actualizaciones del Routing Protocol y para acodar 2 Keepalives. 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. Usted ahora puede aumentar el valor máximo de ancho de banda reservable en el ATM PVC usando el comando max-reserved-bandwidth. Para las versiones del IOS soportadas y la información previa adicional, refiera a entender el comando max-reserved-bandwidth en el ATM PVC.

En el PVC de Frame Relay, los comandos bandwidth and priority calculan la cantidad total de ancho de banda disponible en una de estas 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 más información, refiera a configurar el CBWFQ en el PVC de Frame Relay.

Información Relacionada

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