Comparar a vigilância de tráfego e a modelagem de tráfego para limitar a largura de banda

Introdução

Este documento descreve as diferenças funcionais entre a modelagem de tráfego e a fiscalização de tráfego, as quais limitam a taxa de saída.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Este documento esclarece as diferenças funcionais entre modelagem de tráfego e vigilância. Ambas limitam funcionalmente a taxa de saída de tráfego. Ambos os mecanismos usam um token bucket como medidor de tráfego para medir a taxa de pacotes. Para obter mais informações sobre token buckets, consulte O que é um token bucket

Os conceitos neste documento permanecem relevantes para a compreensão dos projetos de QoS da Cisco. A modelagem de tráfego e a vigilância de tráfego continuam a ser usadas para aplicar taxas de tráfego máximas e gerenciar o congestionamento. Para novas implantações, a Cisco recomenda o uso de modelagem baseada em classe e de política baseada em classe de MQC (Modular QoS Command-Line) quando suportado pela plataforma. Mecanismos legados, como Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS), Committed Access Rate (CAR) e o comando rate-limit, são incluídos para contexto histórico ou para suportar discussões específicas da plataforma.

Vigilância versus modelagem

A política de tráfego propaga os bursts. Quando a taxa de tráfego atinge a taxa máxima configurada, o tráfego de excesso é liberado (ou remarcado). O resultado é uma taxa de saída que aparece como um dente de serra com picos e depressões. Em contraste com a vigilância, a modelagem de tráfego retém pacotes em excesso em uma fila e agenda o excesso para transmissão posterior de acordo com incrementos de tempo. O resultado da modelagem de tráfego é uma taxa de saída de pacote facilitada.

O próximo diagrama ilustra as principais diferenças entre as duas opções de tráfego.

Vigilância VS Modelagem

A modelagem implica na existência de uma fila e de memória suficiente para armazenar os pacotes com retardo em buffer, diferente da vigilância. As filas são um conceito de saída; os pacotes que saem de uma interface são enfileirados e podem ser moldados. Somente a política pode ser aplicada ao tráfego de entrada em uma interface. Certifique-se de ter memória suficiente ao habilitar a modelagem. Além disso, a modelagem requer uma função que programe a transmissão posterior de qualquer pacote atrasado. Essa funcionalidade de agendamento permite organizar a fila de modelagem em filas diferentes. Exemplos dessa funcionalidade são Class Based Weighted Fair Queuing (CBWFQ) e Low Latency Queuing (LLQ).

Critérios de seleção

A tabela a seguir lista as diferenças entre modelagem e vigilância para ajudá-lo a escolher a solução de tráfego apropriada.

	Modelagem de tráfego	Políticas de tráfego
Comportamento principal	Armazene em buffer e enfileire pacotes em excesso nas taxas comprometidas.	Descarta (ou comenta) pacotes em excesso sobre as taxas confirmadas. Não é possível armazenar em buffer.*
Taxa de atualização de token	Os tokens são reabastecidos periodicamente em cada intervalo Tc. No início de cada intervalo, o modelador adiciona tokens Bc, até o limite de bucket configurado. O Tc é restringido por limites específicos da plataforma.	Os tokens são reabastecidos com base no tempo decorrido entre as chegadas de pacotes. O vigilante calcula o número de tokens a serem adicionados com: ((t - t1) * policer_rate_bps) / 8, onde t - t1 é o tempo desde o pacote anterior.
Valores de token	Configurado em bits por segundo (bps).	Configurado em bytes.
Opções de configuração	Comando Shape no MQC para implementar modelagem baseada em classe. Comando frame-relay traffic-shape para implementar o FRTS. Traffic-shape para implementar GTS.	Comando police no MQC para implementar a vigilância baseada em classe. Comando rate-limit para implementar o CAR.
Direção típica	Saída	Entrada ou saída, dependente da plataforma
Intermitências	Controla rajadas e suaviza a taxa de saída em pelo menos oito intervalos de tempo. Ele usa medição de token bucket e enfileira pacotes em excesso. Os pacotes enfileirados são liberados ao longo do tempo, o que cria um efeito de suavização semelhante a um leaky bucket.	Permite bursts dentro dos limites de burst configurados. Ele não armazena pacotes em buffer para suavizar a taxa de transmissão.
Vantagens	Menor probabilidade de descartar pacotes em excesso, visto que estes sofrem buffer. (Pacotes de buffer até o comprimento da fila. Poderão ocorrer quedas se o excesso de tráfego for mantido em altas taxas.) Normalmente evita retransmissões devido a pacotes descartados.	Controla a taxa de saída por meio do cancelamento de pacotes. Evita atrasos devidos a queuing.
Desvantagens	Pode introduzir atraso devido a filas queuingparticularmente profundas.	Descarta pacotes em excesso (quando configurados), tamanhos de janela TCP acelerados e reduz a taxa de saída geral dos fluxos de tráfego afetados. Tamanhos de burst excessivamente agressivos podem levar a quedas de pacotes em excesso e acelerar a taxa de saída geral, particularmente com fluxos baseados em TCP.
Remarcação de Pacote Opcional	No	Sim, ele pode, opcionalmente, transmitir, descartar ou marcar pacotes, incluindo precedência de IP ou ações de DSCP, dependendo das ações do vigilante MQC configurado e do suporte à plataforma.

Taxa de atualização de token

Uma diferença importante entre modelagem e vigilância é a taxa na qual os tokens são reabastecidos. Tanto a modelagem quanto a vigilância usam a metáfora do token bucket. Um token bucket propriamente dito não possui política de descarte ou prioridade.

Com funcionalidade de token bucket: 

• Os tokens são colocados em um bucket a uma certa taxa.

• Cada token dá permissão para que a origem envie um determinado número de bits para a rede.

• Para enviar um pacote, o regulador de tráfego deve estar apto a remover do bucket um número de símbolos que seja igual em representação ao tamanho do bucket.

• Se não houver tokens suficientes no bucket para enviar um pacote, o pacote esperará até que o bucket tenha tokens suficientes (no caso de um modelador) ou o pacote será descartado ou marcado (no caso de um vigilante).

• O bucket propriamente dito possui uma capacidade específica. Se o bucket for preenchido até a capacidade máxima, os novos tokens que chegarem serão descartados e não estarão disponíveis para pacotes futuros. Assim, a qualquer momento, o maior surto que uma origem pode enviar na rede é proporcional ao tamanho do pacote. Um token bucket permite intermitência, mas a limita.

A modelagem incrementa o token bucket em intervalos programados que usam um valor de bits por segundo (bps). Um modelador usa a próxima fórmula:

Tc = Bc/CIR (in seconds)

Nesta equação:

• Bc: Intermitência confirmada. A quantidade de tráfego permitida para envio durante um intervalo de tempo.

• CIR: Taxa de informações confirmadas. A taxa média de tráfego que o modelador ou o vigilante impõe.

• Tc: Intervalo de tempo confirmado. O intervalo de tempo usado por um modelador para enviar a intermitência confirmada enquanto mantém a CIR configurada em segundos.

O intervalo de Tc é entre 10 ms e 125 ms. Em algumas plataformas antigas com Distributed Traffic Shaping (DTS), o Tc mínimo é de 4 ms. O roteador calcula internamente esse valor com base nos valores da CIR e do Bc. Se Bc/CIR for menor que 125 ms, ele utiliza o Tc calculado a partir daquela equação. Se o Bc/CIR for maior ou igual a 125 ms, ele usará um valor de Tc interno se o Cisco IOS determinar que o fluxo de tráfego pode ser mais estável com um intervalo menor. Use o comando show traffic-shape para determinar se o roteador usa um valor interno para Tc ou o valor que você configurou na linha de comando.

show traffic output

Quando o excesso de burst (Be, excess burst) é configurado para um valor diferente de 0, o modelador permite que os tokens sejam armazenados no bucket até Bc + Be. O maior valor que o token bucket pode alcançar é Bc + Be, e os tokens de sobrefluxo são descartados. A única maneira de ter mais tokens Bc no bucket é não utilizar todos os tokens Bc durante um ou mais Tcs. Como o token bucket é repovoado a cada Tc com tokens Bc, é possível acumular tokens não utilizados para uso posterior em Bc + Be.

Em contraste, a vigilância baseada em classe e os tokens de reposição de limitação de taxa com base no tempo decorrido entre as chegadas de pacotes. Quando um pacote chega, o vigilante calcula o número de tokens a serem adicionados a partir do tempo desde o pacote anterior e a taxa de vigilante configurada. Especificamente, a taxa de chegada do token é calculada da seguinte maneira:

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

Em outras palavras, se a chegada anterior do pacote é t1 e o horário atual é t, o bucket é atualizado com o valor de bytes de t-t1 com base na taxa de chegada do token. 

Este é um exemplo que usa uma CIR (ou taxa de vigilante) de 8000 bps e uma intermitência 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 

Os token buckets começam cheios em 1000 bytes. Se um pacote com 450 bytes chegar, ele é aceito, pois há bytes suficientes disponíveis no token bucket. A ação de conformidade (transmissão) é realizada pelo pacote e 450 bytes são removidos do token bucket (e deixam 550 bytes). Se o próximo pacote chegar 0,25 segundo depois, 250 bytes serão adicionados ao token bucket de acordo com a próxima fórmula:

(0.25 * 8000)/8

1. Período começa cheio:

   • Burst normal = 1000 bytes
   • Tokens iniciais = 1000 bytes

2. O primeiro pacote chega:

   • Tamanho do pacote =450 bytes
   • O pacote está em conformidade porque o bucket tem tokens suficientes.
   • O vigilante remove os tokens de 450 bytes do bucket.

   Cálculo: 1000 - 450 = 550 bytes restantes

3. O próximo pacote chega 0,25 segundo mais tarde:

   • Taxa de vigilância = 8000 bps
   • Tokens adicionados durante 0,25 segundo:

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

4. Bucket após atualização:

   • Tokens existentes restantes = 550 bytes
   • Novos tokens adicionados =250 bytes

   Cálculo: 550 + 250 = 800 bytes

O cálculo deixa 800 bytes no token bucket (tokens restantes no policer bucket). Se o próximo pacote tiver 900 bytes, o pacote implicará excesso e a ação exceder (cancelamento) será executada. Nenhum byte foi retirado do token bucket.

Modelagem de tráfego

O Cisco IOS® suporta os próximos métodos de modelagem de tráfego:

• Formatação de tráfego genérico

• Formatação de tráfego frame relay

• Modelagem com base em classes e Modelagem Distribuída com base em classes

Todos os métodos de modelagem são semelhantes em implementação, embora suas interfaces de linha de comandos (CLIs) sejam um pouco diferentes e usem tipos diferentes de filas para conter e modelar o tráfego adiado. A Cisco recomenda modelagem baseada em classe e modelagem distribuída, que são configuradas com a CLI QoS modular.

O próximo diagrama ilustra como uma política de QoS organiza o tráfego em classes e enfileira pacotes que excedem as taxas de modelagem configuradas.

Políticas de tráfego

O Cisco IOS suporta os próximos métodos de vigilância de tráfego:

• Taxa de acesso consolidada

• Vigilância baseada em classe

Os dois mecanismos têm diferenças funcionais importantes, conforme explicado em Como configurar a vigilância baseada em classe. A Cisco recomenda a vigilância baseada em classe e outros recursos da CLI QoS modular quando as políticas de QoS são aplicadas.

Use o comando police para especificar que uma classe de tráfego deve ter uma taxa máxima imposta a ela e, se essa taxa for excedida, uma ação imediata deverá ser tomada. Ou seja, com o comando de vigia, não é possível armazenar o pacote no buffer e, posteriormente, enviá-lo, como é o caso do comando de modelagem.

Além disso, com a vigilância, o token bucket determina se um pacote excede ou corresponde à taxa aplicada. Em ambos os casos, a vigilância implementa uma ação configurável, que inclui a precedência de IP ou o Ponto de Código de Serviços Diferenciados (DSCP).

O próximo diagrama ilustra uma aplicação comum de vigilância de tráfego em um ponto de congestionamento, onde os recursos de QoS geralmente se aplicam.

Controles de largura de banda mínima versus máxima

Os comandos shape e police limitam o tráfego a uma taxa máxima configurada. No MQC, a taxa configurada para a média de forma e a política é especificada em bps, a menos que a sintaxe específica da plataforma declare o contrário. O mais importante é que nenhum dos mecanismos fornece uma garantia de largura de banda mínima durante períodos de congestionamento. Use o comando bandwidth ou priority para fornecer essas garantias.

Uma política hierárquica usa duas políticas de serviço - uma política pai para aplicar um mecanismo de QoS a um agregado de tráfego e uma política filha para aplicar um mecanismo de QoS a um fluxo ou subconjunto do agregado. Interfaces lógicas, como subinterfaces e interfaces de túnel, exigem uma política hierárquica com o recurso de tráfegolimiting no nível pai e enfileiramento nos níveis inferiores. O recurso de tráfegolimiting reduz a taxa de saída e (presumivelmente) cria congestionamento, conforme visto pelos pacotes em excesso queuing.

A próxima configuração é sub-ótima e é mostrada para ilustrar a diferença entre o comando police e o comando shape quando limiting um tráfego é agregado, neste caso, padrão de classe, a uma taxa máxima. Nessa configuração, o comando police envia pacotes das classes filho com base no tamanho do pacote e no número de bytes que permanecem nos token buckets de conformidade e excedente. (Consulte Política de tráfego.) O resultado é que as taxas dadas às classes de Voz sobre IP (VoIP) e Protocolo de Internet (IP) não podem ser garantidas, já que o recurso de polícia substitui as garantias feitas pelo recurso de prioridade.

Entretanto, se o comando shape for utilizado, o resultado será um sistema de enfileiramento hierárquico, e todas as garantias serão implementadas. Em outras palavras, quando a carga oferecida excede a taxa de forma, as classes VoIP e IP têm garantia de sua taxa, e o tráfego padrão da classe (no nível infantil) incorre em qualquer queda.

Caution: Essa configuração não é recomendada e é mostrada para ilustrar a diferença entre o comando police versus shape quando ele limita um agregado de tráfego.

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 a configuração anterior faça sentido, a vigilância deve ser substituída pela modelagem. Por exemplo:

policy-map parent
    class class-default
     shape average 3300000 103000 0
     service-policy child

Use show policy-map interface <interface> para verificar as políticas configuradas, os contadores de classe, a taxa oferecida, os contadores de queda, a taxa de modelagem, a profundidade da fila e os contadores de conformação/exceder/violar da política.

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

Note: Para saber mais sobre políticas pai e filho, consulte QoS: Política de Serviço Filho para Classe de Prioridade.

O exemplo anterior é intencionalmente insuficiente e é fornecido apenas para ilustrar a diferença entre policiamento e modelagem em uma política de QoS hierárquica. Em um projeto de QoS recomendado, o comando priority é normalmente reservado para o tráfego em tempo real sensível à latência, como voz. Classes não em tempo real que exigem uma garantia de largura de banda mínima geralmente usam o comando bandwidth com CBWFQ.

Essa abordagem está alinhada com as orientações de design de QoS da Cisco para LLQ e CBWFQ. O LLQ fornece tratamento de prioridade estrita para tráfego sensível a atrasos, enquanto o CBWFQ fornece garantias de largura de banda para outras classes de tráfego durante o congestionamento. Portanto, a classe IP neste exemplo é mais bem representada com largura de banda em vez de prioridade, a menos que essa classe transporte tráfego que exija explicitamente tratamento de prioridade estrita.

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

Informações Relacionadas

• Suporte à tecnologia de qualidade de serviços (QoS)
• Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões

Revisão	Data de publicação	Comentários
6.0	21-Jul-2026	Recertificação.
4.0	07-Sep-2023	Requisitos de marca atualizados, SEO, gramática e formatação.
3.0	26-Sep-2022	Recertificação
1.0	15-Feb-2002	Versão inicial