Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Conventions

Informações de Apoio

Resumo das diferenças

Configurar o comando de largura de banda

Configurar o comando de prioridade

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

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

Use o comando police para definir um máximo

Entender o valor da largura de banda disponível

Informações Relacionadas

Introdução

Este documento descreve como os comandos  bandwidth   e  priority são aplicados em um mapa de política 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 comandos  bandwidth  e  priority :

Função

bandwidthCommand

priorityCommand

Garantia de largura de banda mínima

Yes

Yes

Garantia máxima de largura de banda

No

Yes

Policer embutido

No

Yes

Fornece latência baixa

No

Yes

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:

Aplicativo

bandwidthCommand

priorityCommand

Gerenciamento de largura de banda para links de WAN

Yes

Razoavelmente

Gerenciar o atraso e as variações no atraso (instabilidade)

No

Yes

Melhorar o tempo de resposta do aplicativo

No

Yes

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:

Sintaxe do comando

Descrição

bandwidth {kbps}

Especifica a alocação de largura de banda como uma taxa de bit.

bandwidth percent {value}

Especifica a alocação de largura de banda como uma porcentagem da taxa de link principal.

bandwidth remaining percent {value}

Especifica a alocação da largura de banda como uma porcentagem da largura de banda que não foi alocada para outras classes.

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:

Fila

Local

Métodos de enfileiramento

Políticas de serviço se aplicam

Comando para ajuste

Fila de hardware ou anel de transmissão

Adaptador de porta ou módulo de rede

somente FIFO

No

tx-ring-limit

Fila da Camada 3

Sistema do processador e buffers da interface da Camada 3

WFQ, CBWFQ, LLQ com base no fluxo

Yes

Varia com o método de enfileiramento. Use o comando queue-limit com uma classe de largura de banda.

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:

Comando

Congestionamento

Não congestionamento

bandwidthCommand

Pode exceder à taxa alocada.

Pode exceder à taxa alocada.

priorityCommand

O Cisco IOS mede os pacotes e aplica um sistema de medição de tráfego por um token bucket. Os pacotes correspondentes são vigiados à taxa de bps configurada e qualquer pacote em excesso é descartado.

A classe pode exceder esta largura de banda configurada.

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 interface ou show queueing   do.

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