Comparando comandos de largura de banda e de prioridade de uma política de servidor de QoS

Introduction

Os comandos bandwidth e priority definem ações que podem ser aplicadas dentro de um mapa de políticas da interface de linha de comando da qualidade de serviço modular (MQC), que pode ser aplicado a uma interface, uma subinterface ou um circuito virtual (VC) através do comando service-policy. Especificamente, estes comandos fornecem uma garantia de largura de banda aos pacotes que correspondem aos critérios de uma classe de tráfego. Entretanto, os dois comandos têm diferenças funcionais importantes nessas garantias. Esta Nota Técnica explica essas diferenças e explica como a largura de banda não utilizada de uma classe é distribuída aos fluxos que correspondem a outras classes.

Prerequisites

Requirements

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. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Convenções

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Resumo das diferenças

Esta tabela lista as diferenças funcionais entre os comandos bandwidth e priority:

Além disso, os comandos bandwidth e priority são criados para atender aos diferentes objetivos da política de qualidade de serviço (QoS). Esta tabela lista os diferentes objetivos:

Mesmo com as interfaces rápidas, a maioria das redes ainda precisa de um forte modelo de gerenciamento QoS para lidar efetivamente com pontos de congestionamento e gargalos que ocorrem inevitavelmente devido a incompatibilidades de velocidades ou diversos padrões de tráfego. Redes no mundo real têm recursos limitados e gargalos e precisam de políticas de QoS para garantir a alocação adequada de recursos.

Configurando o comando bandwidth

Os Guias de Configuração do Cisco IOS^® descrevem o comando bandwidth como a "quantidade de largura de banda, em kbps, a ser atribuída à classe. . . .Para especificar ou modificar a largura de banda alocada para uma classe pertencente a um mapa de política."

Veja o significado dessas definições.

O comando de largura de banda fornece uma garantia de largura de banda mínima durante congestionamentos. Há três formas de sintaxe de comando, conforme ilustrado nesta tabela:

bandwidth {kbps}

bandwidth percent {value}

bandwidth remaining percent {value}

Observação: o comando bandwidth define um comportamento, que é uma garantia de largura de banda mínima. Nem todas as plataformas de Cisco routers utilizam Weighted-Fair Queueing (WFQ, Enfileiramento Considerável Ponderado) como o algoritmo subjacente para implementar esse comportamento. Para obter mais informações, consulte Por que usar CBWFQ?

Configurando o comando priority

Os Guias de configuração do Cisco IOS descrevem o comando priority como reservar "uma fila de prioridade com uma quantidade especificada de largura de banda disponível para o tráfego de CBWFQ... Para dar prioridade a uma classe de tráfego baseada na quantidade de largura de banda disponível em uma política de tráfego." Abaixo temos uma explicação dessas definições.

Você cria uma fila de prioridade com esse conjunto de comandos:

Router(config)# policy-map policy-name
 
Router(config-pmap)# class class-name
 
Router(config-pmap-c)# priority kpbs [bytes]

Durante as condições de congestionamento, a classe do tráfego é a largura de banda garantida igual à taxa especificada. (Lembre-se de que as garantias de largura de banda são um problema somente quando uma interface está congestionada.) Em outras palavras, o comando priority fornece uma garantia de largura de banda mínima.

Além disso, o comando de prioridade implementa uma garantia de largura de banda máxima. Internamente, a fila de prioridade usa um token bucket que mede a carga oferecida e garante que o fluxo de tráfego esteja em conformidade com a taxa configurada. Somente o tráfego em conformidade com o token bucket tem a baixa latência garantida. Qualquer tráfego excedente será enviado, se o link não estiver congestionado, ou será descartado, se o link estiver congestionado. Para obter mais informações, consulte O que é um token bucket?.

A finalidade do vigilante integrado é garantir que as outras filas sejam atendidas pelo programador de filas. No recurso de enfileiramento de prioridade original da Cisco, que usa os comandos priority-group e priority-list, o programador sempre é atendido na fila de maior prioridade primeiro. Em casos extremos, as filas de prioridade mais baixa raramente eram atendidas e efetivamente ficavam sem nenhuma largura de banda.

O verdadeiro benefício do comando priority, e sua principal diferença em relação ao comando bandwidth, é como ele fornece uma prioridade estrita de remoção da fila para colocar um limite à latência. Veja como essa vantagem está descrita no Cisco IOS Configuration Guide (Manual de configuração do Cisco IOS): "Uma fila de prioridade máxima (PQ) permite que dados sensíveis a retardo, como os dados de voz, sejam desenfileirados e enviados antes que os pacotes de outras filas sejam desenfileirados." Vamos ver o que isso significa.

Cada interface do roteador mantém esses dois conjuntos de filas:

Na tabela acima, podemos ver que uma política de serviço se aplica apenas aos pacotes na fila da camada 3.

Desenfileiramento estrito refere-se ao programador de encapsulamento que atende à fila de prioridades e que encaminha seus pacotes ao anel de transmissão primeiro. O anel de transmissão é a última parada antes da mídia física.

Na ilustração a seguir, o anel de transmissão foi configurado para conter quatro pacotes. Se três pacotes já estiverem no anel, no máximo, podemos enfileirar até a quarta posição e, em seguida, aguardar que os outros três sejam esvaziados. Assim, o mecanismo Enfileiramento de baixa latência (LLQ) simplesmente remove da fila os pacotes para a extremidade da fila primeiro a entrar, primeiro a sair (FIFO) do anel de transmissão.

Use o comando tx-ring-limit command para ajustar o tamanho do anel de transmissão para um valor não padrão. A Cisco recomenda o ajuste do anel de transmissão ao transmitir o tráfego de voz. Consulte o Módulo de recursos de enfileiramento de baixa latência.

A priorização do tráfego é especialmente importante para aplicativos baseados em transações interativas e sensíveis a retardos. Para minimizar o retardo e a variação de sinal, os dispositivos de rede devem poder servir os pacotes de voz tão logo cheguem ou, em outras palavras, na forma de prioridade estrita. Só prioridade máxima funciona bem para voz. A menos que os pacotes de voz sejam desenfileirados imediatamente, cada salto apresentará mais atraso.

A ITU (International Telecommunications Union) recomenda um retardo máximo unidirecional de 150 milissegundos de ponta-a-ponta. Sem o desenfileiramento imediato na interface do roteador, um único salto de roteador pode responder pela maior parte desse orçamento de retardo. Para obter mais informações, consulte as Dicas técnicas de qualidade de voz.

Observação: com ambos os comandos, o valor kbps deve levar em conta a sobrecarga da Camada 2. Em outras palavras, se uma garantia for efetuada para uma classe, essa garantia estará relacionada à produtividade da Camada 2. Para obter mais informações, consulte Quais bytes são contados pelo IP para o enfileiramento de CoS ATM? e Por que usar LLQ?.

Quais classes de tráfego podem usar o excesso de largura de banda?

Embora a garantia da largura de banda fornecida e a prioridade dos comandos tenham sido descritas com palavras como "reservada" e "largura de banda a ser reservada", nenhum dos dois comandos implementa uma reserva verdadeira. Em outras palavras, se uma classe de tráfego não estiver usando a largura de banda configurada, qualquer largura de banda não utilizada será compartilhada entre as outras classes.

O sistema de filas impõe uma exceção importante a essa regra, com uma classe de prioridade. Conforme observado acima, a carga oferecida de uma classe de prioridade é medida por um vigilante de tráfego. Durante condições de congestionamento, uma classe de prioridade não pode usar excesso de largura de banda.

Esta tabela descreve quando uma classe de largura de banda e uma classe de prioridade podem usar o excesso de largura de banda:

Observação: uma exceção a essas diretrizes para LLQ é o Frame Relay no roteador Cisco 7200 e em outras plataformas não-Route/Switch Processor (RSP). A implementação original do LLQ no Frame Relay, nessas plataformas, não permite que as classes de prioridade excedam a taxa configurada durante os períodos de não-congestionamento. O software Cisco IOS versão 12.2 remove essa exceção e garante que os pacotes não conformes sejam descartados apenas se houver congestionamento. Além disso, os pacotes menores do que o tamanho de fragmentação FRF.12 não são mais enviados pelo processo de fragmentação, reduzindo a utilização da CPU.

A partir da discussão acima é importante entender que, como as classes de prioridade são vigiadas em condições de congestionamento, elas não recebem nenhuma largura de banda restante das classes de largura de banda. Portanto, a largura de banda restante é compartilhada por todas as classes de largura de banda e pela classe padrão.

Como a largura de banda não utilizada é alocada?

Esta seção explica como o sistema de enfileiramento distribui a largura de banda restante. Veja como a Visão geral do recurso de enfileiramento justo ponderado distribuído de acordo com a classe descreve o mecanismo de alocação: "Se houver largura de banda em excesso, o excedente será dividido entre as classes de tráfego na proporção das larguras de banda configuradas. Se nem toda a largura de banda estiver alocada, a largura de banda restante será proporcionalmente alocada entre as classes, com base em sua largura de banda configurada." Vamos examinar dois exemplos.

No primeiro exemplo, o comando policy-map foo garante 30 da largura de banda para a classe bar e 60 da largura de banda para a classe baz.

policy-map foo 
  class bar 
    bandwidth percent 30 
 class baz 
  bandwidth percent 60

Se você aplicar essa política a um link de 1 Mbps, isso significa que 300 kbps são garantidos para a classe bar e 600 kbps são garantidos para a classe baz. Importante: 100 kbps correspondem ao restante do padrão de classe. Se o padrão de classe não precisar disso, os 100 kbps não utilizados estarão disponíveis para uso pela classe bar e pela classe baz. Se ambas as classes precisarem de largura de banda, elas a compartilham com base na proporção das taxas configuradas. Nessa configuração, a taxa de compartilhamento é 30:60 ou 1:2.

O próximo exemplo de configuração contém três mapas de política: bar, baz e poli. No mapa de política chamado bar e no mapa de política chamado baz, a largura de banda é especificada por porcentagem. No entanto, no mapa de política chamado poli, a largura de banda é especificada em kbps.

Lembre-se de que os mapas de classe já devem ser criados antes de criar os mapas de política.

 
 policy-map bar
  class voice
   priority percent 10
  class data
   bandwidth percent 30
  class video
   bandwidth percent 20
 policy-map baz
  class voice
   priority percent 10
  class data
   bandwidth remaining percent 30
  class video
   bandwidth remaining percent 20
 policy-map poli
  class voice
  class data
   bandwidth 30
  class video
   bandwidth 20

Observação: o comando bandwidth last percent foi introduzido no Cisco IOS versão 12.2(T). Consulte Enfileiramento de baixa latência com o suporte à porcentagem de prioridade para obter uma descrição detalhada do comando bandwidth.

Utilizando o comando police para definir um máximo

Se uma classe de largura de banda ou prioridade não puder exceder sua largura de banda alocada durante períodos sem congestão, você puder continuar combinar o comando de prioridade com o comando de política. Essa configuração impõe uma taxa máxima que está sempre ativa na classe. Optar por configurar uma declaração de vigia nessa configuração depende do objetivo da política.

Compreendendo o valor de largura de banda disponível

Esta seção explica como o sistema de enfileiramento calcula o valor de largura de banda disponível, conforme exibido na saída dos comandos show interface ou show enqueueing.

Criamos este mapa de política chamado leslie:

7200-16# show policy-map leslie 
  Policy Map leslie 
    Class voice 
      Weighted Fair Queueing 
            Strict Priority 
            Bandwidth 1000 (kbps) Burst 25000 (Bytes) 
    Class data 
      Weighted Fair Queueing 
            Bandwidth 2000 (kbps) Max Threshold 64 (packets)

Então, criamos um Circuito virtual permanente (PVC) ATM, atribuímos este circuito à categoria de serviço ATM em tempo não-real de taxa de bits variável e configuramos uma taxa de células sustentada de 6 Mbps. Aplicamos, em seguida, o mapa de políticas ao PVC, com o comando service-policy output leslie.

7200-16(config)# interface atm 4/0.10 point 
7200-16(config-subif)# pvc 0/101 
7200-16(config-if-atm-vc)# vbr-nrt 6000 6000 
7200-16(config-if-atm-vc)# service-policy output leslie

O comando show queueing interface atm exibe “Available Bandwidth 1500 kilobits/sec".

7200-16# show queueing interface atm 4/0.10 
  Interface ATM4/0.10 VC 0/101 
  Queueing strategy: weighted fair 
  Output queue: 0/512/64/0 (size/max total/threshold/drops) 
     Conversations  0/0/128 (active/max active/max total) 
     Reserved Conversations 1/1 (allocated/max allocated) 
     Available Bandwidth 1500 kilobits/sec

Vamos observar como esse valor é calculado:

1. 6 Mbps é a Taxa média de células (SCR). Por padrão, 75 dessa taxa podem ser reservados:

   0.75 * 6000000 = 4500000
   

2. 3000 kbps já são usados pelas classes de voz e dados:

   4500000 - 3000000 = 1500000 bps
   

3. A largura de banda disponível é 1500000 bps.

O valor máximo padrão de largura de banda reservável de 75 é projetado para deixar largura de banda suficiente para o tráfego de sobrecarga, como atualizações do protocolo de roteamento e keepalives da Camada 2. Ele também cobre a carga adicional da Camada 2 para os pacotes correspondentes às classes de tráfego definidas ou às classes padrão de classe. Agora você pode aumentar o valor máximo de largura de banda reservável nos PVCs ATM usando o comando max-reserved-bandwidth. Para obter as versões compatíveis do IOS e informações gerais adicionais, consulte Noções básicas do comando max-reserved-bandwidth nos PVCs ATM.

Nos PVCs de frame relay, os comandos bandwidth e priority calculam a quantidade total de largura de banda disponível de uma destas maneiras:

• Se uma Minimum Acceptable Committed Information Rate (minCIR) não estiver configurada, o CIR é dividido em dois.

• Se um minCIR estiver configurado, a definição do minCIR será usada no cálculo. A largura de banda completa da taxa descrita acima pode ser atribuída a classes de largura de banda e de prioridades.

Dessa forma, o comando max-reserved-bandwidth não é suportado nos PVCs de Frame Relay, embora você deva se certificar de que a largura de banda configurada é grande o suficiente para acomodar carga adicional da Camada 2. Para obter mais informações, consulte Configuração de CBWFQ em PVCs de Frame Relay.

Informações Relacionadas

• Página de suporte de QoS
• Suporte Técnico e Documentação - Cisco Systems