Determinación de los comandos de ancho de banda y prioridad de una política de servicio de QoS

Introducción

Este documento describe cómo se aplican los comandos bandwidth   y priority en un policy-map de interfaz de línea de comandos de calidad de servicio modular.

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 un policy-map de interfaz de línea de comandos de calidad de servicio (MQC) modular, que luego se aplica a una interfaz, subinterfaz o circuito virtual (VC) a través del service-policy comando. 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 bandwidth  y priority están diseñados para cumplir diferentes objetivos de política de calidad de servicio (QoS). Esta tabla enumera los 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 reales tienen cuellos de botella de recursos y recursos limitados, y necesitan políticas de QoS para garantizar una asignación de recursos adecuada.

Configuración del comando Bandwidth

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

Observe el significado de estas definiciones.

El bandwidth  comando proporciona una garantía de 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. No todas las plataformas de router de Cisco utilizan weighted-fair queueing (WFQ) como algoritmo principal para implementar este comportamiento. Para obtener más información, consulte ¿Por qué utilizar CBWFQ?

Configuración del comando Priority

Las Guías de configuración de Cisco IOS describen el comando priority como una reserva para "una cola de prioridad con una cantidad especificada de ancho de banda disponible para el tráfico CBWFQ... para dar prioridad a una clase de tráfico basada en 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.

Puede crear una cola de prioridad con estos conjuntos 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. (Recuerde que las garantías de ancho de banda son solo un problema cuando una interfaz está congestionada). En otras palabras, el priority  comando proporciona una garantía de ancho de banda mínimo.

Además, el priority  comando 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 una cubeta 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 de Cisco original, que utiliza los comandos priority-group y priority-list , el planificador siempre atendió primero la cola de prioridad más alta. En casos extremos, las colas de menor prioridad se atendieron rara vez y, efectivamente, se las privó de ancho de banda.

La ventaja real del priority  comando, y su principal diferencia con el bandwidth  comando, es cómo proporciona una prioridad de eliminación de cola estricta para proporcionar un límite de latencia. La Guía de configuración de Cisco IOS describe esta ventaja de la siguiente manera: "Una cola de prioridad estricta (PQ) permite que los datos sensibles a los retrasos, como la voz, se puedan sacar de la cola y enviar antes de que los paquetes de otras colas se puedan sacar de la cola". Mira lo que esto significa.

Cada interfaz del router mantiene estos dos conjuntos de colas:

En la tabla anterior, podemos ver que una política de servicio se aplica solamente a los paquetes en la cola de Capa 3.

La eliminación estricta de la cola se refiere al programador de colocación en cola que atiende la cola de prioridad y reenvía sus paquetes al anillo de transmisión en primer lugar. El anillo de transmisión es la última parada antes de los medios físicos.

En la siguiente ilustración, el anillo de transmisión se ha configurado para contener 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.

Utilice el tx-ring-limit comando para ajustar el tamaño del anillo de transmisión a un valor no predeterminado. Cisco recomienda que ajuste el anillo de transmisión cuando transmita 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. Sólo una prioridad estricta funciona bien para la voz. A menos que los paquetes de voz sean inmediatamente quitados de la cola, cada salto puede introducir más demora.

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?

Aunque las garantías de ancho de banda proporcionadas por los comandos bandwidth  y priority  se han descrito con palabras como "reservado" y "ancho de banda para dejar de lado", ninguno de los comandos implementa una reserva verdadera. En otras palabras, si una clase de tráfico no utiliza su ancho de banda configurado, cualquier ancho de banda no utilizado se comparte entre las otras clases.

El sistema de envío a cola impone una excepción importante de clase prioritaria a esta regla. Como se mencionó anteriormente, la carga ofrecida de una clase de prioridad es medida por un 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 Cisco 7200 Router y otras plataformas que no son procesador de switch/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 la utilización de la CPU.

De la discusión anterior, es importante entender que dado que las clases de prioridad se controlan 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 no utilizada

Esta sección explica cómo el sistema de colas distribuye el ancho de banda restante. Así es como la Descripción General de la Función Class-Based Weighted Fair Queueing describe el mecanismo de asignación: "Si está disponible un ancho de banda excesivo, el ancho de banda excedente 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 proporción se comparte 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 los mapas de clase ya deben crearse antes de crear los mapas de política.

 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: El comando bandwidth remaining percent fue introducido en la versión 12.2(T) del IOS de Cisco.

Utilice el comando Police para establecer un máximo

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

Comprender 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 interface o show queueing   s.

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 policy-map al PVC con el service-policy output leslie comando.

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 Ancho de banda disponible 1500 kilobits/seg.

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% de este valor:

   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 y son clases de tráfico definidas o la clase class-default. Ahora puede aumentar el valor de ancho de banda máximo reservable en los PVC ATM con el max-reserved-bandwidth comando. Para ver las versiones de Cisco IOS soportadas y más información en segundo plano, consulte Comprensión del Comando max-reserved-bandwidth en ATM PVC.

En los PVC de Frame Relay, los comandos bandwidth y priority   calculan la cantidad total de ancho de banda disponible de 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. El ancho de banda completo de la velocidad anterior se puede asignar a las clases de ancho de banda y prioridad.

Por lo tanto, el max-reserved-bandwidth comando no se soporta en los PVC de Frame Relay, aunque debe asegurarse de que la cantidad de ancho de banda configurada sea lo suficientemente grande como para acomodar la sobrecarga de Capa 2. Para obtener más información, consulte Configuración de CBWFQ en PVC de Frame Relay.

Información Relacionada

• Soporte técnico y descargas de Cisco