Comparación de la política de tráfico y la forma del tráfico para limitar el ancho de banda

Introducción

Este documento describe las diferencias funcionales entre el modelado de tráfico y la regulación del tráfico, los cuales limitan la velocidad de salida.

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

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

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 formar. 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 le permite organizar la cola de modelado en diferentes colas. Algunos ejemplos de esta funcionalidad son Class Based Weighted Fair Queuing (CBWFQ) y Low Latency 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	Comando shape en la interfaz de línea de comandos (MQC) de calidad de servicio modular para implementar el modelado basado en clase. comando frame-relay traffic-shape para implementar el Modelado del tráfico de Frame Relay (FRTS). comando traffic-shape para implementar el Modelado de tráfico genérico (GTS).	Comando police en el MQC para implementar políticas basadas en clase. comando de límite de velocidad para implementar la velocidad de acceso comprometida (CAR).
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 los retrasos debidos a queuing.
Desventajas	Puede introducir retrasos 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 no aplica un búfer, un queuing mecanismo configurado se aplica a los paquetes conformados que deben ponerse en cola mientras esperan para serializarse en la interfaz física.

Velocidad de actualización de token

Una diferencia fundamental entre el modelado y la regulación es la velocidad a la que se recargan los tokens. Tanto el modelado como la regulación utilizan la metáfora de cubeta con ficha. Una cubeta con ficha no posee una política de prioridad o descarte.

Con la funcionalidad de cubeta con ficha: 

• Los token ingresan al bloque de memoria a una velocidad determinada.

• Cada token da permiso para que el origen envíe un determinado 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 tokens en la cubeta para enviar un paquete, el paquete espera hasta que la cubeta tenga suficientes tokens (en el caso de un modelador), o el paquete se descarta o se reduce (en el caso de un regulador).

• 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 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 la velocidad limiting añaden tokens de forma continua 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. 

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 

Las cubetas de token comienzan llenas a 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 admite los siguientes métodos de modelado de tráfico:

• Modelado del tráfico genérico

• Diseño del Frame Relay

• Modelado basado en clase y modelado distribuido basado en clase

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 pone en cola los paquetes que exceden las velocidades de modelado configuradas.

Regulación del tráfico

Cisco IOS admite los siguientes métodos de regulación del tráfico:

• Velocidad de acceso comprometida

• Control basado en clase

Los dos mecanismos tienen importantes diferencias funcionales, como se explica en Comparar la política basada en clases y la tasa de acceso comprometida. Cisco recomienda la regulación basada en clases y otras funciones de la CLI de QoS modular cuando se aplican las 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 de QoS a un agregado de tráfico y una política secundaria para aplicar un mecanismo de QoS a un flujo o subconjunto del agregado. Las interfaces lógicas, como las subinterfaces y las interfaces de túnel, requieren una política jerárquica con la limiting función de tráfico en el nivel principal y colas en los niveles inferiores. La limiting función de tráfico reduce la velocidad de salida y (presumiblemente) crea congestión, tal como la ven los paquetes en queuing exceso.

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 se agrega, 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 pueden garantizarse ya que la función de regulación anula las garantías ofrecidas 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.

Precaución: esta configuración no se recomienda y se muestra para ilustrar la diferencia entre el comando police versus el comando shape cuando limita un tráfico agregado.

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

Nota: Para obtener más información sobre las políticas primarias y secundarias, consulte Política de servicio secundario de QoS para la clase de prioridad .

Información Relacionada

• Soporte de tecnología de calidad de servicio (QoS)
• Soporte Técnico y Documentación - Cisco Systems