Determinar os comandos de largura de banda e prioridade de uma política de serviço de QoS

Introdução

Este documento descreve como os comandos bandwidth e priority são aplicados em um mapa de políticas de interface de linha de comando de qualidade de serviço modular.

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.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

Os comandos bandwidth e priority definem ações que podem ser aplicadas dentro de um mapa de política de interface de linha de comando de qualidade de serviço (MQC) modular, que você aplica a uma interface, subinterface ou 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.

Resumo das diferenças

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

Além disso, os comandos bandwidth  e priority são projetados para atender a diferentes objetivos de 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. As redes reais têm recursos e gargalos de recursos limitados e precisam de políticas de QoS para garantir a alocação adequada de recursos.

Configurar o comando de largura de banda

Os ^{Guias de Configuração ®} do Cisco IOS ^{descrevem o} bandwidth  comando 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 que pertença a um mapa de políticas."

Veja o significado dessas definições.

O bandwidth  comando fornece uma garantia de largura de banda mínima durante o congestionamento. 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 roteador da Cisco usam weighted-fair queueing (WFQ) como o algoritmo principal para implementar esse comportamento. Para obter mais informações, consulte Por que usar o CBWFQ?

Configurar o comando de prioridade

Os Guias de Configuração do Cisco IOS descrevem o comando priority como uma reserva para "uma fila de prioridade com uma quantidade especificada de largura de banda disponível para o tráfego CBWFQ... para dar prioridade a uma classe de tráfego com base na quantidade de largura de banda disponível dentro de uma política de tráfego." O próximo exemplo explica o que essas definições significam.

Você cria uma fila de prioridade com estes conjuntos 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 priority  comando fornece uma garantia de largura de banda mínima.

Além disso, o priority  comando 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 original de enfileiramento de prioridade da Cisco, que usa os comandos priority-group e priority-list , o agendador sempre atendia primeiro à fila de prioridade mais alta. Em casos extremos, as filas de prioridade mais baixa raramente eram atendidas e efetivamente ficavam sem nenhuma largura de banda.

O benefício real do priority  comando — e sua principal diferença em relação ao bandwidth  comando — é como ele fornece uma prioridade rígida de desenfileiramento para fornecer um limite na latência. Veja como o Cisco IOS Configuration Guide descreve esse benefício: "Uma fila de prioridade estrita (PQ) permite que dados sensíveis a atrasos, como voz, sejam removidos da fila e enviados antes que pacotes em outras filas sejam removidos da fila." Veja o que isso significa.

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

A partir da tabela anterior, podemos ver que uma política de serviço se aplica somente a pacotes na fila da camada 3.

O desenfileiramento estrito se refere ao agendador de enfileiramento que serve a fila de prioridade e encaminha seus pacotes para o anel de transmissão primeiro. O anel de transmissão é a última parada antes da mídia física.

Na próxima ilustração, 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 tx-ring-limit comando para ajustar o tamanho do anel de transmissão para um valor não padrão. A Cisco recomenda que você ajuste o anel de transmissão ao transmitir tráfego de voz.

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. Somente uma prioridade estrita funciona bem para voz. A menos que os pacotes de voz sejam imediatamente desenfileirados, cada salto pode introduzir 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 o Suporte de qualidade de voz.

Observação: com ambos os comandos, o valor de 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.

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

Embora as garantias de largura de banda fornecidas pelos comandos bandwidth  priority  e tenham sido descritas com palavras como "reserved" e "bandwidth to be set aside", nenhum dos comandos implementa uma reserva verdadeira. Em outras palavras, se uma classe de tráfego não usar sua 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. Como observado anteriormente, 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 que um tamanho de fragmentação FRF.12 não são mais enviados através do processo de fragmentação, o que reduz a utilização da CPU.

A partir da discussão anterior, é importante entender que, como as classes de prioridade são vigiadas durante 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.

Alocação de largura de banda não utilizada

Esta seção explica como o sistema de enfileiramento distribui a largura de banda restante. Veja como a Visão geral do recurso Weighted Fair Queueing baseado em classe descreve o mecanismo de alocação: "Se o excesso de largura de banda estiver disponível, o excesso de largura de banda será dividido entre as classes de tráfego na proporção de suas 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." Veja dois exemplos.

No primeiro exemplo, 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 proporção é compartilhada de 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 da criação dos 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 pending percent foi introduzido no Cisco IOS versão 12.2(T).

Use o comando police para definir um máximo

Se uma classe de largura de banda ou prioridade não deve exceder sua largura de banda alocada durante períodos sem congestionamento, você pode combinar o priority comando com o police  comando. Essa configuração impõe uma taxa máxima que está sempre ativa na classe. A opção de configurar uma police  instrução nessa configuração depende do objetivo da política.

Entender o valor da largura de banda disponível

Esta seção explica como o sistema de enfileiramento deriva o valor de largura de banda disponível, conforme exibido na saída dos comandos show interfaceoushow queueing .

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. Em seguida, aplicamos o mapa de políticas ao PVC com o service-policy output leslie comando.

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

show queueing interface atm O comando exibe a largura de banda disponível de 1500 kilobits/seg.

7200-16#show queue interface atm 4/0.10 
  Interface ATM4/0.10 VC 0/101 
  queue 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% disso é reservável:

   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 sobrecarga da Camada 2 para pacotes que correspondem e são classes de tráfego definidas ou classe padrão de classe. Agora você pode aumentar o valor máximo da largura de banda reservável em PVCs ATM com o max-reserved-bandwidth comando. Para obter as versões suportadas do Cisco IOS e mais informações de apoio, consulte Compreender o Comando max-reserved-bandwidth em PVC ATM.

Nos PVCs do 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 total da taxa anterior pode ser atribuída às classes de largura de banda e prioridade.

Assim, o max-reserved-bandwidth comando não é suportado nos PVCs do Frame Relay, embora você deva garantir que a quantidade de largura de banda configurada seja grande o suficiente para acomodar a sobrecarga da Camada 2. Para obter mais informações, consulte Configurar CBWFQ em PVCs de Frame Relay.

Informações Relacionadas

• Suporte técnico e downloads da Cisco