Contenido

Introducción

Prerequisites

Requirements

Convenciones

Componentes Utilizados

Antecedentes

Modelado versus regulación del tráfico

Criterios de selección

Velocidad de actualización de token

Modelado de tráfico

Regulación del tráfico

Controles de ancho de banda mínimo versus máximo

Información Relacionada

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

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

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

- 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).

- t traffic-shape para implementar Generic Traffic Shaping (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 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:

- 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 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:

- Velocidad de acceso comprometida

- Control basado en clase

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.

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 QoS secundaria para clase de prioridad .

Información Relacionada

- Soporte de tecnología de calidad de servicio (QoS)

- Soporte Técnico y Documentación - Cisco Systems