Compare las políticas de tráfico y el modelado del tráfico para limitar el ancho de banda

Introducción

En este documento se describen las diferencias funcionales entre el modelado 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.

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

Los conceptos de este documento siguen siendo relevantes para comprender los diseños de Cisco QoS. El modelado del tráfico y la regulación del tráfico se siguen utilizando para aplicar las velocidades de tráfico máximas y gestionar la congestión. Para las nuevas implementaciones, Cisco recomienda utilizar modelado basado en clases de línea de comandos de QoS modular (MQC) y políticas basadas en clases cuando la plataforma lo admite. Los mecanismos heredados, como Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS), Committed Access Rate (CAR) y el comando rate-limit, se incluyen para el contexto histórico o para admitir discusiones específicas de la plataforma.

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 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 de tráfico	Regulación del tráfico
Comportamiento principal	Almacene en la cola y almacene en el búfer los paquetes excedentes a las velocidades comprometidas.	Descarta (o comenta) los paquetes excedentes sobre las velocidades comprometidas. No almacena en búfer.
Velocidad de actualización de token	Los tokens se reponen periódicamente en cada intervalo Tc. Al inicio de cada intervalo, el modelador agrega tokens Bc, hasta el límite de depósito configurado. Tc está limitado por límites específicos de la plataforma.	Los tokens se reponen en función del tiempo transcurrido entre la llegada de los paquetes. El regulador calcula el número de tokens a agregar con: ((t - t1) * policer_rate_bps) / 8, donde t - t1 es el tiempo desde el paquete anterior.
Valores Token	Configurado en bits por segundo (bps).	Configurados en bytes.
Opciones de Configuración	Comando Shape en MQC para implementar el modelado basado en clases. Frame-relay traffic-shape para implementar FRTS. Comando traffic-shape para implementar GTS.	Comando police en el MQC para implementar políticas basadas en clase. Comando Rate-limit para implementar CAR.
Dirección típica	Salientes	Entrante o saliente, dependiente de la plataforma
Ráfagas	Controla las ráfagas y suaviza la velocidad de salida en al menos ocho intervalos de tiempo. Utiliza medición de cubeta con ficha y pone en cola los paquetes excedentes. Los paquetes en cola se liberan con el tiempo, lo que crea un efecto de suavizado similar a una cubeta con fugas.	Permite ráfagas dentro de los límites de ráfaga configurados. No almacena en búfer los paquetes para suavizar la velocidad de transmisión.
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í, opcionalmente puede transmitir, descartar o marcar paquetes, incluidas las acciones de precedencia IP o DSCP, dependiendo de las acciones configuradas del regulador MQC y del soporte de la plataforma.

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 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: Ráfaga Comprometida. La cantidad de tráfico permitido para ser enviado durante un intervalo de tiempo.

• CIR: tasa de información comprometida. La velocidad de tráfico promedio que el formador o regulador aplica.

• Tc: Intervalo de tiempo confirmado. El intervalo de tiempo utilizado por un modelador para enviar la ráfaga confirmada mientras mantiene la CIR configurada en segundos.

El rango para Tc es de 10 a 125 ms. En algunas plataformas heredadas con Distributed Traffic Shaping (DTS), 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 el IOS de Cisco 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.

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 los tokens de reaprovisionamiento de limitación de velocidad se basan en el tiempo transcurrido entre las llegadas de paquetes. Cuando llega un paquete, el regulador calcula el número de tokens que se deben agregar desde el tiempo transcurrido desde el paquete anterior y la velocidad del regulador configurada. Específicamente, la velocidad de llegada del token se calcula de la siguiente manera:

Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes

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

1. El depósito comienza lleno:

   • Ráfaga normal =1000 bytes
   • Tokens iniciales =1000 bytes

2. Llega el primer paquete:

   • Tamaño de paquete =450 bytes
   • El paquete cumple porque la cubeta tiene suficientes tokens.
   • El regulador elimina de la cubeta 450 bytes de tokens.

   Cálculo: 1000 - 450 = quedan 550 bytes

3. El siguiente paquete llega 0,25 segundos después:

   • Velocidad del regulador = 8000 bps
   • Tokens agregados durante 0,25 segundos:

   (0,25 × 8000) / 8 = 250 bytes

4. Depósito después de la actualización:

   • Tokens existentes restantes =550 bytes
   • Nuevos tokens agregados =250 bytes

   Cálculo: 550 + 250 = 800 bytes

El cálculo deja 800 bytes en la cubeta con ficha (fichas que permanecen en la cubeta con regulador). Si el paquete siguiente es de 900 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 diferencias funcionales importantes, como se explica en Cómo Configurar la Regulación Basada en Clase. 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 limitan el tráfico a una velocidad máxima configurada. En MQC, la velocidad configurada para el promedio de forma y la regulación se especifica en bps a menos que la sintaxis específica de la plataforma indique lo contrario. 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 función de tráficolimiting en el nivel principal y colas en los niveles inferiores. La función de tráficolimiting 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 versus el 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

Utilice show policy-map interface <interface> para verificar las políticas configuradas, los contadores de clase, la velocidad ofrecida, los contadores de caídas, la velocidad de modelado, la profundidad de la cola y los contadores de conformidad/exceso/violación del regulador.

Router#show policy-map interface gigabitEthernet 0/0/2
 GigabitEthernet0/0/2 

 Service-policy output: parent 
    Class-map: class-default (match-any)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
 shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000 
 Service-policy : child 
        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: VoIP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 5 
 Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0           

        Class-map: IP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 3 
 Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0           

        Class-map: class-default (match-any)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

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

El ejemplo anterior es intencionalmente subóptimo y se proporciona sólo para ilustrar la diferencia entre la regulación y el modelado en una política de QoS jerárquica. En un diseño de QoS recomendado, el comando priority suele reservarse para el tráfico sensible a la latencia en tiempo real, como el de voz. Las clases no en tiempo real que requieren una garantía de ancho de banda mínimo utilizan comúnmente el comando bandwidth con CBWFQ.

Este enfoque se alinea con la guía de diseño de Cisco QoS para LLQ y CBWFQ. LLQ proporciona un tratamiento de prioridad estricta para el tráfico sensible a los retrasos, mientras que CBWFQ proporciona garantías de ancho de banda para otras clases de tráfico durante la congestión. Por lo tanto, la clase IP de este ejemplo se representa mejor con ancho de banda en lugar de con prioridad, a menos que esa clase transporte tráfico que explícitamente requiera un tratamiento de prioridad estricta.

policy-map child
 class VoIP
  priority 128
 class IP
  bandwidth 1000

Información Relacionada

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

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
6.0	21-Jul-2026	Recertificación.
4.0	07-Sep-2023	Actualización de requisitos de marca, SEO, gramática y formato.
3.0	26-Sep-2022	Recertificación
1.0	15-Feb-2002	Versión inicial