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

Introdução

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.

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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

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

Resumo das diferenças

Esta tabela alista as diferenças funcionais entre os comandos bandwidth and priority:

Além, os comandos bandwidth and priority são projetados encontrar objetivos da política diferentes do Qualidade de Serviço (QoS). Esta tabela alista aqueles objetivos de deferimento:

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 manuais de configuração do ^{® do} Cisco IOS descrevem o comando bandwidth como a “quantidade de largura de banda, nos kbps, ser atribuído à classe. Para especificar ou alterar a largura de banda atribuída para uma classe que pertence 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 formulários da sintaxe de comando, como ilustrado nesta tabela:

bandwidth {kbps}

bandwidth percent {value}

bandwidth remaining percent {value}

Nota: O comando bandwidth define um comportamento, que seja 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 mais informação, refira porque o uso CBWFQ?.

Configurando o comando priority

Os guias de configuração do IOS da Cisco descrevem o comando priority como a reserva “de uma fila de prioridade com uma quantidade especificada de largura de banda disponível para o tráfego de CBWFQ… para dar a prioridade a uma classe de tráfego baseada na quantidade de largura de banda disponível dentro de uma política de tráfego.” Abaixo temos uma explicação dessas definições.

Você cria uma fila de prioridade com os estes 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. (Aviso que as garantias de largura de banda são somente uma edição quando uma relação for congestionada.) Ou seja 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 meça a carga oferecida e assegura-se de que o fluxo de tráfego se conforme à taxa configurada. Somente o tráfego em conformidade com o token bucket tem a baixa latência garantida. Todo o tráfego excedente é enviado se o link não é congestionado ou deixado cair se o link é congestionado. Para mais informação, refira o que é um Token Bucket?.

A finalidade do policer embutido é assegurar-se de que as outras filas estejam prestadas serviços de manutenção pelo planificador de enfileiramento. Nos recursos de enfileiramento da prioridade original Cisco, que usam os comandos priority-group and priority-list, o planificador prestou serviços de manutenção sempre à fila a mais prioritária primeiramente. 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 comando priority — e sua diferença principal do comando bandwidth — é como fornece uma prioridade do desenfileiramento restrito para fornecer um limite na 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 estes dois grupos 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 transmitir anel é a última parada antes dos meios físicos.

Na ilustração a seguir, o anel de transmissão foi configurado para conter quatro pacotes. Se três pacotes já estão no anel, a seguir o melhor possível nós podemos enfileirar-se à quarta posição e então esperar os outros três para esvaziar. 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 ajustar o tamanho do transmitir anel a um valor fora de padrão. A Cisco recomenda o ajuste do anel de transmissão ao transmitir o tráfego de voz. Refira o módulo dos recursos de enfileiramento de latência baixa.

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 de-forem enfileirados imediatamente, cada salto 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 mais informação, refira os dicas técnica da Qualidade de voz.

Nota: Com comandos both, o valor dos kbps deve levar em conta a camada 2 aérea. Ou seja se uma garantia é feita a uma classe, essa garantia é no que diz respeito à taxa de transferência da camada 2. Para mais informação, refira que bytes são contados pelo enfileiramento do IP to ATM CoS? e porque uso 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. Ou seja se uma classe de tráfego não está usando sua largura de banda configurada, toda a largura de banda não utilizada é 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 a largura de banda excedente:

Nota: Uma exceção a estas diretrizes para o LLQ é Frame Relay no Cisco 7200 Router e em outras Plataformas da NON-rota/processador de switch (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 Cisco IOS Software Release 12.2 remove esta exceção e assegura-se de que os pacotes sem adequação estejam deixados cair somente se há uma congestão. Além, os pacotes menores do que um tamanho de fragmentação FRF.12 são enviados já não com o processo fragmentando, reduzindo a utilização 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 toda a largura de banda remanescente. É aqui como a visão geral de características do Class-Based Weighted Fair Queueing 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ê aplica esta política a um link do 1 Mbps, significa que 300 kbps estão garantidos à barra de classe, e 600 kbps são garantidos à classe baz. Importante, 100 kbps são restantes para o class-default. 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. Nesta configuração, a razão de compartilhamento é 30:60 ou 1:2.

A configuração de exemplo seguinte contém três mapas da política — barra, baz, e poli. No mapa de política chamado barra e no mapa de política chamado baz, a largura de banda é especificada pela porcentagem. Contudo, no mapa de política chamado poli, a largura de banda é especificada nos kbps.

Recorde que os mapas da classe devem já ser criados antes que você crie os mapas da 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

Nota: O comando bandwidth remaining percent foi introduzido na versão do Cisco IOS 12.2(T). Refira o low latency queueing com apoio do priority percentage para 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. Esta configuração impõe uma taxa máxima que seja 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 deriva o valor de largura de banda disponível, como mostrado na saída dos comandos show interface or show queueing.

Nós criamos este mapa de política nomeado 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

Deixe-nos olhar como este valor é derivado:

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 são usados já pela Voz e pelas classes de dados:

   4500000 - 3000000 = 1500000 bps
   

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

O máximo padrão do valor da largura de banda reservável de 75 por cento é projetado sair da largura de banda suficiente para o tráfego aéreo, tal como atualizações de protocolo de roteamento e mergulhar 2 Keepalives. 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. Você agora pode aumentar o valor máximo de largura de banda reservável no ATM PVCs usando o comando max-reserved-bandwidth. Para versões do IOS apoiadas e uma informações de fundo mais adicional, refira a compreensão do comando max-reserved-bandwidth no ATM PVCs.

Em PVC do Frame Relay, os comandos bandwidth and priority calculam a quantidade total de largura de banda disponível em 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 mais informação, refira configurar o CBWFQ em PVC do Frame Relay.

Informações Relacionadas

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