Comparación de la política de tráfico y la forma del tráfico para limitar el ancho de banda
Contenido
Introducción
Este documento describe las diferencias funcionales entre el modelado de tráfico y la regulación del tráfico, que limitan la velocidad de salida.
Prerequisites
Requirements
No hay requisitos específicos para este documento.
Convenciones
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. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
Este documento aclara las diferencias funcionales entre el modelado de tráfico y la regulación del tráfico. Ambos limitan funcionalmente la velocidad de salida del tráfico. Ambos mecanismos utilizan una cubeta con ficha como medidor de tráfico para medir la velocidad del paquete. Para obtener más información sobre las cubetas de token, vea ¿Qué es una cubeta de token?
Modelado versus regulación del tráfico
La regulación del tráfico propaga ráfagas. Cuando la velocidad del tráfico alcance la velocidad máxima configurada, el tráfico en exceso se suprime (o remarca). El resultado es una velocidad de salida que tiene la apariencia de un diente de sierra, con crestas y depresiones. A diferencia del establecimiento de políticas, el modelado del tráfico retiene los paquetes excedentes en una cola y luego programa dicho excedente para su posterior transmisión en incrementos de tiempo. El resultado del diseño del tráfico es una velocidad atenuada del paquete de salida.
El siguiente diagrama ilustra las diferencias clave entre las dos opciones de tráfico.
Políticas VS Shaping
A diferencia del establecimiento de políticas, el modelado implica la existencia de una cola y de memoria suficiente para almacenar en una memoria intermedia los paquetes con retraso. Las colas son un concepto de salida; los paquetes que salen de una interfaz se ponen en cola y se pueden modelar. Solamente se puede aplicar una regulación al tráfico entrante en una interfaz. Asegúrese de que dispone de memoria suficiente cuando habilite el modelado. Además, el modelado requiere una función que programe la transmisión posterior de cualquier paquete retrasado. Esta funcionalidad de programación permite organizar la cola de modelado en diferentes colas. Ejemplos de esta funcionalidad son Class Based Weighted Fair Queuing (CBWFQ) y baja latencia Queuing (LLQ).
Criterios de selección
La siguiente tabla enumera las diferencias entre el modelado y la regulación para ayudarlo a elegir la solución de tráfico apropiada.
| Modelado | Control de tráfico | |
|---|---|---|
| Objetivo | Almacene en la cola y almacene en el búfer los paquetes excedentes a las velocidades comprometidas. | Descartar (o remarcar) los paquetes en exceso sobre las velocidades comprometidas. No almacena en búfer. |
| Velocidad de actualización de token | Incrementada al inicio de un intervalo de tiempo. (Se requiere una cantidad mínima de intervalos). | Continua según la fórmula:1 / tasa de información comprometida |
| Valores Token | Configurado en bits por segundo | Configurados en bytes. |
| Opciones de Configuración |
|
|
| Aplicable en la entrada | No | Yes |
| Se aplica a la salida | Yes | Yes |
| Ráfagas | Controla las ráfagas y suaviza la velocidad de salida en al menos ocho intervalos de tiempo. Utiliza un contador dinámico para retardar el tráfico, el cual logra un efecto atenuante. | Propaga las ráfagas. No suaviza. |
| Ventajas | Es menos probable que los paquetes en exceso se descarten puesto que estos paquetes se almacenan en el buffer. (Paquetes de búferes hasta la longitud de la cola. Se pueden producir caídas si el tráfico excesivo se mantiene a altas velocidades.) Evita normalmente las retransmisiones debidas a paquetes descartados. | Controla la velocidad de salida a través de las caídas de los paquetes. Evita retrasos debido a queuing. |
| Desventajas | Puede introducir retraso debido a queuing, especialmente las colas profundas. |
Descarta los paquetes en exceso (cuando se configuran), limita los tamaños de las ventanas TCP y reduce la velocidad de salida general de los flujos de tráfico afectados. Los tamaños de ráfaga excesivamente agresivos pueden provocar caídas de paquetes excesivas y limitar la velocidad de salida general, especialmente con flujos basados en TCP. |
| Remarcación opcional de paquete | No | Sí (con la función CAR heredada). |
* Aunque la regulación de tráfico no aplica un búfer, un queuing El mecanismo se aplica a los paquetes conformados que pueden necesitar ser puestos en cola mientras esperan ser serializados en la interfaz física.
Velocidad de actualización de token
Una diferencia clave entre el modelado y la regulación es la velocidad a la que se reponen los tokens. Tanto el modelado como la regulación utilizan la metáfora de cubeta con tokens. Una cubeta con ficha no posee una política de prioridad o descarte.
Con funcionalidad de cubeta con ficha:
-
Los token ingresan al bloque de memoria a una velocidad determinada.
-
Cada token es un permiso para que el origen envíe cierto número de bits a la red.
-
Para enviar un paquete, el regulador del tráfico debe ser capaz de retirar de la cubeta una cantidad de fichas equivalente al tamaño del paquete.
-
Si no hay suficientes fichas en la cubeta como para enviar un paquete, el paquete espera hasta que la cubeta tenga suficientes fichas (en el caso de un modelador) o el paquete se descarta o se rebaja (en el caso de un vigilante).
-
La cubeta posee una capacidad especificada. Si la cubeta se llena hasta alcanzar su capacidad, los nuevos tokens que lleguen se descartan y no están disponibles para paquetes futuros. De esta manera, en cualquier momento, la ráfaga más grande que una fuente puede enviar a la red es más o menos proporcional al tamaño de la cubeta. Una cubeta con ficha permite la ráfaga pero la limita.
El modelado incrementa la cubeta con ficha a intervalos cronometrados que utilizan un valor de bits por segundo (bps). Un modelador utiliza la siguiente fórmula:
Tc = Bc/CIR (in seconds)
En esta ecuación, Bc representa la ráfaga comprometida y CIR representa la velocidad de información comprometida. (Vea Configuración del Modelado de Tráfico Frame Relay para obtener más información.) El valor de Tc define el intervalo de tiempo durante el cual se envían los bits de Bc para mantener la tasa promedio de CIR en segundos.
El rango para Tc es de 10 a 125 ms. Con el modelado de tráfico distribuido (DTS) en Cisco 7500 Series, el Tc mínimo es de 4 ms. El router calcula internamente este valor basándose en los valores de CIR y Bc. Si el valor de Bc/CIR es menor a 125 ms, utiliza el Tc que se calcula a partir de esa ecuación. Si Bc/CIR es mayor o igual a 125 ms, utiliza un valor Tc interno si Cisco IOS® determina que el flujo de tráfico puede ser más estable con un intervalo menor. Utilice el comando show traffic-shape para determinar si el router utiliza un valor interno para Tc o el valor configurado en la línea de comandos. El siguiente ejemplo de resultado del comando show traffic-shape se explica en los comandos show para el modelado de tráfico de Frame Relay.
show traffic output
Cuando la ráfaga en exceso (Be) se configura en un valor diferente de 0, el modelador permite que los tokens se almacenen en la cubeta, hasta el valor de Bc + Be. El valor más grande que la cubeta con fichas puede llegar a alcanzar es de Bc + Be y las fichas desbordadas se pierden. La única manera para tener más que fichas Bc en la cubeta es no utilizar todas las fichas Bc durante uno o más Tc. Dado que la cubeta con tokens vuelve a cargarse todos los Tc con tokens Bc, puede acumular tokens no utilizados para usarlos posteriormente hasta Bc + Be.
Por el contrario, la regulación basada en clases y lalimiting agrega tokens continuamente a la cubeta. Específicamente, la velocidad de llegada del token se calcula de la siguiente manera:
(time between packets<which is equal to t-t1>* policer rate)/8 bits per byte
En otras palabras, si la llegada anterior del paquete fue a t1 y la hora actual es t, la cubeta se actualiza con el valor de bytes de t-t1 basado en la velocidad de llegada del token. Tenga en cuenta que un regulador de tráfico utiliza valores de ráfaga especificados en bytes y que la fórmula anterior convierte de bits a bytes.
Este es un ejemplo que utiliza una CIR (o velocidad del regulador) de 8000 bps y una ráfaga normal de 1000 bytes:
Router(config)# policy-map police-setting Router(config-pmap)# class access-match Router(config-pmap-c)# police 8000 1000 conform-action transmit exceed-action drop
La cubeta con ficha se inicia completa a los 1000 bytes. Si llega un paquete de 450 bytes, éste se ajusta porque hay suficientes bytes en la cubeta de ficha. El paquete realiza la acción de conformidad (transmisión) y se eliminan 450 bytes de la cubeta con fichas (y se dejan 550 bytes). Si el siguiente paquete llega 0,25 segundos después, se agregan 250 bytes a la cubeta con ficha según la siguiente fórmula:
(0.25 * 8000)/8
El cálculo deja 700 bytes en la cubeta de tokens. Si el paquete siguiente es de 800 bytes, el paquete excede el límite y se ejecuta la acción para exceso (supresión). No se toman bytes de la cubeta con ficha.
Modelado de tráfico
Cisco IOS soporta los siguientes métodos de modelado de tráfico:
Todos los métodos de moldeado de tráfico son similares en cuanto a la implementación, aunque sus Interfaces de línea de comandos (CLI) difieren en cierta medida y usan diferentes tipos de colas para contener y moldear el tráfico que es postergado. Cisco recomienda el modelado basado en clases y el modelado distribuido, que se configuran con la CLI de QoS modular.
El siguiente diagrama ilustra cómo una política de QoS organiza el tráfico en clases y paquetes de colas que exceden las velocidades de modelado configuradas.
Regulación del tráfico
Cisco IOS soporta los siguientes métodos de regulación del tráfico:
Los dos mecanismos tienen importantes diferencias funcionales, como se explica en Comparar la regulación basada en clases y la tasa de acceso comprometida. Cisco recomienda políticas basadas en clase y otras funciones de la CLI de QoS modular cuando se aplican políticas de QoS.
Utilice el comando police para especificar que una clase de tráfico debe tener una velocidad máxima impuesta y, si se excede esa velocidad, se debe tomar una acción inmediata. En otras palabras, con el comando police no existe la opción de almacenar el paquete en el búfer y enviarlo más tarde, como sucede con el comando shape.
Además, con la regulación de tráfico, la cubeta con ficha determina si el paquete excede la velocidad aplicada o se ajusta a ella. En cualquier caso, la regulación del tráfico implementa una acción configurable, que incluye la precedencia IP o el punto de código de servicios diferenciados (DSCP).
El siguiente diagrama ilustra una aplicación común de regulación del tráfico en un punto de congestión, donde generalmente se aplican las características de QoS.
Controles de ancho de banda mínimo versus máximo
Los comandos shape y police, restringen la velocidad de salida a un valor máximo en kbps. Cabe destacar que ningún mecanismo provee una garantía de ancho de banda mínimo durante periodos de congestión. Utilice los comandos priority o bandwith para proveer tales garantías.
Una política jerárquica utiliza dos políticas de servicio: una política principal para aplicar un mecanismo QoS a un tráfico total y una política secundaria para aplicar un mecanismo QoS a un flujo o subconjunto del tráfico total. Las interfaces lógicas, como las subinterfaces y las interfaces de túnel, requieren una política jerárquica con el tráficolimiting función en el nivel principal y colas en niveles inferiores. El tráfico-limiting reduce la velocidad de salida y (presumiblemente) crea congestión, como lo ve queuing exceso de paquetes.
La siguiente configuración no es óptima y se muestra para ilustrar la diferencia entre el comando police frente al comando shape cuando limiting un tráfico agregado, en este caso class-default, a una velocidad máxima. En esta configuración, el comando police envía los paquetes de las clases secundarias basándose en el tamaño del paquete y el número de bytes que permanecen en las cubetas de tokens conformes y excedentes. (Vea Regulación del Tráfico.) El resultado es que las velocidades dadas a las clases de voz sobre IP (VoIP) y protocolo de Internet (IP) no se pueden garantizar ya que la función de policía invalida las garantías realizadas por la función de prioridad.
Sin embargo, si se utiliza el comando shape, el resultado es un sistema jerárquico de colocación de cola y se realizan todas las garantías. En otras palabras, cuando la carga ofrecida excede la velocidad modelada, a las clases de IP y VoIP se les garantiza su velocidad y el tráfico de clase predeterminada (en el nivel secundario) sufre las pérdidas.
class-map match-all IP
match ip precedence 3
class-map match-all VoIP
match ip precedence 5
policy-map child
class VoIP
priority 128
class IP
priority 1000
policy-map parent
class class-default
police 3300000 103000 103000 conform-action transmit exceed-action drop
service-policy child
Para que la configuración anterior tenga sentido, la regulación debe ser reemplazada por el modelado. Por ejemplo:
policy-map parent
class class-default
shape average 3300000 103000 0
service-policy child
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
2.0 |
26-Sep-2022 |
Recertificación |
1.0 |
15-Feb-2002 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)