El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
En este documento se describe cómo bandwidth
y priority
los comandos se aplican en un policy-map de interfaz de línea de comandos de calidad de servicio modular.
No hay requisitos específicos para este documento.
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.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
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.
Esta tabla enumera las diferencias funcionales entre los bandwidth
y priority
comandos:
Función | bandwidthCommand | priorityCommand |
---|---|---|
Garantía de ancho de banda mínimo | Yes | Yes |
Garantía de ancho de banda máxima | No | Yes |
Vigilante incorporado | No | Yes |
Proporciona latencia baja | No | Yes |
Además, el bandwidth
Los comandos y priority están diseñados para cumplir diferentes objetivos de política de calidad de servicio (QoS). Esta tabla enumera los diferentes objetivos:
Aplicación | bandwidthCommand | priorityCommand |
---|---|---|
Administración del ancho de banda para los enlaces WAN | Yes | Algo |
Administrar el retraso y las variaciones en el retraso (fluctuación) | No | Yes |
Mejore el tiempo de respuesta de la aplicación. | No | Yes |
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.
Las guías de configuración de Cisco IOS ® describen la bandwidth
como la "cantidad de ancho de banda, en kbps, que se va a 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.
bandwidth
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:
Sintaxis del comando | Descripción |
---|---|
bandwidth {kbps} |
Especifica la asignación del ancho de banda en velocidad de bits. |
bandwidth percent {value} |
Especifica la asignación de ancho de banda como un porcentaje de la velocidad de link principal. |
bandwidth remaining percent {value} |
Especifica la asignación del ancho de banda como un porcentaje del ancho de banda que no se asignó a otras clases. |
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?
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
proporciona una garantía de ancho de banda mínimo.
Además, el priority
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 prioritaria original de Cisco, que utiliza la priority-group
y priority-list
, el planificador siempre atendió 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.
El beneficio real de la priority
y su principal diferencia con el comando bandwidth
comando: es la forma en que proporciona una prioridad de eliminación de cola estricta para proporcionar un límite en 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:
Cola | Ubicación | Métodos de almacenamiento en cola | Asignación de políticas de servicio | Comando a ajustar |
---|---|---|---|---|
Cola de hardware o anillo de transmisión | Adaptador de puerto o módulo de red | sólo FIFO | No | tx-ring-limit |
Cola de capa 3 | Sistema de procesamiento de capa 3 o memorias intermedias de interfaz | CBWFQ, LLQ, WFQ basado en flujos | Yes | Varía con el método para colocación en cola. Use el comando queue-limit con una clase de ancho de banda. |
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.
Use el comando tx-ring-limit
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.
Aunque las garantías de ancho de banda proporcionadas por el bandwidth
y priority
los comandos se han descrito con palabras como "reservado" y "ancho de banda a 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:
Comando | Congestión | Sin congestión |
---|---|---|
bandwidthCommand | Permitido para exceder la velocidad asignada. | Permitido para exceder la velocidad asignada. |
priorityCommand | El IOS de Cisco mide los paquetes y aplica un sistema de medición del tráfico por medio de una cubeta de ficha. Los paquetes que coinciden se regulan a la velocidad de bps configurada y se descartan todos los paquetes en exceso. | La clase puede exceder su ancho de banda configurado. |
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.
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.
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
con el comando police
comando. Esta configuración impone una frecuencia máxima que siempre está activa en la clase. La opción para configurar un police
en esta configuración depende del objetivo de la política.
En esta sección se explica cómo el sistema de envío a cola deriva el valor Ancho de banda disponible, como se muestra en la salida del show interface
or
show queueing
comandos.
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 el policy-map al PVC con el comando 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
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:
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
3000 Kbps ya son utilizados por las clases de voz y datos:
4500000 - 3000000 = 1500000 bps
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 máximo de ancho de banda reservable en los PVC ATM con el comando 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, el bandwidth
y priority
los comandos 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, max-reserved-bandwidth
El 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 la Capa 2. Para obtener más información, consulte Configuración de CBWFQ en PVC de Frame Relay.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
30-Aug-2023 |
Errores mecanográficos fijos. Recertificación. |
2.0 |
04-Apr-2023 |
Formato actualizado, CCW corregido. Recertificación. |
1.0 |
27-Nov-2001 |
Versión inicial |